worker_connections を上げる前に NGINX プロキシのソケットを見積もる
プロキシされる接続は通常クライアント側とアップストリーム側の 2 つのソケットを占有します。ワーカーの接続上限とサービスのファイルディスクリプタ上限を区別してください。
長時間存続するプロキシ接続は、通常クライアント用とアップストリーム用の 2 つのソケットを占有します。worker_connections は両側を数えます。したがって、これを worker_processes 倍してもプロキシ利用者の容量を約束するものではありません。
接続が失敗したら、報告された上限に従ってください。
| 根拠 | 確認すべき設定またはプロセスの状態 |
|---|---|
| worker_connections の枯渇 | アップストリームのソケットを含むワーカーの接続予算 |
| OS の「開いているファイルが多すぎます」 | 実際のサービスプロセスが継承するファイルディスクリプタ上限 |
待ち受けソケット、ログ、その他の開いているファイルもディスクリプタを消費します。接続の再利用とトラフィックの構成が、利用者とソケットの関係を変えます。
worker_rlimit_nofile は環境の権限の範囲でワーカーの上限を調整します。systemd ユニットは LimitNOFILE を設定できますが、対話シェルの ulimit は稼働中のサービスを変えません。
上限は作業負荷に合わせて見積もり、誰が消費しているかを確認してください。想定外のクライアントや繰り返し失敗するアップストリーム接続は、以前は十分だった予算を枯渇させます。プロセス数やメモリ上限を増やしてもディスクリプタ不足は直りません。