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を出力します