スレッドプール：NGINX 9回以上の高速化

ご存じのとおり、NGINXは非同期イベントアプローチを使用して接続を処理します。 （従来のアーキテクチャのサーバーが行うように）各リクエストに個別のスレッドまたはプロセスを割り当てる代わりに、NGINXは単一のワークフローで複数の接続とリクエストの処理を多重化します。 このため、ソケットは非ブロッキングモードで使用され、 epollやkqueueなどのイベントを処理する効果的な方法が使用されます。



フルウェイトの処理フローは少数で一定であるため（通常はコアごとに1つ）、メモリとプロセッサリソースは切り替えコンテキストで節約されます。 NGINXの例でこのアプローチのすべての利点を十分に観察できます。NGINX自体は、数百万のリクエストを同時に処理でき、拡張性に優れています。







各プロセスはメモリを消費し、プロセスを切り替えるたびに追加のプロセッササイクルが必要になり、Lキャッシュのリーチングにもつながります。



コインには欠点もあります。 非同期アプローチの主な問題、または「敵」と言った方がよいのは、操作をブロックすることです。 そして、残念ながら、NGINXの機能の原理を理解していないサードパーティモジュールの多くの作成者は、モジュールでブロッキング操作を実行しようとします。 このような操作は、NGINXのパフォーマンスを完全に損なう可能性があるため、いかなる場合でも回避する必要があります。



しかし、現在のNGINX実装でも、ロックを回避することが常に可能とは限りません。 そして、この問題を解決するために、NGINXバージョン1.7.11は「スレッドプール」の新しいメカニズムを導入しました。 それが何であるか、そしてそれをさらに適用する方法を分析し、最初に敵を直接知ることになります。

問題

問題をよりよく理解するために、NGINXがどのように機能するかに関する主要なポイントを最初に詳細に調べます。



動作原理によれば、NGINXはそのようなイベントハンドラーであり、接続で発生したすべてのイベントに関する情報をカーネルから受け取り、オペレーティングシステムに何をするかを指示するコントローラーです。 実際、NGINXはシステムリソースを操作する最も困難なタスクを解決し、オペレーティングシステムはすべてのルーチンを実行し、情報のバイトを読み取り、送信します。 したがって、NGINXワークフローがイベントにどれだけ迅速かつタイムリーに応答するかが重要です。







ワークフローは、カーネルからイベントを受信して​​処理します。



このようなイベントには、タイマーイベント、新しいデータの到着、応答の送信、バッファ内のスペースの解放、接続エラーまたはそのクローズの通知があります。 NGINXはそのようなイベントのパケットを受信し、順番に処理を開始し、必要なアクションを実行します。 したがって、イベントキューのすべての処理は、1つのスレッドで単純なサイクルで行われます。 NGINXはキューからイベントを次々と抽出し、ソケットへのデータの書き込みや読み取りなどのいくつかのアクションを実行します。 ほとんどの場合、これは非常に迅速に行われるため（ほとんどの場合、メモリ内の少量のデータをコピーするだけです）、すべてのイベントを瞬時に処理することを検討できます。







すべての処理は、1つのスレッドで単純なサイクルで行われます。



しかし、ある種の長くて難しい操作を実行しようとするとどうなりますか？ イベントループ全体が、この操作の完了を待機しなくなります。



したがって、ブロッキング操作とは、イベント処理のサイクルを大幅に遅らせる操作を意味します。 操作は、さまざまな理由でブロッキングと呼ばれることがあります。 たとえば、NGINXは長時間の計算集約的な操作でビジーであるか、何らかのリソース（ハードディスク、ミューテックス、ライブラリ呼び出し、同期モードでのデータベースからの応答を待機するなど）へのアクセスを期待する場合があります。 ここで重要なのは、これらの操作中、ワークフローは他に役立つことは何もできず、他のイベントを処理できないことです。ただし、多くの場合、まだ空きリソースがあり、キューでさらに待機しているイベントはそれらを使用できます。



