IIS 8 を使用した NUMA ハードウェアでのマルチコア スケーリングについて
作成者: Kaori Sawada
Non-Uniform Memory Access (NUMA) は最新設計のコンピューター メモリ アクセスであり、対称型マルチプロセッサ (SMP) アーキテクチャのスケーラビリティ制限を克服するために設計されました。 SMP では、各コアが独自のバスと独自の I/O ハブにアクセスします。 SMP は多数の CPU (または CPU コア) ではうまく機能しません。それらが共有バスへのアクセスを競争するようになったためです。
NUMA は、1 つのメモリ バス上の CPU の数を制限し、高速相互接続で接続することで、このようなボトルネックを軽減するように設計されました。 これらの機能を利用するために、IIS 8 (Windows Server 2012 の一部) 以降で、NUMA ハードウェアのパフォーマンスを向上させる機能が提供されています。 これにより、IIS がワーカー プロセスを NUMA ノードにインテリジェントにアフィニタイズし、CPU の使用率を向上させることができます。
IIS 8 での新しい NUMA 関連オプション
管理者に高度な制御を提供するため、IIS 8 には次の 4 つの新機能/オプションがあり、それらは NUMA ハードウェアをサポートするサーバーで機能します。
- [プロセッサの関係]
- アフィニティ モード
- 最適な NUMA の選択
- Web ガーデン
[プロセッサの関係]
プロセッサ アフィニティは新しい機能ではありませんが、IIS 8 で強化されています。 smpProcessorAffinityMask および smpProcessorAffinityMask2 属性は IIS 7 以降で使用できるようになっており、管理者がこれらを使用してアプリケーション プールを特定のコアにアフィニタイズできます。 その目的は IIS 8 でも変わりませんが、64 個を超える論理プロセッサ (LP) をサポートするために、IIS 8 に次の新しいスキーマ要素が導入されました。
<element name="cpu">
...
<attribute name="smpAffinitized" type="bool" defaultValue="false"/>
<attribute name="smpProcessorAffinityMask" type="uint" defaultValue="4294967295"/>
<attribute name="smpProcessorAffinityMask2" type="uint" defaultValue="4294967295"/>
<attribute name="processorGroup" type="int" defaultValue="0" validationType="integerRange"
validationParameter="0,2147483647"/>
...
</element>
* IIS 8 での変更箇所が強調表示されています
Note
64 個を超える LP をサポートするために、プロセッサ グループという新しい概念が導入されました。 64 個を超える LP があるすべてのマシンには、必然的に複数のプロセッサ グループがあります。 1 つのプロセッサ グループは LP の静的なセットであり、単一のスケジューリング エンティティとして扱われます。 オペレーティング システムが起動すると、プロセッサ グループを作成し、それらに論理プロセッサを割り当てます。 プロセッサ グループには、0 から始まる番号が付けられます。
smpProcessorAffinityMask および smpProcessorAffinityMask2 が 64 ビット (それぞれが 32) を提供するため、processorGroup 属性を使用すると、最大 64 のコアがあるシステム上でアプリケーション プールをアフィニタイズできます。 2 つの関係マスクを使用して 10 進プロセッサ マスクが構成されます。10 進プロセッサ マスクは、アプリケーション プール内のワーカー プロセスをどの CPU にバインドすべきかを示します。 たとえば、64 個のプロセッサのコンピューターがあり、8 番目、15 番目、26 番目、32 番目、40 番目、48 番目、60 番目のプロセッサを有効にする場合は、次のように 16 進プロセッサ マスクを計算します。
プロセッサの識別は 0 から開始して右から左へ行われるので、バイナリでは、最初の 32 プロセッサのプロセッサ 8、15、26、32 は次のように識別されます。
1000 0010 0000 0000 0100 0000 1000 0000
この数値が 10 進数に変換されると smpProcessorAffinityMask になります。
0x82004080
2 番目の 32 プロセッサのセットのプロセッサ 40、48、60 も次のように識別されます。
0000 1000 0000 0000 1000 0000 1000 0000
この数値が 10 進数に変換されると smpProcessorAffinityMask2 になります。
0x8008080
これら 2 つの関係マスクの型は uint (符号なし 32 ビット整数) のため、合計 64 個のアドレス指定可能ビットが提供され、最大 64 個のプロセッサを指定できます。 アプリケーション プールの複数のプロセッサ グループへのアフィニタイズをサポートする場合、または 64 を超えるプロセッサがある場合は、processorGroup 属性によってこのような状況を表します。 番号が 0 の processorGroup を参照する場合、対応する AffinityMask 値は最初のグループ (番号 0 から 63) に適用されます。 processorGroup 1 を参照する場合、マスク値は 2 番目 (番号 64 から 127) に適用されます。 アプリケーション プールを LP に関連付けるプロセッサ グループは 1 つしか指定できません。 次の例は、マスク値が 2 番目のプロセッサ グループ (グループ 1) にのみ適用されることを示しています。 このアプリケーション プール内のワーカー プロセスが、最初のプロセッサ グループ (グループ 0) の LP で実行されることはありません。
applicationHost.config に対して構成する例を次に示します。.
<applicationPools>
<add name="DefaultAppPool">
<cpu smpAffinitized="true" smpProcessorAffinityMask="82004080"
smpProcessorAffinityMask2="8008080" processorGroup="1" />
</add>
</appricationPools>
Note
LP 64 個よりプロセッサ数が少ない場合でも、2 つを超えるプロセッサ グループを構成できます。
https://msdn.microsoft.com/library/ff542298(VS.85).aspx
このシナリオでは、smpProcessorAffinityMask および smpProcessorAffinityMask2 属性の一部のビットは無視されます。
次の図は、アプリケーション プールの詳細構成ダイアログでマスクを構成する方法を示しています。
この構成が使用されるとき、アプリケーション プールは "ハード アフィニタイズ" され、他の NUMA ノードには影響しません。 テストでは、ハード アフィニティはソフト アフィニティよりも高いスループット (1 秒あたりの要求数 (RPS) で測定) を提供すると示されています。
Note
processorGroup が受け入れられるのは、AffinityMasks と共に使用してプロセスをコアに手動でアフィニタイズする場合のみです。
アフィニティ モード
プロセスのコア ノードまたは NUMA ノードへのアフィニタイズに際して、次の 2 つのアフィニティ モードが使用可能です。
- ハード アフィニティ。 プロセスはコア (または NUMA ノードを構成する複数のコア) にアフィニタイズされ、プロセスのすべてのスレッドがアフィニタイズされたコアによって実行されます。 他のコアに余分な CPU サイクルがあるかどうかに関係なく、スレッドがシステム上の他のコアによって実行されることはありません。 スレッドは、アフィニタイズされたコア内に含まれます。
- ソフト アフィニティ。 プロセスはコア (または NUMA ノードを構成する複数のコア) に "優先コア" としてアフィニタイズされます。 スレッドの実行がこれからスケジュールされる場合、"優先コア" が最初に検討されますが、システム上の他のコアの負荷と可用性によっては、そのスレッドがシステム上の他のコアでスケジュールされる可能性があります。 多くの場合、この動作は、ソフト アフィニタイズされていない他のコアに スレッドが "スピル オーバー" する "スピル オーバー" 効果として説明されます。
アフィニティ モードを構成するために次の新しいスキーマ要素が IIS 8 に導入されました。
<element name="cpu">
...
<attribute name="numaNodeAffinityMode" type="enum" defaultValue="Soft">
<enum name="Soft" value="0" />
<enum name="Hard" value="1" />
</attribute>
</element>
管理者は、インターネット サービス マネージャーを使用して numaNodeAffinityMode 属性を構成することもできます。
既定ではアプリケーション プールはソフト アフィニタイズされます。ほとんどのシナリオに対してより "寛大な" 構成であるためです。 smpProcessorAffinityMask および smpProcessorAffinityMask2 属性をインテリジェントに構成できるほど高度な場合には、システムのノード レイアウトに合わせてハード/ソフト アフィニティを構成するとパフォーマンスを向上させることができます。
最適な NUMA の選択
既定では、Windows は、単純な "ラウンドロビン" アルゴリズムを使用して、各プロセスをシステム内の次の NUMA ノードに割り当てます。 このため、既定では、可能であれば常に特定のプロセスのスレッドは同じ NUMA ノード内で実行されるようになります。 ただし、IIS 8 では、リモート NUMA ノード上のメモリへのアクセスを最小限に抑えるために、別のスケジュール アルゴリズムを使用します。 最適な NUMA の選択とは、まもなくインスタンス化されるワーカー プロセスのためにパフォーマンスを向上させることができる NUMA ノードを IIS 8 が選択する機能を指します。 IIS 8 にはこの構成のために 次の 2 つのオプションがあります。
MostAvailableMemory。 WAS によって開始されるワーカー プロセス用のスケジューリング アルゴリズムであり、使用可能なメモリが最も多いノード上にプロセスがスケジュールされます。 これは、リモート NUMA ノード上のメモリへのアクセスを最小限に抑えるのに役立ちます。 最初のワーカー プロセスは、どの NUMA ノードの使用可能な (空き) メモリが最も多いかに基づいて選択されます。 残りのワーカー プロセスは、ラウンドロビン方式でアフィニタイズされます。
Note
numaNodeAffinityMode 属性が適用されるのは MostAvailableMemory がある場合のみです。
WindowsScheduling。 既定では、オペレーティング システムは、NUMA システムに対して、"ラウンドロビン" アルゴリズムを使用してシステム内の次の NUMA ノードに各プロセスを割り当てます。 ワーカー プロセスが均等に分散されるのは、Windows がこの "ラウンドロビン" アルゴリズムに基づいて NUMA ノードを選択し、プロセスを NUMA ノードにソフト アフィニタイズするためです。
Note
numaNodeAffinityMode 属性は WindowsScheduling と一緒には適用できません。それ自体が IIS 実装ではなく Windows 実装であるためです。
これらのオプションの構成は、新しいスキーマ オプションを使用して行われます。
<element name="cpu">
...
<attribute name="numaNodeAssignment" type="enum" defaultValue="MostAvailableMemory">
<enum name="MostAvailableMemory" value="0"/>
<enum name="WindowsScheduling" value="1"/>
</attribute >
...
</element>
管理者は、インターネット サービス マネージャーを使用して numaNodeAssignment 属性も構成できます。
この仕組み
8 個の NUMA ノードと 4 プロセスの Web ガーデンがある構成を考えてみましょう。 numaNodeAssignment 属性が MostAvailableMemory に設定された場合、NUMA ノード 2 が最適な NUMA ノードとして選択されて、最初の 4 プロセスがアフィニタイズされると、後続のプロセスは NUMA ノード 3、ノード 4、ノード 5 に順にアフィニタイズされます。
| NUMA 0 | NUMA1 | NUMA2 | NUMA3 | NUMA4 | NUMA5 | NUMA6 | NUMA7 |
|---|---|---|---|---|---|---|---|
| IIS w3wp | IIS w3wp | IIS w3wp | IIS w3wp |
同様に最初の 4 プロセスに NUMA ノード 6 が選択された場合、後続のプロセスは NUMA ノード 7、0、1 に順にアフィニタイズされます。
| NUMA 0 | NUMA1 | NUMA2 | NUMA3 | NUMA4 | NUMA5 | NUMA6 | NUMA7 |
|---|---|---|---|---|---|---|---|
| IIS w3wp | IIS w3wp | IIS w3wp | IIS w3wp |
Web ガーデン
IIS 8 以降では Web ガーデンの動作も少し変わりました。 IIS 7.5 (Windows Server 2008 R2 付属) では、maxProcesses 属性の値は 1 から始まりましたが、IIS 8 ではこの値は 0 から始まるようになりました (ただし既定値は 1 のままです)。 スキーマでは次のようになります。
<element name="processModel">
...
<attribute name="maxProcesses" type="uint" defaultValue="1" validationType="integerRange"
validationParameter="0,2147483647" />
...
</element>
当然、これは GUI で構成することもできます。
NUMA 以外のハードウェアでこの構成を 0 に設定すると、既定値の 1 が使用されます。 NUMA ハードウェアでこれを 0 に設定すると、IIS はシステム上の NUMA ノードと同じ数のワーカー プロセスを起動するため、ワーカー プロセスと NUMA ノードの間に 1 対 1 のアフィニティがあります。 このようなシステムでは、最大パフォーマンスを実現するために maxProcesses 値を 0 に設定する必要があります。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示