LinuxおよびNginxの最大ファイル記述子と、worker_rlimit_nofileの最適値を理解する

nginxで一見一般的な「ファイル記述子が多すぎる」エラーが発生しました。多くの検索の後、解決策は明らかにnginxが利用できるファイル記述子の数を増やすことです。しかし、これを意味のある安全な方法で快適に行うのに十分な情報はありません。ほとんどのフォーラム/メールスレッドがカバーする主なポイントは次のとおりです。

• OSには独自の合計ファイル記述子制限があります（私のシステムでは、cat /proc/sys/fs/file-max「100678」を出力します）
• 各ユーザーは独自の制限を持つこともできます（ただし、私のシステムでは、ulimitユーザーが「無制限」を出力するときに実行されます。詳細は下部の更新を参照してください）
• 少数の人々は何の線に沿って何か言ったこの人は言った：「ディレクティブworker_rlimit_nofileは、それがないオペレーティング・システムの制限である『どのように多くの』指定されていません。ディレクティブworker_rlimit_nofileは、この制限が十分でない場合に、この制限を拡大する迅速で汚い方法を許可します。つまり、設定ではなくnginx OSユーザーの制限を設定するほうが「より良い」ということです。

ワーカーあたりの接続数よりも大きいworker_rlimit_nofile値をスローして1日で呼び出すことができますが、ここで何が起こっているのか本当にわかりません。

• ワーカーあたりの制限がOSの制限よりも小さいのはなぜですか？
• 現在の制限を確認するにはどうすればよいですか？

update：rootと通常のユーザーの両方で、ulimitは「無制限」を出力しますが、BUT ulimit -Hnとulimit -Sn両方が1024を出力します

worker_rlimit_nofilenginxを実行しているユーザーとは対照的に、ワーカープロセスのファイル記述子の制限を設定します。このユーザーで実行している他のプログラムがファイル記述子の不足を適切に処理できない場合は、この制限をユーザーの制限よりも少し低く設定する必要があります。

まず、ファイル記述子を何に使用していますか？

1. クライアントへの各アクティブ接続
2. proxy_pass？これらのリクエストを処理するホスト：ポートへのソケットが開きます
3. ローカルポートにproxy_passを使用していますか？それは別のオープンソケットです。（そのプロセスの所有者向け）
4. 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;して問題はありませんでしたが、安全に増やすことができますが、ファイル記述子が不足する可能性はごくわずかです。