Verständnis der Multicore-Skalierung auf NUMA-Hardware mit IIS 8

by Kaori Sawada

Nicht einheitlicher Speicherzugriff (NUMA) ist ein modernes Design für den Computerspeicherzugriff, der die Skalierbarkeitsgrenzwerte der symmetrischen SMP-Architektur (Symmetric Multi-Processor, SMP) überwinden soll. In SMP greift jeder Kern auf seinen eigenen Bus und seinen eigenen E/A-Hub zu. SMP funktioniert nicht gut mit einer großen Anzahl von CPUs (oder CPU-Kernen), da sie für den Zugriff auf den gemeinsam genutzten Bus im Wettbewerb stehen.

NUMA wurde entwickelt, um solche Engpässe zu verringern, indem die Anzahl der CPUs auf einem einzigen Speicherbus begrenzt und mit einer Hochgeschwindigkeitsverbindung verbunden wird. Um diese Funktionen zu nutzen, bietet IIS 8 (Teil von Windows Server 2012) und höher Features zur Verbesserung der Leistung auf NUMA-Hardware an. Dadurch kann IIS Arbeitsprozesse intelligent an NUMA-Knoten anbinden und eine bessere Auslastung der CPUs bieten.

Neue NUMA-bezogene Optionen in IIS 8

Um dem Administrator ein hohes Maß an Kontrolle zu bieten, verfügt IIS 8 über die folgenden vier neuen Features/Optionen, die auf Servern zur Verfügung gestellt werden, die NUMA-Hardware unterstützen:

• Prozessoraffinität
• Affinitätsmodus
• Optimale NUMA-Auswahl
• Web Gardens

Prozessoraffinität

Die Prozessoraffinität ist kein neues Feature, wurde jedoch in IIS 8 verbessert. Die Attribute smpProcessorAffinityMask und smpProcessorAffinityMask2 sind seit IIS 7 verfügbar und ermöglichen es dem Administrator, einen Anwendungspool an einem bestimmten Kern anzubinden. Ihr Zweck bleibt mit IIS 8 identisch, aber die folgenden neuen Schemaelemente wurden in IIS 8 eingeführt, um mehr als 64 logische Prozessoren (LPs) zu unterstützen:

<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>

* Änderungen für IIS 8 sind hervorgehoben

Hinweis

Um mehr als 64 LPs zu unterstützen, wurde ein neues Konzept eingeführt: Prozessorgruppe. Jeder Computer mit mehr als 64 LPs verfügt nach Bedarf über mehrere Prozessorgruppen. Eine einzelne Prozessorgruppe ist eine statische Gruppe von LPs und wird als einzelne Planungsentität behandelt. Wenn das Betriebssystem gestartet wird, erstellt es die Prozessorgruppen und weist ihnen logische Prozessoren zu. Prozessorgruppen werden beginnend mit 0 nummeriert.

Da smpProcessorAffinityMask und smpProcessorAffinityMask2 64 bits (jeweils 32) bieten, kann das processorGroup-Attribut verwendet werden, um Anwendungspools an ein System mit bis zu 64 Kernen anzubinden. Die beiden Affinitätsmasken werden verwendet, um die Dezimalprozessormaske zu konfigurieren, und das Dezimalprozessorformat gibt an, an welche CPU die Arbeitsprozesse in einem Anwendungspool gebunden werden sollen. Wenn Sie beispielsweise über einen Computer mit 64 Prozessoren verfügen und die 8. , 15. , 26. , 32. , 40., 48. und 60. Prozessoren aktivieren möchten, würden Sie die Hexadezimalprozessormaske wie folgt berechnen.

Die Prozessoridentifikation beginnt bei 0, von rechts nach links. In binär würden Sie also Prozessoren 8, 15, 26 und 32 für die ersten 32 Prozessoren bestimmen als:

1000 0010 0000 0000 0100 0000 1000 0000

Diese Zahl, die in eine Dezimalzahl konvertiert wird, ist Ihr smpProcessorAffinityMask:

0x82004080

Sie würden auch Prozessoren 40, 48 und 60 für die zweite Gruppe von 32 Prozessoren bestimmen als:

0000 1000 0000 0000 1000 0000 1000 0000

Diese Zahl, die in eine Dezimalzahl konvertiert wird, ist Ihr smpProcessorAffinityMask2:

0x8008080

