私はnginxのではデフォルトとして以下のように '上' 'accept_mutex' ですが見つかりました:Nginxでは 'accept_mutex'がデフォルトで 'on'になっていますか?
次に接続がミューテックスを必要と受け入れていますか?どうして?
私はnginxのではデフォルトとして以下のように '上' 'accept_mutex' ですが見つかりました:Nginxでは 'accept_mutex'がデフォルトで 'on'になっていますか?
次に接続がミューテックスを必要と受け入れていますか?どうして?
いくつかのプロセスが1つのポートでリッスンし、epollで待機するとします。 mutexを許可しないと、すべてのプロセスが起動しますが、1つだけが接続を受け入れることができます。他のプロセスは非生産的に目を覚ました。 よく知られていますhttp://en.wikipedia.org/wiki/Thundering_herd_problem
しかし、それは物語の終わりではありません。
多くの場合、または常に失敗したコンテキストスイッチになります受け入れる: http://en.wikipedia.org/wiki/Lock_convoy
私のテストはせずに、ミューテックスを受け入れる失われた5〜10%の性能を示します。
更新: "accept mutex"は受け入れの周りにmutextロックされていません。 ワーカー間のサーバーポートのリスニングをシリアライズするために使用されるテクノロジの名前です。 1つのワーカーが指定されたポートを一瞬でリッスンします。
mutexを受け入れる方が効率的なら、なぜオフのオプションがありますか?それはいつ有用でしょうか? –
私が知っているように、受け入れミューテックスや他のモジュール/構成に関してはめったに問題はありませんでした。場合によってはaccept_mutesをoffに設定すると役に立ちます。 –
'accept_mutex off;を有効にすると、qpsの数が>> 10kの場合、待ち時間を数十ミリ秒短縮できます – SaveTheRbtz
nginxメインラインバージョン1.11.3(リリース日:2016-07-26)、accept_mutex
now defaults to off
。これは、新しいEPOLLEXCLUSIVE
フラグが余分なオーバーヘッドなしでaccept_mutex
の利点を提供するためです。
はい。 mutexを使用して新しい接続をシリアル化します。ここにいくつかの情報があります:http://nginx.org/ja/docs/ngx_core_module.html#accept_mutexしかし、それ以上のことを知りたいです。 –
FYI: 'accept_mutex'はデフォルトで' off'sinceになりましたNginx 1.11.3(https://nginx.org/en/CHANGES) – Sicco