コンテンツにスキップ 
私は構成する NGINX ワーカー これにより、worker_processes、worker_connections、worker_rlimit_nofile が正確に一致し、イベントループで Epoll が機能するようになります。これにより、私は CPUコア 効率的であり、同時接続数を計画通りに拡張し、負荷のピーク時でもレイテンシを低く抑える。.
中心点
以下の重要なポイントを押さえることで、堅牢なNGINXワーカーの設定に向けた指針をすぐに得ることができます。.
- ワーカープロセス 論理コアの数に連動させる。理想的には「auto」とする。.
- ワーカーコネクション 実際のピーク値が余裕を持ってカバーされるように設定する。.
- rlimit_nofile また、通信量に合わせてOSの制限値を引き上げる。.
- epoll また、イベントループを効率的に活用するために、multi_accept を有効にします。.
- 負荷テスト 進めながら、少しずつ微調整していく。.
NGINXのアーキテクチャ：マスターとワーカーの仕組みを理解する
私は以下のタスクを分けています マスター また、マスターとワーカーの役割も明確です。マスターは設定を読み込み、ソケットを開き、プロセスを起動する一方、ワーカーはイベントループ内でリクエストを処理します。各ワーカーは独立して動作し、イベントに応答し、ブロックを生じさせることなく数千もの接続を管理できます。 このモデルは、CPUコアを適切に割り当て、epollを介してイベントループを最適に処理する場合に真価を発揮します。その際、プロキシホップが1つ増えるごとに接続リソースが消費されることに留意する必要があります。これは制限値にも反映されます。各役割を理解している人は、意識的に判断を下すことができます。 リソース そして、ボトルネックを早期に未然に防ぎます。.
3つの重要な指針を適切に連携させる
私はこう考える ワーカープロセス, 、worker_connections、およびworker_rlimit_nofileは、決して個別に設定するのではなく、常に一体として扱います。可能な接続の総数は、ワーカー数にワーカーあたりの接続数を掛けた値となり、そこからファイル記述子の制限値を導き出します。 これらの調整パラメータが一致していないと、「too many open files」エラーが発生したり、タイムアウトが発生したりします。高負荷時には、十分なプロセス数、余裕のある接続数、適切に増やされた rlimit_nofile、そして適切な OS パラメータという、調和のとれた一連の設定が必要です。そうすることで、rlimit_nofile が小さすぎるために 制限 全生産能力を削減した。.
worker_processes：数を適切に選択する
をセットした。 ワーカープロセス 通常は「auto」に設定し、NGINXが論理CPUコア数を認識して各コアを活用できるようにします。コアごとに1つのワーカーを割り当てることで、不要なコンテキスト切り替えを回避し、負荷を適切に分散できるため、応答時間を予測可能な範囲に抑えることができます。 コア数が非常に多いマシンでは、キャッシュヒット率とコア使用率を比較するために、意図的にワーカー数を少なくしてテストも行っています。メトリクスからコアが過負荷になっていることやTLBミスが増加していることが判明した場合は、ワーカー数を段階的に調整します。 まず測定し、それから変更する――そうすることで、信頼性の高い 結果.
worker_connections: 接続数を計画的に増やす
を選ぶ。 ワーカーコネクション ターゲットトラフィックやプロトコルの構成に応じて、多くの場合2048または4096から設定します。トラフィックの多いAPIについては、OSの制限やRAMの容量に問題がなければ、8192を検討します。 接続数の増加には毎回負荷テストで検証を行います。これは、開いている接続がメモリを占有し、アップストリームの挙動に影響を与えるためです。 SSLハンドシェイクや大容量のアップロードが主流の場合は、単なる接続数だけでなく、CPUやI/Oのプロファイルも参考にしています。これにより、ワーカーごとに定義された 定員 実際に利用可能な状態が維持される。.
worker_rlimit_nofile と OS の制限を同期させる
私は、次のように確実にする。 rlimit_nofile 少なくとも計算上の総容量をカバーし、多くの場合、予備容量を含めて設定されます。リバースプロキシのシナリオでは、クライアント接続1つにつき、アップストリームへの2つ目のディスクリプタを想定して計算します。それに応じて、rlimit_nofile は予想される同時接続数の2倍に設定するようにしています。 カーネルおよびユーザー制限（ulimit -n、fs.file-max）は、NGINXが実際にその値を利用できるよう、適切に引き上げます。エラーログにオープンファイルに関するメッセージが表示された場合は、速やかに制限値を引き上げ、状況を監視します。 レイテンシー 負荷をかけた状態で再度。.
イベントブロック：epoll と multi_accept を効果的に活用する
イベントブロックで有効にします epoll そして、multi_accept を「on」に設定し、ワーカーが待機中の接続を一括で受け入れるようにします。Epoll は、多数のソケットが同時に存在する際のオーバーヘッドを軽減し、非ブロッキング型の NGINX 設計と調和します。 これらの設定は、トラフィックのピーク時に効果を発揮します。接続受け入れフェーズを高速化し、実際の処理へより早く移行できるためです。Linux では、これが私の標準設定であり、ごく稀な特殊なケースを除いて変更することはありません。さらに深く理解したい方は、イベントループモデルを以下と比較してみてください。 スレッドプール対イベントループ そしてそこから 結論 自分の身の回りの環境のために。.
CPUアフィニティ：ワーカーをコアにバインドする
をセットした。 worker_cpu_affinity ワークロードが一定でCPUに依存している場合には、これを意図的に適用します。コンテキストスイッチを回避し、キャッシュの局所性を高めるため、割り当てスキームをビットマスクを用いて分散させます。 4コアのシステムでは、各ワーカーが独自のコアを割り当てられるようにマスクを配置します。その後、キャッシュミス率、中央値のレイテンシ、および99パーセンタイルを確認し、その効果を明確に把握します。アフィニティとNUMAに関する詳細な説明は、以下に簡潔にまとめられています。 CPUアフィニティの実践, これは微調整を行う際に 労働者-レイアウトが役立ちます。.
容量計画：ヘッドルームと負荷テスト
接続に関しては、私は バッファ 観測されたピーク値を大幅に上回る値を設定することで、一時的なトラフィックの急増によってリミットが直接突破されるのを防ぎます。ピーク負荷を基準値として2倍に設定しておけば、多くのシナリオにおいて十分な余裕が確保できます。 トラフィックの変動が激しい場合は、99パーセンタイルが安定して推移するまで、バッファをさらに拡大します。 その後、wrkやk6などのツールでボトルネックを確認し、エラー率を監視し、ステータスで未処理の接続を確認します。メトリクスが安定して初めて、個々のパラメータを的を絞って増減させます。 価値観.
設定と計算例
接続容量は、ワーカー数にワーカーあたりの接続数を乗じて算出し、そこから導き出された値よりも高い上限を設定しています。CPUコアが4つで「auto」設定、ワーカーあたり4096接続の場合、計算上は16384の同時接続数となります。 プロキシ環境では、アップストリームソケットも対象に含めるため、rlimit_nofileを32768以上にするようにしています。 2コアの小型マシンでは、アップロードやTLSの割合がそれほど高くない限り、ワーカーあたり2048接続で十分な場合が多いです。以下の表は、 開始値:
| CPUコア | ワーカープロセス | worker_connections (開始) | rlimit_nofile の最小値（目安） | ヒント |
|---|---|---|---|---|
| 2 | auto (≈2) | 2048 | 4096以上 | リザーブ TLS/プロキシ用にスケジュールを設定する |
| 4 | auto (≈4) | 4096 | 16384以上 | プロキシの場合、FDではしばしば係数が2となる |
| 8 | auto (≈8) | 4096-8192 | ≥ 32768 | 負荷テスト 増額について決定する |
| 16+ | 自動車、場合によってはそれ以下 | 8192+ | 65535以上 | 親近感と距離感を保ちながら試す |
NGINXのワーカーとアップストリーム：シナリオを適切に重み付けする
私は、静的配信、リバースプロキシ運用、およびAPIゲートウェイの負荷を区別しています。なぜなら、それらは 労働者-設定によって要件が異なります。静的コンテンツはリソースをあまり消費しませんが、TLS、圧縮、アップストリーム接続はCPUやFDをより多く消費します。SSL鍵が大きくなるほど、またハンドシェイク回数が増えるほど、「コアごとに1ワーカー」という設定の効果が顕著になります。 大規模なアップロードでは負荷の重点がI/Oに移るため、rlimit_nofileやネットワークバッファに注目するようになります。受信やバックエンドからの応答に目立った待ち時間が生じる場合は、以下の概要を確認することが役立ちます。 待ち行列と遅延, 、ボトルネックを解消するために ターゲット 解決する。.
実務ワークフロー：サーバーの高速化に向けたステップバイステップの手順
まずは、関連するすべての事項について現状把握を行うことから始めます 価値観 nginx.conf 内で、CPU コア数、ulimit、カーネルパラメータを確認します。その後、worker_processes を auto に設定し、worker_connections を例えば 4096 に設定し、rlimit_nofile を十分に大きくします。 Eventsブロックでは、epollとmulti_acceptを有効にし、リロードを行ってログを確認します。 続いて、再現可能な条件下で負荷テストを実施し、応答時間、エラー率、およびオープン接続数を監視します。微調整の段階では、常に1つの変数のみを変更し、各手順を記録するとともに、その影響を 指標.
ホスティング環境：リソース、カーネル、ネットワーク
十分な量を心がけています CPU- コア数、十分なRAM、高速なSSDまたはNVMe、そして最新のLinuxカーネル。これらが揃って初めて、epoll、最新のTCPスタック、そして実用的なオフロード機能が確実に動作します。 somaxconn や tcp_max_syn_backlog といったネットワークパラメータは、接続の目標数に合わせて調整し、受信キューを短く保つようにしています。 堅牢なI/O性能と自由に変更可能なシステム構成を備えたプロバイダーを選ぶことは、明らかにその価値があります。比較テストでは、安定した リソース NGINXの柔軟性を大幅に高める。.
キープアライブ戦略：クライアント接続とアップストリーム接続
私は、処理能力と遅延を調整する手段として、意図的にKeepaliveを活用しています。クライアント側では、 keepalive_timeout 高すぎないようにし、非アクティブなソケットが不必要に ワーカーコネクション ブロックする。10～30秒の範囲の値に設定すると、再利用性とリソースの占有量のバランスがうまく取れることが多い。 keepalive_requests 接続ごとのリクエスト数を制限し、長時間実行されるリクエストを遮断して、メモリ負荷を回避しています。アップストリーム側（リバースプロキシ）では、 keepalive アップストリーム・ブロック内でウォームアップされるため、ハンドシェイクやTCPのセットアップが不要になります。その際、バックエンドごとの数を、バックエンドの処理能力に合わせて控えめに設定しています（max_conns)、そうでなければ、アップストリーム側で自分でキューを回すことになる。重要：各キープアライブ・ソケットは開いている接続としてカウントされ、FDを消費する。この点については、 rlimit_nofile そして、ヘッドルームの計画も組み込みました。.
リストの最適化：reuseport、バックログ、およびAccept戦略
私は、次のようにして受入負荷を均等に分散させます。 SO_REUSEPORT 有効化（listen … reuseport）。これにより、各ワーカーは独自のAcceptキューを持つことになり、「サンダーリング・ハード」を軽減し、ホットスポットを回避できる。これと組み合わせて multi_accept これにより、受付の処理が著しくスピードアップします。リストのバックログ (listen … backlog=) およびカーネル側の対応する設定（somaxconn、tcp_max_syn_backlog）は、ソケットの受信側でトラフィックのピークが無駄にならないよう、余裕を持って設定しています。このオプション 延期 データが到着するまでAcceptを延期する――短命なリクエストが多い場合にはこれが役立つことがあるが、そうでない場合はテストで比較している。私が accept_mutex 必要かどうかはベンチマークで判断する。reuseportがあれば、たいていは不要だ。reuseportがない場合は、公平性を高めることができるが、調整の手間がかかる。ここではデータに基づいて判断し、決して直感で決めることはない。.
タイムアウトとキューを安定した設定にする
をセットした。 タイムアウト 低速なクライアントがワーカーの処理を妨げないように： client_header_timeout そして クライアント・ボディ・タイムアウト フリーズを防ぐために最小限に抑えつつ、実際のユーザーにとっては十分な余裕を持たせています。. send_timeout クライアントへの応答がブロックされるのを防ぎます。プロキシ環境では、次のように定義します。 プロキシ接続タイムアウト, proxy_read_timeout そして proxy_send_timeout 厳格に設定し、バックエンドの処理が滞ってもフロントエンドが機能停止しないようにします。並列処理能力に制限のあるバックエンドでは、私は queue アップストリーム・ブロックでタイムアウトを設定し、トラフィックの急増を緩和するとともに、すべてのワーカーを待機中のアップストリーム・ソケットにバインドする代わりに、制御された形で503エラーを返すようにしています。さらに、以下のようにして安定性を高めています。 limit_req (バースト／ディレイ) および limit_conn リソースを適切に配分する仕組みを設け、個々のクライアントやボットが過度にリソースを消費しないようにする。.
バッファリング、sendfile、およびAIO：I/O方式を意図的に選択する
をセットした。 sendfile 静的ファイル用に設定し、これを tcp_nopush/tcp_nodelay ワークロードに応じて、パケットを効率的に束ねたり、インタラクティブな遅延を抑えたりするために。大きなファイルの場合は、私は 直通 ある閾値以上の場合にのみ、キャッシュ汚染を防ぎ、ページキャッシュが上書きされないようにします。プロキシ動作時には、私が判断して proxy_buffering 役立つのか（クライアントへの高速な引き渡し、アップストリーム読み取りの分離）、あるいはストリーミング負荷の場合はむしろ proxy_request_buffering を削減し、アップロードを早めに開始するようにします。各ファイルのサイズは proxy_buffers, proxy_buffer_size そして large_client_header_buffers 接続ごとのメモリ使用量が爆発的に増えないよう、意識的に制御しています。CPUへの負荷を抑えるファイルアクセスについては、次のような方法を検討しています。 アイオ （ネイティブまたはスレッド）ですが、イベントループとI/Oの特性が互いに影響し合うため、十分にテストを行ってください。.
HTTP/2／HTTP/3 および TLS：ワーカーの処理能力への影響
私は次のことを考慮に入れている。 HTTP/2 そして HTTP/3 接続の動的挙動を変更する：多くのリクエストは ストリーム 少数のTCPまたはQUIC接続を使用します。これにより接続数は減少しますが、接続あたりのCPUおよびメモリ使用量は増加します（多重化、ヘッダー圧縮、TLS/QUIC）。私の ワーカーコネクション したがって、私はこれを単に「リクエスト数が同じ」と盲目的に解釈はしません。私が観察しているのは 並行ストリーム 各接続ごとに、そして適合して keepalive_timeout および必要に応じて. http2_max_concurrent_streams 。TLS側では、セッション再開（チケット／キャッシュ）とOCSPステープリングを活用することで、コストのかかるハンドシェイクを省き、遅延を低く抑えることができます。その反面、キープアライブ時間が長くなるとFDやRAMが占有されてしまうため、私は rlimit_nofile そして、現実的な予備容量を備えたメモリ割り当て。CPU負荷の高い暗号アルゴリズムについては、アフィニティ設定や最新の暗号処理アクセラレーションを用いたテストを行う価値がある。.
可観測性：ステータス、ログ、メトリクス
私はスリムな仕組みで透明性を確保しています ステータス-エンドポイント（例：stub_status）を使用して、アクティブな接続、読み取り／書き込み／待機状態、および受理されたリクエストを確認します。ログについては、ノイズを最小限に抑えています：簡潔な log_format 時間、ステータス、アップストリーム時間、バイト数といった情報があれば、ほとんどの分析には十分です。QPSが非常に高い場合は、I/Oによるパフォーマンス低下を防ぐため、アクセスログを（ロケーションに基づいて）選択的に無効にするか、ログを非同期でバッファリングします。エラーログについては、 警告 或いは エラー そして、特定の分析を行うためだけに、一時的に デバッグ. 私は継続的に、レイテンシ（中央値／95パーセンタイル／99パーセンタイル）、オープンコネクション、バックエンドのエラー率、およびワーカーごとのCPU使用率を相関分析しており、その結果に基づいて3つの主要なディレクティブの調整を行い、飽和効果を早期に検知しています。.
コンテナと仮想環境：制限を適切に引き継ぐ
コンテナ内で cgroup- CPU、RAM、PIDの上限を設定し、NGINXの設定と照らし合わせて調整してください。. ulimit -n コンテナ内で十分に高い値に設定する必要があります。そうしないと、rlimit_nofile の設定が無効になってしまいます。CPU クォータ（例：2 vCPU）の場合は、次のように設定します。 ワーカープロセス これにより、スケジューリングが不自然に詰め込まれるのを防ぎます。ネットワークに近い環境では、「ホスト」ネットワークモードによりオーバーヘッド遅延が低減されるメリットがありますが、オーバーレイではホップ数が増加します。 マルチNUMAホストでは、ワーカーがノードをまたがって動作しないよう、アフィニティとメモリスロットに注意を払っています。IRQおよびRPS/XPSアフィニティについても同様です。NICからIRQを経てワーカーのコアに至るパスが適切であれば、レイテンシのピークは測定可能なほど低減されます。.
接続のライフサイクル：一時的なポート、TIME_WAIT、およびリザーブ
十分な量を計画しています 一時的なポート (ip_local_port_range)は、NGINXがアップストリームに対してアクティブなクライアントとして動作する場合に設定します。接続スループットが非常に高い場合、アップストリーム・キープアライブを使用してポートの過度な変動を回避し、TIME_WAITスタックの縮小を図ります。 「再利用」に関するカーネルのトグル設定については、慎重に扱っています。最新のスタックでは、多くの部分が内部ですでに最適化されているためです。適切なキープアライブとタイムアウトの値を設定して接続の持続時間を制御する方が、より安定しています。 レツレポート 公平な配分のために活用する。キャパシティの算出にあたっては、クライアントに加え、常にアップストリーム側も考慮に入れている。多くの場合、実際のボトルネックとなるのはフロントドアではなく、アップストリーム側のFDである。.
中断のないスムーズなリロードとデプロイ
私はマスター／ワーカーモデルを以下の用途に利用しています。 スムーズな再読み込み: マスターが新しい設定を読み込むと、古いワーカーは停止し、新しいワーカーがシームレスに引き継ぐ。 ワーカーシャットダウンタイムアウト リクエストがリソースをブロックすることなく、正常に終了するまで時間を確保します。アップストリームでのゼロダウンタイムデプロイについては、ヘルスチェックと組み合わせ、 proxy_next_upstream- 個々のバックエンドに不具合が生じても、システム全体のレイテンシが上昇しないようにルールを設けています。設定を変更する際は、常に1つのパラメータのみを変更し、ログやメトリクスでその影響を確認しています。これにより、設定ミスを防ぎ、パフォーマンスの再現性を確保しています。.
簡潔な要約
接続します ワーカープロセス コア数（理想的には自動設定）に合わせて、ピーク負荷に応じたworker_connectionsを設定し、rlimit_nofileおよびOSの制限値を十分に大きく設定します。イベントブロックではepollとmulti_acceptを使用し、再現性のある負荷テストですべてを確認した上で、段階的に微調整を行います。 プロキシワークロードの場合は、追加のディスクリプタを見込みに含め、ワークロードが一定の場合はCPUアフィニティをテストします。適切なカーネル、高速なI/O、そして合理的なネットワークパラメータを備えた、適切に構成されたスタックが、大きな違いを生み出します。このようにして、私は NGINX 要求の厳しいページやAPIが必要とするパフォーマンス領域において、確実に動作します。.
