Nginx worker_connectionsは、ワーカープロセスで開くことができる同時接続の最大数を設定します。この数には、クライアントとの接続だけでなく、すべての接続（たとえば、プロキシサーバーとの接続など）が含まれます。現在開いているファイルの最大数の制限を超えることはできません。」これに関するクエリはほとんどありません。

1. これに最適な値または推奨値は何ですか？
2. 多数のワーカー接続を使用することのマイナス面は何ですか？

実用的なアプローチを取りましょう。

これらの制限はすべて、ハードウェアが低速で高価であった前世紀にハードコーディングおよび設計されたものです。2016年になりました。平均的なウォールマートトースターは、デフォルト値よりも多くのリクエストを処理できます。

デフォルト設定は実際には危険です。ウェブサイトに何百人ものユーザーがいることは印象的ではありません。

worker_process

関連する設定です。トピックについて説明します。

ロードバランサーとしてのnginx：

• HTTPロードバランシング用の1つのワーカー。
• HTTPSロードバランシング用のコアごとに1つのワーカー。

Webサーバーとしてのnginx：

これはトリッキーです。

一部のアプリケーション/フレームワーク/ミドルウェア（php-fpmなど）は、nginxの外部で実行されます。その場合、1つのnginxワーカーで十分です。通常、外部アプリケーションが重い処理を実行してリソースを消費しているためです。

また、一部のアプリケーション/フレームワーク/ミドルウェアは、一度に1つのリクエストしか処理できず、それらをオーバーロードするのはバックファイアです。

一般的に、1人の労働者は常に安全な賭けです。

それ以外の場合、自分が何をしているのかわかっている場合は、コアごとに1つのワーカーを配置できます。そのルートは最適化であると考え、適切なベンチマークとテストをアドバイスします。

worker_connections

接続の合計量はですworker_process * worker_connections。ロードバランサーモードでは半分。

これでトースター部分に到達しました。多くの深刻な過小評価されているシステム制限があります。

• ulimitsは、Linuxではプロセスごとに最大1k個のオープンファイルです（一部のディストリビューションでは1kソフト、4kハード）
• systemdの制限は、ulimitsとほぼ同じです。
• nginxのデフォルトはワーカーごとに512接続です。
• 他にもあるかもしれません：SELinux、sysctl、supervisord（それぞれのdistro + versionはわずかに異なります）

1k worker_connections

安全なデフォルトは、1kをどこにでも置くことです。

それは、ほとんどの内部および未知のサイトがこれまでに遭遇するよりも十分に高いです。他のシステム制限に達しないほど十分に低いです。

10,000人のworker_connections

特に公開Webサイトの場合、何千ものクライアントが存在することは非常に一般的です。デフォルト値が低いため、ダウンしたウェブサイトの数のカウントを停止しました。

実稼働で許容される最小値は10kです。それを許可するには、関連するシステムの制限を増やす必要があります。

高すぎる制限などはありません（ユーザーがいない場合、制限は単に効果がありません）。ただし、制限が低すぎると、ユーザーが拒否され、サイトがデッドになります。

10k以上

10kは素晴らしく簡単です。

任意の1000kkの制限を設定することはできます（結局は制限です）が、それはあまり実用的ではなく、そのトラフィックを取得できず、とにかくそれを取得できません。

合理的な設定として10kに固執しましょう。より多くの（そして実際にできる）サービスには、特別なチューニングとベンチマークが必要です。

特別なシナリオ：高度な使用法

時々、サーバーにあまりリソー​​スがないことがわかっており、あまり処理できないスパイクが発生することが予想されます。試すよりもユーザーを拒否したいです。その場合は、適切な接続制限を設定し、適切なエラーメッセージと処理を構成します。

バックエンドサーバーは正常に動作している場合もありますが、ある程度の負荷までしか機能しません。サーバーをクラッシュさせるよりも遅くしたいです。その場合は、厳しい制限でキューイングを設定し、リクエストが制限されたペースで排出されている間、nginxがすべての熱をバッファリングするようにします。

ulimit -a システムでプロセスが使用できるファイルをいくつ開いているかがわかります。

また、net.ipv4.ip_local_port_rangeIPごとに有効にするソケットの合計範囲を設定します。

そのため、TCPキューの合計サイズworker_connectionsまで、クライアント接続はこれらのいずれよりも多くなることはできませんnet.core.netdev_max_backlog。

逆プロキシとしてnginxを使用している場合、接続ごとに2つのソケットを使用することに注意してください。net.ipv4.tcp_fin_timeoutソケットの状態をすばやく切り替えるために、他のカーネルtcp関連のタイムアウトを少し試してみることをお勧めします。別の注意点は、各ソケットがTCPメモリスタックのメモリを割り当てることです。またsysctl、を使用してTCPメモリスタックの制限を設定することもできます。CPUと十分なファイルハンドラがある限り、RAMにより多くの圧力をかけることができます。

参考までに、十分なコンピューティングリソースがあれば、約32GBのRAMを備えた1台のサーバーと、sysctlを使用したカーネルチューニングで1MMの同時接続を処理する仮想ネットワークインターフェイスを使用できます。私のテストでは、1MM以上を処理し、約700バイトのペイロードを送信すると、サーバーは約1.2MMの同時クライアントを更新するのに約10秒かかりました。次に、いくつかの追加のNICを結合し、仮想NICを捨てることにより、ネットワーク帯域幅を増やしました。ペイロード、帯域幅、およびすべてのクライアントを更新するのに妥当な時間を考えると、1.2MM以上のクライアントとの擬似リアルタイム通信を実現することが可能です。

ハッピーチューニング！

適切なサイジングは、Nginxが処理しているトラフィックのタイプに基づいて変化するため、テストを通じて発見できます。

理論的には、nginxは次を処理できます：max clients = worker_processes * worker_connections（* = multiply）およびworker_processes =プロセッサー数

プロセッサを見つけるには、次を使用します。grep processor / proc / cpuinfo | wc -l

リソースに制約がある場合は、下限を設定すると便利です。たとえば、キープアライブ接続（クライアントだけでなく、アップストリームサーバーとも）などの一部の接続は、（nginxが非常に効率的であっても）リソースを効率的に浪費しているため、必要ありません汎用サーバーの適切な操作。つまり、それらを安全に削除して、残りの操作でより多くのリソースを使用できるようにすることができます。

したがって、リソース制限を低くすると、nginxに物理リソースが不足している可能性があり、利用可能なリソースを新しい接続に割り当てる必要があります。より差し迫ったニーズに応えます。

推奨値は何ですか？これがデフォルトです。

デフォルトはすべてドキュメント内に文書化されています。

デフォルト：worker_connections 512;

そして、することが可能で、ソースコードレベルで確認event/ngx_event.c、あまりにも、

13＃define DEFAULT_CONNECTIONS 512

マルセルの答えは本当に支持される必要があります！ulimitsが約1kのデフォルト値に設定されている場合、max_connectionsを同じ値に設定する必要があります。そうしないと、max_connectionsを10kに設定してもメリットがありません。

「worker_connectionsがそれ以上にならない場合、またはクライアント接続がnet.core.netdev_max_backlog-TCPキューの合計サイズ」になると、nginxでキューに入れられたリクエストとソケットが閉じられます。

ulimitsが許可するように、単一のプロセスが接続のように開くことができます。num_workers * max_connectionsは式ですが、妥当な値を得るには、外部のロードバランサー/プロキシの最大接続とulimitを考慮する必要があります。max_connectionを非常に高い値に設定すると、ulimitが制限要因になるため、逆効果になる可能性があります。