web-dev-qa-db-ja.com

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

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

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

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

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

update:rootと通常のユーザーの両方で、ulimitは「unlimited」を出力しますが、BUT ulimit -Hnおよびulimit -Sn両方の出力1024

10
John Bachir

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

最初に、ファイル記述子を何が使用していますか?

  1. クライアントへのアクティブな各接続
  2. Proxy_passを使用していますか?これらのリクエストを処理するHost:portへのソケットを開きます
  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実行するユーザーに関連付けられているすべての制限が表示されます。

10
Dan R

正直に言うにはソースをチェックする必要がありますが、それはかなり低いです。

worker_rlimit_nofile 15000;および問題がなければ、安全に増やすことができますが、ファイル記述子が不足する可能性はごくわずかです。

2