Nginxで一見一般的な「ファイル記述子が多すぎる」エラーが発生しました。多くの検索の後、解決策は明らかにnginxで利用可能なファイル記述子の数を増やすことです。しかし、これを意味のある安全な方法で快適に行うための十分な情報はありません。ほとんどのフォーラム/メールスレッドがカバーする主なポイントは次のとおりです。
cat /proc/sys/fs/file-max
出力 "100678")ulimit
を実行しているため、すべてのユーザーが「無制限」を出力するので、下部の更新を参照してください)ワーカーあたりの接続数よりも大きいworker_rlimit_nofile値をスローして1日で呼び出すことができますが、ここで何が起こっているのか本当にわかりません。
update:rootと通常のユーザーの両方で、ulimitは「unlimited」を出力しますが、BUT ulimit -Hn
およびulimit -Sn
両方の出力1024
worker_rlimit_nofile
は、nginxを実行しているユーザーとは対照的に、ワーカープロセスのファイル記述子の制限を設定します。このユーザーで実行されている他のプログラムがファイル記述子の不足を適切に処理できない場合は、この制限をユーザーの制限よりも少し低く設定する必要があります。
最初に、ファイル記述子を何が使用していますか?
ワーカーあたりの制限がOSの制限を下回るのはなぜですか?
ワーカーはマシンで実行されている唯一のプロセスではないため、これはOSによって制御されます。 nginxを実行しているユーザー用に変更するには、以下を参照してください。ワーカーがすべてのプロセスで利用できるすべてのファイル記述子を使い果たした場合、それを可能にするために制限を設定しないでください。
#/etc/sysctl.conf
#This sets the value you see when running cat /proc/sys/fs/file-max
fs.file-max = 65536"
#/etc/security/limits.conf
#this sets the defaults for all users
* soft nofile 4096
* hard nofile 4096
#This overrides the default for user `usernamehere`
usernamehere soft nofile 10240
usernamehere hard nofile 10240
これらのセキュリティ制限を変更した後でも、ulimit
を使用するユーザーのソフト制限を増やす必要があったと思います。
現在の制限を確認するにはどうすればよいですか?
ulimit -a
実行するユーザーに関連付けられているすべての制限が表示されます。
正直に言うにはソースをチェックする必要がありますが、それはかなり低いです。
worker_rlimit_nofile 15000;
および問題がなければ、安全に増やすことができますが、ファイル記述子が不足する可能性はごくわずかです。