巨大な買い手が並んでいる店の売り手を想像してください。 そして今、列の最初の人がチェックアウトカウンターに近づき、窓にはないが遠くの倉庫にある商品を購入したいと考えています。 売り手は数時間待つように頼み、商品の倉庫に向けて出発します。 並んでいる他の顧客の反応を想像できますか？ 待機時間はこれら2時間増加しましたが、多くの場合、必要なものはカウンターの上に数メートルあります。







ライン全体は、最初のバイヤーの注文の実行を待機せざるを得ません。



NGINXでも同様の状況が発生します。送信されるファイルがメモリ内ではなく、ハードドライブ上にある場合です。 ディスクは低速であり（特に回転するディスク）、キューで処理されるのを待機している他の要求はハードドライブへのアクセスを必要としない場合がありますが、それでも待機する必要があります。 その結果、遅延が増大し、システムリソースが完全に利用されない場合があります。







1回のブロッキング操作で、後続のすべての処理が大幅に遅延する可能性があります。



一部のオペレーティングシステムは、ファイルを非同期で読み取るためのインターフェイスを提供し、NGINXはそれらを効率的に使用できます（ aioディレクティブの説明を参照）。 そのようなシステムの良い例は、FreeBSDです。 残念ながら、Linuxでも同じことは言えません。 Linuxにはファイルを読み取るための特定の非同期インターフェイスがありますが、多くの重大な欠点があります。 そのような要件の1つは、読み取りとバッファーのアライメントです。 NGINXはこれにうまく対処できますが、2番目の問題はさらに深刻です。 非同期読み取りでは、ファイル記述子にO_DIRECT



フラグを設定する必要があります。 これは、すべてのデータがオペレーティングシステムのページキャッシュ（いわゆるページキャッシュ ）をバイパスしてディスクから読み取られることを意味します。多くの場合、これは最適ではなく、ディスクサブシステムの負荷が大幅に増加します。



特に、この問題を解決するために、NGINX 1.7.11はスレッドプールの新しいメカニズムを導入しました。 これらはまだNGINX Plusに含まれていませんが、スレッドプールを使用してNGINX Plus R6アセンブリを試してみたい場合は、営業部門にお問い合わせください。



そして、それらが何であり、どのように機能するかをより詳細に分析します。

スレッドプール

不運な売り手に戻りましょう。 しかし、今回は彼はより機知に富んでいることがわかりました（または、怒った顧客にbeatられた後ですか？）そして、宅配便を組織しました。 現在、バイヤーがカウンターにない商品を要求すると、カウンターを離れるのではなく、自分で商品を探して他の全員に待たせ、商品の配達要求を宅配便に送信して、顧客の列にサービスを提供し続けます。 したがって、ストアに注文がなかった買い手のみが配達を待っており、その間、売り手は問題なく残りにサービスを提供できます。







クーリエによる注文処理は、キューをブロックしません。



NGINXの場合、スレッドプールはクーリエとして機能します。 ジョブキューと、このキューを処理する個々の軽量スレッドのセットで構成されます。 ワークフローは、それ自体で行うのではなく、潜在的に長い操作を必要とする場合、処理タスクをプールキューに入れ、そこから任意のフリーストリームがすぐに処理を開始できます。







ワークフローは、ブロッキング処理をスレッドプールに送信します。



ここで別のターンが形成されたようです。 そうです。 ただし、この場合、このキューは特定のリソースに制限されます。 彼ができるよりも速くディスクから読み取ることはできませんが、少なくとも読み取りを待つことで、他のイベントの処理が遅れることはありません。



ディスクからの読み取りは、ブロッキング操作の最も一般的な例として取り上げられていますが、実際には、NGINXのスレッドプールは、メインワークサイクル内で実行するのが非合理的な他のタスクに使用できます。



