トラフィックが限界に達したときトラフィックの急増（スパイク）が発生するまでは、すべてが順調に見えます。突然、ユーザーに500 Internal Server Errorが表示されたり、サイトが応答しなくなったりします。/var/log/nginx/error.logにあるNginxのエラーログを確認すると、次のような警告が表示されているはずです。
2023/10/27 14:30:15 [alert] 1234#0: 1024 worker_connections are not enough, reopen logs
サーバーが物理的な限界に達しました。デフォルトでは、多くのNginxインストールで各ワーカープロセスの接続数が1024に制限されています。十分な数に思えるかもしれませんが、最新のアプリや多忙なAPIにとっては少なすぎることがよくあります。
なぜ1024では不十分なのかサーバーの総容量は、簡単な式で計算できます：最大接続数 = worker_processes * worker_connections。しかし、NginxをNode.js、PHP-FPM、またはPythonのリバースプロキシとして使用している場合は注意が必要です。
プロキシ設定では、1つのリクエストにつき2つの接続が使用されます。1つはユーザーとNginxを繋ぎ、もう1つはNginxとバックエンドサービスを繋ぎます。これにより、1024の容量は実質的に半分になり、同時に接続できるユーザー数は512人に制限されます。 Nginxの設定以外にも、Linuxカーネルは「オープンファイル数」に制限を設けています。Linuxはすべてのネットワークソケットをファイルとして扱うため、設定ファイルを変更しても、OSがNginxによるさらなる接続の確立をブロックしている可能性があります。
ステップ 1: Nginx設定の更新まずは内部制限を増やすことから始めましょう。お好みのエディタで /etc/nginx/nginx.conf を開きます。
sudo nano /etc/nginx/nginx.conf
events ブロックを探します。2GBから4GBのRAMを搭載した標準的なVPSの場合、4096または8192が安全で安定した開始点となります。
events {
worker_connections 4096;
# 各ワーカーがすべての待機中の新規接続を一度に受け入れるようにする
multi_accept on;
}
ステップ 2: ワーカーとCPUコアの同期同じファイル内で worker_processes ディレクティブを探します。これを auto に設定します。これにより、Nginxは利用可能なCPUコアごとに1つのプロセスを生成するようになり、数値を推測するよりもはるかに効率的です。
worker_processes auto;
ステップ 3: ファイルディスクリプタ制限の引き上げここで多くの人がつまずきます。worker_connections を4096に設定しても、システムが1024を上限だと判断している場合、Nginxはクラッシュし続けます。Nginxが処理できるファイルディスクリプタの数を明示的に伝える必要があります。nginx.conf ファイルの最上部に worker_rlimit_nofile を追加してください。
user www-data;
worker_processes auto;
pid /run/nginx.pid;
# これをworker_connectionsの少なくとも2倍に設定する
worker_rlimit_nofile 16384;
events {
worker_connections 8192;
}
ステップ 4: LinuxシステムのチューニングOS自体に厳格な「nofile」制限がある場合があります。ulimit -n を実行することで、現在のシェルの制限を確認できます。Nginxユーザーに対して永続的な変更を行うには、システム制限ファイルを編集します。
sudo nano /etc/security/limits.conf
ファイルの最後に以下の行を追加します。システムで nginx ユーザーを使用している場合は、www-data を nginx に置き換えてください。
www-data soft nofile 16384
www-data hard nofile 16384
ステップ 5: 修正の適用と確認構文（シンタックス）をテストせずにNginxを再起動しないでください。たった一つのタイプミスでサイト全体がオフラインになる可能性があります。
sudo nginx -t
テストに合格したら、設定をリロードします。これにより、アクティブなユーザーを切断することなく変更が適用されます。
sudo systemctl reload nginx
動作確認の方法システムの言葉を鵜呑みにしてはいけません。アクティブなワーカーのプロセスID（PID）を見つけます。
ps aux | grep nginx
次に、そのPIDのリアルタイム制限を確認します（1234 を実際のPIDに置き換えてください）：
cat /proc/1234/limits | grep "Max open files"
出力が16384を示していれば、サーバーは次のトラフィック急増への準備が整っています。