CPUあたりのユニコーンプロセスの最適数

Unicornの下でRuby on Rails Webアプリを実行しています。私たちのアプリは厳密にはCPUバウンドではありません（デュアルXeon E5645システムw / 12コアがあり、ピーク負荷平均値は約6です）。最初は40人のUnicornワーカーで開始しましたが、アプリケーションのメモリフットプリントは時間とともに増加しました。そのため、ワーカープロセスの数を減らす必要があります。標準（CPUコアの数+ 1）の式はUnicornにも適用されると思いましたが、同僚はCPUごとにさらに多くのUnicornインスタンスを予約する必要があると私に納得させ、このリンクを提供しました。しかし、アイドル状態のUnicornプロセスにこれほど多くのメモリを費やす必要があるのはなぜか、はっきりとはわかりません。

私の質問は、CPUコアごとに複数のUnicornインスタンスを持つ理由は何ですか？これは、ユニコーンの建築上の特殊性によるものですか？忙しいUnicornプロセスは新しい接続を受け入れられないことは承知しています（UNIXドメインソケットを使用して、UnicornインスタンスBTWと通信しています）が、これに対処するためにバックログが正確に導入されたと考えました。CPUルールごとにこの2〜8個のUnicornインスタンスを克服することは可能ですか？

さて、私は最終的に答えを見つけました。Unicornワーカーの最適な数は、CPUコアの数に直接関係しません。負荷と内部アプリの構造/応答性に依存します。基本的に、サンプリングプロファイラーを使用してワーカーの状態を判断し、ワーカーの70％をアイドル状態にし、30％が実際の作業を行うようにします。したがって、サンプルの70％は、「フロントエンドサーバーから要求を取得するためにselect（）呼び出しを待機する」必要があります。調査によると、労働者の有効な状態は3つのみです。サンプルの0〜30％がアイドルであり、サンプルの30〜50％がアイドルであり、サンプルの50〜70％がアイドルです（アプリケーションの応答性は大きく変わらないため、実際のポイントではありません）。0〜30％の状況を「レッドゾーン」、30〜50％の状況を「イエローゾーン」と見なします。

CPUにバインドされたジョブの場合、N + 1については正しいです。

一方、ユニコーンはスレッドを使用しないため、すべてのIO操作が行われます。プロセスをブロックし、別のプロセスが起動してHTTPヘッダーを解析し、文字列を連結し、ユーザーにサービスを提供するために必要なすべてのCPU集中タスクを実行します（要求の待ち時間を短縮するためにそれを早期に行います）。

また、コアよりも多くのスレッド/プロセスが必要になる場合があります。次の状況を想像してください。Aはreqの10倍以上かかります。B、複数の同時Aリクエストがあり、高速BリクエストがA-reqの完了を待機するだけでキューに入れられます。したがって、大量の要求の数を予測できる場合は、この数をシステムを調整する別のガイドラインとして使用できます。