Da der Typ dieser beiden Affinitätsmasken uint ist, was eine nicht signierte 32-Bit-Ganzzahl ist, bieten sie insgesamt 64 adressierbare Bits an, sodass Sie bis zu 64 Prozessoren angeben können. Um die Affinität des Anwendungspools auf mehr als 1 Prozessorgruppe zu unterstützen, oder es mehr als 64 Prozessoren gibt, gibt es ein processorGroup-Attribut für diese Situationen. Wenn Sie auf eine processorGroup mit der Nummer 0 verweisen, gelten die entsprechenden AffinityMask-Werte für die erste Gruppe, die mit 0 bis 63 nummeriert ist. Wenn Sie auf processorGroup 1 verweisen, gelten die Maskenwerte für die zweite Gruppe, die mit 64 bis 127 nummeriert ist. Sie können nur eine Prozessorgruppe angeben, um den Anwendungspool an LPs anzubinden. Das folgende Beispiel zeigt, dass die Maskenwerte nur für die zweite Prozessorgruppe, die Gruppe 1, gelten. Jeder Arbeitsprozess in diesem Anwendungspool wird niemals auf LPs in der ersten Prozessorgruppe, der Gruppe 0, ausgeführt.

Im Folgenden sehen Sie das Beispiel für die Konfiguration der applicationHost.config.

<applicationPools>
   <add name="DefaultAppPool">
      <cpu smpAffinitized="true" smpProcessorAffinityMask="82004080" 
      smpProcessorAffinityMask2="8008080" processorGroup="1" />
   </add>
</appricationPools>

Hinweis

Sie können mehr als 2 Prozessorgruppen konfigurieren, auch wenn weniger Prozessoren als 64 LPs vorhanden sind.

https://msdn.microsoft.com/library/ff542298(VS.85).aspx

In diesem Szenario werden einige Bits von smpProcessorAffinityMask- und smpProcessorAffinityMask2-Attributen ignoriert.

Die folgende Abbildung zeigt, wie Sie die Maske im erweiterten Konfigurationsdialogfeld des Anwendungspools konfigurieren können.

Wenn diese Konfiguration verwendet wird, sind die ApplicationPools fest gebunden, was bedeutet, dass es keine Auswirkungen auf andere NUMA-Knoten gibt. Bei Tests wurde gezeigt, dass „feste Affinität (fest gebunden)“ einen höheren Durchsatz als weiche Affinität bietet, was in Anforderungen pro Sekunde (RPS) gemessen wird.

Hinweis

Die processorGroup wird nur berücksichtigt, wenn sie mit AffinityMasks verwendet wird, um einen Prozess manuell an einen Kern zu binden.

Affinity MODE

Bei der Affinität eines Prozesses zu einem Kern- oder NUMA-Knoten sind zwei Affinitätsmodi möglich:

1. Feste Affinität. Ein Prozess ist an einen Kern (oder Kerne, die einen NUMA-Knoten bilden) gebunden, und alle Threads für den Prozess werden vom gebundenen Kern ausgeführt. Die Threads können nicht von den anderen Kernen auf dem System ausgeführt werden, unabhängig davon, ob die anderen Kerne zusätzliche CPU-Zyklen aufweisen oder nicht. Die Threads sind innerhalb des gebundenen Kerns enthalten.
2. Weiche Affinität. Ein Prozess wird an einen Kern (oder Kerne, die einen NUMA-Knoten bilden) als „bevorzugten Kern“ gebunden. Wenn ein Thread geplant wird, der ausgeführt werden soll, wird der „bevorzugte Kern“ zuerst betrachtet, aber je nach Auslastung und Verfügbarkeit der anderen Kerne im System, wird der Thread möglicherweise auf den anderen Kernen des Systems geplant. Dieses Verhalten wird häufig als „Überlaufeffekt“ beschrieben, bei dem die Threads auf die anderen nicht weich gebundenen Kerne „überlaufen“.

Das folgende neue Schemaelement wurde in IIS 8 zum Konfigurieren der Affinitätsmodi eingeführt:

<element name="cpu">
 ...
 <attribute name="numaNodeAffinityMode" type="enum" defaultValue="Soft">
 <enum name="Soft" value="0" />
 <enum name="Hard" value="1" />
 </attribute>
</element>

Der Administrator kann auch das numaNodeAffinityMode-Attribut mit dem Internet Service Manager konfigurieren.

Anwendungspools sind standardmäßig weich gebunden, da es sich bei den meisten Szenarien um eine „weichere“ Konfiguration handelt. Wenn Sie fortgeschritten genug sind, um die Attribute smpProcessorAffinityMask und smpProcessorAffinityMask2 intelligent konfigurieren zu können, kann die Konfiguration der fest/weich Affinität im Einklang mit dem Knotenlayout des Systems die Leistung verbessern.

Optimale NUMA-Auswahl

