☰

複数のLXCがある環境でサービスを開始すると、「エラー：開いたファイルが多すぎます」

tag-icon • tag-icon linux lxc
複数のLXCがある環境でサービスを開始すると、「エラー：開いたファイルが多すぎます」

環境：

私はCentOS-7をハイパーバイザーとして使用していますlibvirt。各コンテナは、単純なFreePBX（Asterisk、Apache、MySQL +ビット）でCentOS-7の最小インストールを実行します。

兆候：

16個のコンテナが問題なく実行されています。コンテナを再起動すると起動しますが、17番目のコンテナが起動した後はsystemctl start/restart/stop <anything>どのコンテナでも次のことができません。

[root@test-lxc ~]# systemctl restart dnsmasq
Error: Too many open files

診断：

17番目のLXCの実行と失敗中に、次の診断と計算が行われましたsystemctl restart blabla。

LXCにSSHで接続して、lsなどの最も基本的なコマンドを実行できます。私はこの制限がsystemd。

私はどこで/なぜ限界にぶつかったのか理解しようとしています。

[root@lxc-hypervisor]# sysctl fs.file-nr
fs.file-nr = 29616      0       12988463

これは調整されておらず、デフォルトでインストールされています。上記と同様に、最大（最後）の値= 12988463はハイパーバイザーによって報告され、各LXCの内部にもあります。 30,000未満の非常に類似した最初の値も各LXCで報告されています。

各LXC内のすべてのプロセスのファイル記述子の数を数えようとすると、各LXCで取得される順序は400〜500です。

for pid in $( ls /proc/ | grep -E -e "^[0-9][0-9]*\$" ); do
    ls -l /proc/${pid}/fd/ 2> /dev/null | wc -l
done

ハイパーバイザー自体がない場合、合計は約9000（9k）です。ハイパーバイザーで実行すると、通常10005のように10000よりわずかに高い疑わしいほど近い値が得られます。

質問：

Q1.制限はどこで設定または継承されますか？

Q2.制限がsystemctl start/stop/restart blahコマンドに影響を与えるのはなぜですか？しかし、まだLXCでsshを介してroot権限になりますが、分岐ループが多いbashスクリプトなどのコマンドを実行できます。

Q3.より多くのLXCを実行できるように制限を調整する方法。私が知る限り、RAMや他のリソースに制限はありません。

ファイル記述子の制限 トピックに関する多くの記事や回答を読みましたが、私のシステムがどこで制限に達したかを確認できませんでした。

その他の関連情報も歓迎します。

答え1

私はあなたがグローバル制限に達していないと信じています。inotify限界。これは実行中のコンテナで見ることができます。システムなぜならシステム使用inotify会計は便利ですが、ホストも影響を受けます。コンテナは使用されません。システム（いいえinotify）には影響しないことがあります。

/proc/sys/fs/inotify/max_user_instances:

これは、実際のユーザーIDごとに作成できるinotifyインスタンスの数の上限を指定します。

ルートがない場合（例：根本当はコンテナの中にあります。根) コンテナが使用中の場合根ユーザーがボトルネックに遭遇します。複数のコンテナが同じルートのないユーザーマッピングを使用すると、そのコンテナにボトルネックが発生する可能性があります。根ユーザー（ホストには影響しません）。デフォルトは 128 で、コンテナの使用には少なすぎます。

CentOS7（またはRocky9）にはLXCのデフォルト設定は含まれていません。Debian ベースのディストリビューションには以下が含まれます。ホストシステム上のこのファイルは次のとおりです。

/etc/sysctl.d/30-lxc-inotify.conf:

# Defines the maximum number of inotify listeners.
# By default, this value is 128, which is quickly exhausted when using
# systemd-based LXC containers (15 containers are enough).
# When the limit is reached, systemd becomes mostly unusable, throwing
# "Too many open files" all around (both on the host and in containers).
# See https://kdecherf.com/blog/2015/09/12/systemd-and-the-fd-exhaustion/
# Increase the user inotify instance limit to allow for about
# 100 containers to run before the limit is hit again
fs.inotify.max_user_instances = 1024

したがって、ホストシステムでこのファイルを作成して同じことを行う必要があります。すぐに適用されます（ホストから）：

sysctl -w fs.inotify.max_user_instances=1024

関連情報