Ausführen einer Anwendung über zwei Knoten mit Windows Server mit NUMA

971
RandomInsano

Ich hatte heute ein interessantes Gespräch mit einem Kunden. Wir haben eine Anwendung, die andere Apps plant, und normalerweise haben wir keine Probleme mit Servern mit NUMA-Konfiguration mit 2 bis 4 Knoten.

Während des Anrufs haben wir zwei sehr CPU-hungrige Anwendungen in Betrieb genommen, und beide wurden dem Knoten 0 zugewiesen, so dass der gesamte Computer nur zu 50% ausgelastet war. Nachdem wir die zweite App-Instanz auf den anderen Knoten geändert hatten, verwendeten wir alle Kerne (die Hälfte einer App, die andere Hälfte). Es schien unmöglich, allen Kernen eine App zuzuordnen.

Nun, der einzige Unterschied zwischen diesem Computer und denjenigen, die ich gewohnt bin, ist, dass der Task-Manager von Windows die Knoten in einer Dropdown-Liste anstatt einer langen Liste einzelner Kerne auflistet. Microsoft weiß also, was diese Einschränkung ist, aber es ist ein schwieriges Problem, online zu recherchieren.

Es ist ziemlich klar, dass wir eine NUMA-Knotenaffinität entwickeln müssen, aber im Moment versuche ich, das Problem zu verstehen. Was kann dazu führen, dass ein NUMA-Computer-Stil es beiden Anwendungen erlaubt, beide Knoten transparent zu verwenden, und was verursacht dieses Verhalten jetzt?

Ich kann mir vorstellen, dass diese Architektur für viele kleine Anwendungen gut funktioniert, aber normalerweise werden monolithische mit vielen Threads ausgeführt.

Der Server, mit dem ich kämpfe, ist ein HP Proliant DL388Gen9 mit zwei Intel Xeon E5-2690V3-CPUs.

Gedanken darüber, was das verursacht?

1

2 Antworten auf die Frage

1
dyasta

Ein Prozess kann nur einem einzelnen NUMA-Knoten zugeordnet werden. Das ist die kurze Antwort. Sie können keine einzelne Instanz zur Ausführung auf mehr als einem NUMA-Knoten erzwingen. Dies ist angesichts des Zwecks von NUMA und des sekundären Zweckes sinnvoll, bei einem Betriebssystem, das 64-Bit-CPU-Affinitätsbitmasken verwendet,> 64 CPU-Kerne zuzulassen.

1
Dragontamer5788

Ich bin kein Experte in dieser Angelegenheit, aber ich stimme meiner Meinung zu.

Es ist ziemlich klar, dass wir eine NUMA-Knotenaffinität entwickeln müssen, aber im Moment versuche ich, das Problem zu verstehen. Was kann dazu führen, dass ein NUMA-Computer-Stil es beiden Anwendungen erlaubt, beide Knoten transparent zu verwenden, und was verursacht dieses Verhalten jetzt?

Ich weiß, dass Windows eine "Knotenentfernung" berechnet, um die Zeit zu schätzen, die verschiedene NUMA-Knoten für die Kommunikation miteinander benötigen. Ich weiß nicht, ob es sich um Latenz oder Bandbreite handelt (oder vielleicht beides), aber es ist wichtig zu wissen.

Moderne Maschinen wie Skylake-Server können über "SubNuma-Clustering" verfügen, wobei verschiedene Teile desselben Chips als unterschiedliche NUMA-Knoten gemeldet werden. Der Unterschied zwischen Knoten innerhalb desselben Chips beträgt jedoch ~ 10 Nanosekunden. Während ein anderer Sockel ~ 200 Nanosekunden haben kann.

Beispiel: Zwei Xeon Golds (20 Kerne pro CPU) mit aktiviertem Sub-NUMA-Clustering würden für Windows wie 4x NUMA-Knoten aussehen. 2-NUMA-Knoten pro Chip, die die "linken" 10 Kerne und die "rechten" 10 Kerne auf jeder Chiphälfte darstellen. Links 3x Speichercontroller, rechts 3x Speichercontroller. Alle 20 Kerne können jedoch in ~ 80 Nanosekunden mit einem der Speichercontroller kommunizieren. Sie können in 70 Nanosekunden einfach mit dem "näheren" Speichercontroller sprechen. Ein kaum wahrnehmbarer Unterschied, daher zieht es Windows wahrscheinlich vor, Threads über diese beiden NUMA-Knoten zu schweben.

Ich gehe davon aus, dass Windows unter den Standardeinstellungen Ihres Setups entschieden hat, dass ein "Node Distance" kurz genug war, um Threads zu schweben, während bei den anderen Setups die Speicherabstände so lang waren, dass die Standardeinstellungen von Windows bevorzugt werden die Threads innerhalb eines NUMA-Knotens.

Das ist nicht meine einzige Theorie. Meine zweite Theorie besagt, dass bei "Processor Groups" etwas Seltsames vor sich geht. Prozessorgruppen sind ein fehlerhafter Kompatibilitäts-Hack der Win32-API, da CPU-Affinitätsmasken aus Leistungsgründen auf 64 Bit beschränkt sind. Daher sind 64 logische Kerne die maximale Standardeinstellung von Windows.

Sie können über die Prozessorgruppen-API auf mehr als 64 logische Kerne zugreifen. https://msdn.microsoft.com/de-de/library/windows/desktop/dd405503(v=vs.85).aspx

Kurz gesagt: Wenn sich Ihre Prozesse in separaten "Prozessorgruppen" befinden, können Sie als Programmierer das Programm so ändern, dass es Prozessorgruppen unterstützt.

Ich habe nicht viel mit diesem Zeug persönlich getestet. Aber hoffentlich sind dies nützliche Informationen für Sie.

Verwandte Probleme