Standardmäßig weist Windows jedem Prozess den nächsten NUMA-Knoten im System mithilfe eines einfachen Roundrobin-Algorithmus zu. Dadurch wird sichergestellt, dass die Threads für einen bestimmten Prozess standardmäßig nach Möglichkeit innerhalb desselben NUMA-Knotens ausgeführt werden. IIS 8 ermöglicht jedoch einen anderen Planungsalgorithmus, um den Zugriff auf den Arbeitsspeicher auf Remote-NUMA-Knoten zu minimieren. Optimale NUMA-Auswahl bezieht sich auf eine Funktionalität, in der IIS 8 einen NUMA-Knoten auswählt, der eine bessere Leistung für einen Arbeitsprozess bereitstellen sollte, der gerade instanziiert werden soll. Für diese Konfiguration gibt es zwei Optionen in IIS 8:

1. MostAvailableMemory. Der Planungsalgorithmus für Arbeitsprozesse, die von WAS gestartet wurden, wodurch der Prozess auf dem Knoten mit dem verfügbarsten Arbeitsspeicher geplant wird. Dies trägt dazu bei, den Zugriff auf den Arbeitsspeicher auf einen Remote-NUMA-Knoten zu minimieren. Der erste Arbeitsprozess wird basierend darauf ausgewählt, welcher NUMA-Knoten den verfügbarsten (kostenlosen) Arbeitsspeicher aufweist. Die restlichen Arbeitsprozesse werden auf Roundrobin-weise gebunden.

   Hinweis

   Das Attribut numaNodeAffinityMode gilt nur für MostAvailableMemory.

2. WindowsScheduling. Das Betriebssystem weist standardmäßig jedem Prozess den nächsten NUMA-Knoten im System mithilfe eines „Roundrobin“-Algorithmus auf einem NUMA-System zu. Die Arbeitsprozesse werden gleichmäßig verteilt, da Windows den NUMA-Knoten basierend auf diesem „Roundrobin“-Algorithmus auswählt und die Prozesse weich an NUMA-Knoten bindet.

   Hinweis

   Das Attribut numaNodeAffinityMode gilt nicht für WindowsScheduling, da es sich hierbei nicht um eine IIS-Implementierung, sondern um eine Windows-Implementierung selbst handelt.

Die Konfiguration dieser Optionen erfolgt mithilfe neuer Schemaoptionen:

<element name="cpu">
 ... 
 <attribute name="numaNodeAssignment" type="enum"   defaultValue="MostAvailableMemory">
 <enum name="MostAvailableMemory" value="0"/>
 <enum name="WindowsScheduling" value="1"/>
 </attribute >
 ... 
</element>

Der Administrator kann das numaNodeAssignment-Attribut auch mit dem Internet Service Manager konfigurieren.

So funktioniert's

Erwägen Sie eine Konfiguration, in der es 8 NUMA-Knoten und einen Web Garden mit vier Prozessen gibt. Wenn die NumaNodeAssignment-Attribute auf MostAvailableMemory festgelegt sind und NUMA Node 2 als optimaler NUMA-Knoten für die ersten der 4 Prozesse ausgewählt und gebunden ist, werden die nachfolgenden nacheinander an NUMA Node 3, Node 4 und Node 5 gebunden:

NUMA 0	NUMA1	NUMA2	NUMA3	NUMA4	NUMA5	NUMA6	NUMA7
		IIS w3wp	IIS w3wp	IIS w3wp	IIS w3wp

Wenn NUMA Node 6 für den ersten der vier Prozesse ausgewählt wird, werden die nachfolgenden nacheinander an NUMA Node 7, 0 und 1 in Folge gebunden:

NUMA 0	NUMA1	NUMA2	NUMA3	NUMA4	NUMA5	NUMA6	NUMA7
IIS w3wp	IIS w3wp					IIS w3wp	IIS w3wp

Web Gardens

Das Web Garden-Verhalten in IIS 8 und höher hat sich ebenfalls etwas geändert. In IIS 7.5 (das mit Windows Server 2008 R2 ausgeliefert wurde), beginnt der Wert für das Attribut maxProcesses von 1 und mit IIS 8 jetzt mit 0 (obwohl der Standardwert noch 1!) ist. So sieht es im Schema aus:

<element name="processModel">
 ...
 <attribute name="maxProcesses" type="uint" defaultValue="1" validationType="integerRange"
 validationParameter="0,2147483647" />
 ... 
</element>

Natürlich ist dies auch mit der GUI konfigurierbar:

Wenn diese Konfiguration auf 0 auf Nicht-NUMA-Hardware festgelegt ist, wird der Standardwert 1 verwendet. Wenn sie auf 0 auf NUMA-Hardware festgelegt ist, startet IIS so viele Arbeitsprozesse wie NUMA-Knoten auf dem System, sodass eine 1:1-Affinität zwischen den Arbeitsprozessen und NUMA-Knoten vorhanden ist. Auf solchen Systemen sollten Sie den maxProcesses-Wert auf 0 festlegen, um eine maximale Leistung zu erzielen.