現在、スレッドプールへのアップロード操作は、ほとんどのオペレーティングシステムのread（）システムコール、およびLinuxのsendfile（）に対してのみ実装されています。 この問題の調査を継続し、おそらくパフォーマンスが向上する場合は、今後、スレッドプールによる他の操作の実行を実装する可能性があります。

パフォーマンスのテスト

理論から実践へと移行する時が来ました。 スレッドプールを使用した効果を示すために、簡単な実験を行います。 つまり、ディスクアクセスでのブロッキングの問題が完全に明らかになったときに、NGINXにブロッキングとノンブロッキングの読み取りの混合を実行させる、最も難しい条件を再現します。



これには、オペレーティングシステムのキャッシュに収まらないことが保証されているデータセットが必要です。 RAM容量が48 GBのマシンでは、ランダムデータを含む各4 MBの256 GBのファイルが生成され、NGINXバージョン1.9.0が起動してそれらを配布しました。



構成は非常に簡単です。

 worker_processes 16; events { accept_mutex off; } http { include mime.types; default_type application/octet-stream; access_log off; sendfile on; sendfile_max_chunk 512k; server { listen 8000; location / { root /storage; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、最高のパフォーマンスを得るために少し調整が行われました。ロギングが無効になり、 accept_mutexが無効になり、 sendfileがオンになり、 sendfile_max_chunkが設定されます。 後者を使用すると、 sendfile()



呼び出しのロック時間を短縮できます。この場合、NGINXは一度にファイル全体の読み取りと送信を試行せず、512キロバイトの部分で実行するためです。



このマシンには、2つのIntel Xeon E5645プロセッサ（合計12コア、24のHyperThreadingスレッド）と10 GBネットワークインターフェイスが装備されています。 ディスクサブシステムは、RAID10アレイに結合された4台のWestern Digital WD1003FBYXハードドライブで構成されています。 これらはすべて、Ubuntu Server 14.04.1 LTSオペレーティングシステムによって制御されます。





テストベッド構成。



顧客は特性が似ている2台のマシンです。 それらの1つはwrkを実行し、Luaスクリプトで一定の負荷を作成します。 スクリプトは、200の並列接続を使用して、ストレージからファイルをランダムな順序で要求します。 この負荷を寄生と呼びます。



別のクライアントマシンからwrk



を実行し、50個のスレッドで同じファイルを要求します。 このファイルは常にアクセスされているため、ランダムな順序で要求されたファイルとは異なり、オペレーティングシステムのキャッシュから洗い落とされる時間がなく、その読み取りは常にメモリから行われます。 これを負荷テストと呼びます。



サーバー上のifstat



インジケータと2番目のクライアントマシンからのwrk



統計によってパフォーマンスを測定します。



そのため、スレッドプールを使用しない最初の実行では、非常に控えめな結果が示されます。

 % ifstat -bi eth2 eth2 Kbps in Kbps out 5531.24 1.03e+06 4855.23 812922.7 5994.66 1.07e+06 5476.27 981529.3 6353.62 1.12e+06 5166.17 892770.3 5522.81 978540.8 6208.10 985466.7 6370.79 1.12e+06 6123.33 1.07e+06
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この構成を見るとわかるように、このような負荷の下で、サーバーは毎秒約1ギガビットを発行できます。 同時に、上部では、ほとんどの場合、すべてのNGINXワークフローがI / Oでブロックされた状態にあることがわかります（文字D



マークされています）。

 top - 10:40:47 up 11 days, 1:32, 1 user, load average: 49.61, 45.77 62.89 Tasks: 375 total, 2 running, 373 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.3 sy, 0.0 ni, 67.7 id, 31.9 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 49453440 total, 49149308 used, 304132 free, 98780 buffers KiB Swap: 10474236 total, 20124 used, 10454112 free, 46903412 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4639 vbart 20 0 47180 28152 496 D 0.7 0.1 0:00.17 nginx 4632 vbart 20 0 47180 28196 536 D 0.3 0.1 0:00.11 nginx 4633 vbart 20 0 47180 28324 540 D 0.3 0.1 0:00.11 nginx 4635 vbart 20 0 47180 28136 480 D 0.3 0.1 0:00.12 nginx 4636 vbart 20 0 47180 28208 536 D 0.3 0.1 0:00.14 nginx 4637 vbart 20 0 47180 28208 536 D 0.3 0.1 0:00.10 nginx 4638 vbart 20 0 47180 28204 536 D 0.3 0.1 0:00.12 nginx 4640 vbart 20 0 47180 28324 540 D 0.3 0.1 0:00.13 nginx 4641 vbart 20 0 47180 28324 540 D 0.3 0.1 0:00.13 nginx 4642 vbart 20 0 47180 28208 536 D 0.3 0.1 0:00.11 nginx 4643 vbart 20 0 47180 28276 536 D 0.3 0.1 0:00.29 nginx 4644 vbart 20 0 47180 28204 536 D 0.3 0.1 0:00.11 nginx 4645 vbart 20 0 47180 28204 536 D 0.3 0.1 0:00.17 nginx 4646 vbart 20 0 47180 28204 536 D 0.3 0.1 0:00.12 nginx 4647 vbart 20 0 47180 28208 532 D 0.3 0.1 0:00.17 nginx 4631 vbart 20 0 47180 756 252 S 0.0 0.1 0:00.00 nginx 4634 vbart 20 0 47180 28208 536 D 0.0 0.1 0:00.11 nginx 4648 vbart 20 0 25232 1956 1160 R 0.0 0.0 0:00.08 top 25921 vbart 20 0 121956 2232 1056 S 0.0 0.0 0:01.97 sshd 25923 vbart 20 0 40304 4160 2208 S 0.0 0.0 0:00.53 zsh
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、すべてがディスクサブシステムのパフォーマンスに依存しますが、プロセッサはほとんどの時間アイドル状態です。 wrk



結果も残念です。

 Running 1m test @ http://192.0.2.1:8000/1/1/1 12 threads and 50 connections Thread Stats Avg Stdev Max +/- Stdev Latency 7.42s 5.31s 24.41s 74.73% Req/Sec 0.15 0.36 1.00 84.62% 488 requests in 1.01m, 2.01GB read Requests/sec: 8.08 Transfer/sec: 34.07MB
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メモリからファイルを1つだけ配布する場合でも、大幅な遅延が発生します。 すべてのワークフローはディスクからの読み取りでビジーであり、スプリアスロードを作成する最初のマシンから200の接続を提供し、これらのテスト要求をタイムリーに処理できません。



次に、スレッドプールを接続します。このために、ストレージを使用してlocation



ブロックにaio threads



ディレクティブを追加します。

 location / { root /storage; aio threads; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、NGINXに設定を再読み込みするよう依頼します。



テストを繰り返します。

 % ifstat -bi eth2 eth2 Kbps in Kbps out 60915.19 9.51e+06 59978.89 9.51e+06 60122.38 9.51e+06 61179.06 9.51e+06 61798.40 9.51e+06 57072.97 9.50e+06 56072.61 9.51e+06 61279.63 9.51e+06 61243.54 9.51e+06 59632.50 9.50e+06
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、サーバーは9.5ギガビット/秒（スレッドプールなしで〜1ギガビット/秒）を発行します！



それはおそらくより多くを与える可能性がありますが、これは特定のネットワークインターフェイスの実際的な制限であり、NGINXはネットワーク帯域幅に依存します。 ワークフローは、ほとんどの時間、イベントを待機してスリープします（状態S



）。

 top - 10:43:17 up 11 days, 1:35, 1 user, load average: 172.71, 93.84, 77.90 Tasks: 376 total, 1 running, 375 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.2 us, 1.2 sy, 0.0 ni, 34.8 id, 61.5 wa, 0.0 hi, 2.3 si, 0.0 st KiB Mem: 49453440 total, 49096836 used, 356604 free, 97236 buffers KiB Swap: 10474236 total, 22860 used, 10451376 free, 46836580 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4654 vbart 20 0 309708 28844 596 S 9.0 0.1 0:08.65 nginx 4660 vbart 20 0 309748 28920 596 S 6.6 0.1 0:14.82 nginx 4658 vbart 20 0 309452 28424 520 S 4.3 0.1 0:01.40 nginx 4663 vbart 20 0 309452 28476 572 S 4.3 0.1 0:01.32 nginx 4667 vbart 20 0 309584 28712 588 S 3.7 0.1 0:05.19 nginx 4656 vbart 20 0 309452 28476 572 S 3.3 0.1 0:01.84 nginx 4664 vbart 20 0 309452 28428 524 S 3.3 0.1 0:01.29 nginx 4652 vbart 20 0 309452 28476 572 S 3.0 0.1 0:01.46 nginx 4662 vbart 20 0 309552 28700 596 S 2.7 0.1 0:05.92 nginx 4661 vbart 20 0 309464 28636 596 S 2.3 0.1 0:01.59 nginx 4653 vbart 20 0 309452 28476 572 S 1.7 0.1 0:01.70 nginx 4666 vbart 20 0 309452 28428 524 S 1.3 0.1 0:01.63 nginx 4657 vbart 20 0 309584 28696 592 S 1.0 0.1 0:00.64 nginx 4655 vbart 20 0 30958 28476 572 S 0.7 0.1 0:02.81 nginx 4659 vbart 20 0 309452 28468 564 S 0.3 0.1 0:01.20 nginx 4665 vbart 20 0 309452 28476 572 S 0.3 0.1 0:00.71 nginx 5180 vbart 20 0 25232 1952 1156 R 0.0 0.0 0:00.45 top 4651 vbart 20 0 20032 752 252 S 0.0 0.0 0:00.00 nginx 25921 vbart 20 0 121956 2176 1000 S 0.0 0.0 0:01.98 sshd 25923 vbart 20 0 40304 3840 2208 S 0.0 0.0 0:00.54 zsh
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、プロセッサリソースはまだ十分に供給されています。



2番目のマシンのwrk



結果：

 Running 1m test @ http://192.0.2.1:8000/1/1/1 12 threads and 50 connections Thread Stats Avg Stdev Max +/- Stdev Latency 226.32ms 392.76ms 1.72s 93.48% Req/Sec 20.02 10.84 59.00 65.91% 15045 requests in 1.00m, 58.86GB read Requests/sec: 250.57 Transfer/sec: 0.98GB
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

4 MBファイルの平均アップロード時間は、7.42秒から226.32ミリ秒に短縮されました。 〜33倍、1秒間に処理されるリクエストの数は31倍（8に対して250）増加しました！



これは、ワークフローがディスクからの読み取りをブロックされている間、リクエストが処理のためにキューで待機することはなくなり、空きスレッドによって処理されるようになったという事実によって説明されます。 そして、ディスクサブシステムができる限りジョブを実行し、最初のマシンから「偽の」トラフィックを処理しますが、NGINXは残りのプロセッサリソースとネットワーク帯域幅を使用して、メモリから2番目のクライアントを処理します。

特効薬は存在しません

ブロック操作とそのような驚くべき結果に関するすべての恐ろしい話の後、あなたの多くはおそらく彼らのサーバーでスレッドプールをオンにしたいと思うでしょう。 急がないでください。



幸いなことに、ほとんどの場合、ファイル操作は低速のハードドライブからの読み取りにはつながりません。 十分なRAMがある場合、最新のオペレーティングシステムは、いわゆるページキャッシュで頻繁にアクセスされるファイルをキャッシュするのに十分スマートです。



ページキャッシュは非常によく処理され、これにより、NGINXは常に最も一般的な状況で高いパフォーマンスを発揮することができました。 ページキャッシュからの読み取りは非常に迅速に行われ、この操作をブロッキングと呼ぶことはできません。 同時に、スレッドプールとの対話には、追加の同期コストがかかります。



したがって、十分なRAMと少量のホットデータがあれば、すでに問題はなく、NGINXはスレッドプールを使用せずに最適な方法で動作します。



実際、読み取り操作を別のスレッドプールにアンロードすると、かなり狭い範囲のタスクが解決されます。 定期的に要求されるデータの量がRAMに収まらない状況に限定されるため、オペレーティングシステムのページキャッシュが非効率的になります。 そのような例は、負荷の高いメディア配信サービスです。 この状況をテストでシミュレートしました。



読み取り操作のスレッドプールへのアンロードは、必要なデータがメモリ内にあるかどうかを事前に確認する効果的な方法があれば、読み取り操作に対してより汎用的になり、遅延を減らします。後者の場合のみ、操作を別のストリームにアンロードします。



店舗と遠く離れた倉庫の例えに戻ると、売り手は商品が窓にあることを知る機会がなく、常に宅配便を利用せざるを得ません。



実際には、オペレーティングシステムのカーネルからの対応するサポートはありません。 最初に、この機能をfincore（）システムコールの形式でLinuxに追加しようと試みましたが、2010年に遡りますが、「まだあります」。 後にpreadv2()



システムコールおよびRWF_NONBLOCK



フラグの形式で試行が行われました（詳細は、LWN.netのノンブロッキングバッファーファイル読み取り操作および非同期バッファー読み取り操作の記事に記載されています ）-しかし、これらのパッチの運命は依然として疑問です。 このすべてのせいが悪名高い自転車運転 （フェルトペンの匂いの色についての議論）であるように思われるのは悲しいことです。



FreeBSDユーザーは心配する必要はありませんが、カーネルに実装された正常に機能する非同期読み取りメカニズムを持っています。 スレッドプールの代わりに使用することをお勧めします。

構成

そのため、タスクのスレッドプールから利益を得ることができると確信している場合は、スレッドプールを有効にして構成する方法に関する疑問が必ず生じます。



構成は非常にシンプルであると同時に非常に柔軟です。 まず、-with --with-threads



フラグでコンパイルされたNGINXバージョン1.7.11以降が必要です。 最も単純なケースでは、セットアップは基本的に見えます。 読み取りおよびファイルのスレッドプールへのダウンロードを可能にするために必要なのは、スレッドに設定されたhttp



、 server



またはlocation



レベルのaio



ディレクティブだけです。

 aio threads;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、スレッドプールを構成するための最小のオプションです。 実際、これはこの構成の短縮バージョンです。

 thread_pool default threads=32 max_queue=65536; aio threads=default;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

default



スレッドプールを設定しdefault



。32個のスレッドが機能し、ジョブキューの最大許容サイズは65536です。ジョブキューがいっぱいの場合、NGINXはリクエストを拒否し、エラーを記録します。

 thread pool "NAME" queue overflow: N tasks waiting
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、スレッドが作業量に対応せず、キューが処理されるよりも早く満たされる場合に可能です。 この場合、最大キューサイズを増やすことを試みることができます。これが役に立たない場合、システムは単純にそのような多数のリクエストを処理できません。



ご覧のとおり、 thread_poolディレクティブを使用して、スレッド数、最大キューサイズ、およびこのスレッドプールの名前を設定できます。 後者には、複数の独立したプールを構成し、それらを異なるタスクの構成の異なる部分で使用する機能が含まれます。

 thread_pool one threads=128 max_queue=0; thread_pool two threads=32; http { server { location /one { aio threads=one; } location /two { aio threads=two; } } … }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プール2のようにmax_queue



パラメーターmax_queue



明示的に指定されていない場合、デフォルト値の65536が使用されます例からわかるように、キューサイズをゼロに設定できます。 その後、プールは、空きスレッドと同数のジョブのみを同時に受け入れることができ、キューで待機しているジョブはありません。



ここで、バックエンドのキャッシュプロキシとして機能する3台のハードドライブを備えたサーバーがあるとします。 同時に、推定キャッシュサイズは、使用可能なRAMの量の何倍にもなります。 本質的に、これは個人のコンテンツ配信ネットワーク（CDN）上のキャッシュノードのようなものです。 この場合、キャッシュされたデータを返す際の主な負担はディスクサブシステムにあります。 もちろん、利用可能な3つのドライブから最大のパフォーマンスを引き出す必要があります。



ここでの解決策の1つは、RAIDアレイの編成です。 もちろん、このアプローチには長所と短所があります。 しかし、今日NGINXはあなたに異なるアプローチを提供する準備ができています：

 #             : # /mnt/disk1, /mnt/disk2  /mnt/disk3  thread_pool pool_1 threads=16; thread_pool pool_2 threads=16; thread_pool pool_3 threads=16; http { proxy_cache_path /mnt/disk1 levels=1:2 keys_zone=cache_1:256m max_size=1024G use_temp_path=off; proxy_cache_path /mnt/disk2 levels=1:2 keys_zone=cache_2:256m max_size=1024G use_temp_path=off; proxy_cache_path /mnt/disk3 levels=1:2 keys_zone=cache_3:256m max_size=1024G use_temp_path=off; split_clients $request_uri $disk { 33.3% 1; 33.3% 2; * 3; } server { … location / { proxy_pass http://backend; proxy_cache_key $request_uri; proxy_cache cache_$disk; aio threads=pool_$disk; sendfile on; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この構成では、3つの独立したキャッシュを使用します。各ハードドライブに1つと、ディスクにも3つの独立したスレッドプールです。



キャッシュ（および、それに応じてハードドライブ）間で負荷を均等に分散するには、 split_clientsモジュールを使用します。これはこれに最適です。



use_temp_path=off



ディレクティブのuse_temp_path=off



パラメーターは、 use_temp_path=off



に、キャッシュデータが置かれているのと同じディレクトリに一時ファイルを保存するように指示します。 これは、応答をキャッシュに保存するときに、あるドライブから別のドライブにデータをコピーすることを避けるためです。



これらすべてを組み合わせることで、NGINXは個別のスレッドプールを介して各ディスクと並行して独立して対話するため、このディスクサブシステムから最大のパフォーマンスを引き出すことができます。 各ディスクは16の独立したストリームによって処理され、ファイルの読み取りと送信のためのタスクの個別のキューが形成されます。



結局のところ、あなたの顧客は個々のアプローチが好きですか？ ハードドライブも確認してください。 ;）



この例は、ハードウェアを直接構成する際のNGINXの非常に高い柔軟性のデモです。 NGINXに、このサーバーとデータのディスクサブシステムと最適に対話する方法を指示しています。 そして、このような微調整は、ユーザーレベルまでのソフトウェアが最も最適な方法で機器と連携するときに、特定のシステムのすべてのリソースの最も効率的な使用を保証します。

結論

スレッドプールは、非同期アプローチの主な有名な敵であるブロッキング操作と戦う素晴らしいメカニズムです。これにより、NGINXは、特に非常に大量のデータについて話している場合に、新しいレベルのパフォーマンスを取ることができます。



前述のように、スレッドプールは他の操作に使用でき、非同期インターフェイスを持たないライブラリを操作できます。潜在的に、これにより、モジュールと機能の実装の新しい可能性が開かれますが、パフォーマンスを損なうことなく実装することは、以前は妥当な時間では実現できませんでした。既存のライブラリの非同期バージョンを作成するか、そのようなインターフェイスを追加しようとすると、多くの労力と時間を費やすことができますが、「ゲームには価値がありますか？」という疑問が生じました。スレッドプールを使用すると、ブロックコールで動作するモジュールを作成し、NGINXがメインタスクを実行して残りのリクエストを処理することなく、このタスクをはるかに簡単に解決できます。



そのため、NGINXには将来、多くの新しく興味深いものが待っています。私たちと一緒にいてください！