NUMA/vNUMA I/O sensitive switch high

[Login]

Hallo,

für eine extreme Ausnahmesituation wird eine Server2019 1809 VM mit 96GB vRAM und 16 vCPUs benötigt.

Der VM creation wizard schlägt mir 8 Sockel mit jeweils 2 CPUs vor. Ich bin mir nicht sicher, ob das noch "wide and flat" bzw. die optimale Konfig ist. Die Software ist zu allem übel noch extrem latenzempfindlich, sodass ich Sockel-übergreifenden Speicherzugriff und sonstige NUMA-Probleme tunlichst vermeiden will.

Kurz zur Hardware:

2x DL380 g10, 512GB Ram, 2x Gold 6254 an SAS DAS MSA 2052

Die VM liegt auf der MSA auf einem dedizierten Raid10 aus 6 SSDs

ESXi 7.0u1

Danke euch schon mal im Voraus!

[irix]

Die CPU hat doch 18 Cores. Ich wuerde es da mit 16 vCPU ala 16 vCore x 1vSocket versuchen..

Gruss
Joerg

PS: 16 vCPU und 96G vMEM ist nicht gross.

[Login]

Hi Jörg,

danke dir! Das war auch mein erster Gedanke. Ist es in dem Fall normal, dass der Taskmanager bei 16x 1 sockel in Windows trotzdem 2 NUMA nodes anzeigt?

Seltsamerweise belegt die VM in dieser Konfig laut esxtop tatsächlich CPUs auf beiden physikalischen Sockeln, das hat mich gewundert. Ich meine gelesen zu haben, dass der CPU scheduler die vCPUs innerhalb eines NUMA nodes zur Verfügung stellt, wenn der I/O sensitive switch auf high steht, das scheint aber nicht der Fall zu sein.

Die VM genießt im Moment auch einen kompletten Host, um Ressourcen zanken muss sie also nicht.

Vielleicht habe ich ja auch irgendwo einen Denkfehler.

Gruß,
conne

PS: VMs mit mehr als 8 vCPUs kommen bei uns relativ selten vor, sodass ich mir bisher auch noch nicht all zu viele Gedanken über NUMA/vNUMA und vor allem derartige Latenz-Themen gemacht habe. Und weil hier im Forum immer sehr viel geballte Kompetenz vorhanden ist, wollte ich einfach mal den Kopf reinstecken

[irix]

Dein Ergebnis haette ich jetzt nicht erwartet. Ich hatte was aehnliches letzte Woche beim Kunden und der hat einfach nicht das umgesetzt was man ihm gesagt hat sprich er hat das mit Core und Socket verwechselt und genau anders herum gemacht. Er hatte eine 24vCPU SAP HANA welche er auf 12vCore mit 2 vSocket konfigurieren sollte! Ergebnis war genau anders herum

Es gibt auf der ESXi cmd bzw. esxtop was zu Thema vNUMA angucken und auch im Windows kann man was abfragen. Ich muss mal schauen ob ich es noch zusammen kriege.
Ansonsten... auch bei VMware GSS(also Supportticket aufmachen) kann man ruhig mal nachfragen

Gruss
Joerg

[Dayworker]

@irix
Ich habe die Lizenzgeschichte nicht im direkten Blickpunkt, aber spielt da vielleicht die seit Anfang April 2020 geänderte Lage hinsichtlich der CPU-Lizenz pro 32 Kerne mit rein? Bei 2 Sockeln könnten ja automatisch auch 2 Lizenzen gezogen werden und dadurch auch die Aufteilung in 2 NUMA-Nodes. Könnte natürlich auch völliger Quatsch sein...

[irix]

Hmm... mangels Hardware mit >= 32 Cores gibts keine Erwahrungswerte aber nein glauben kann ich das nicht. Macht ja auch wenig bis keinen Sinn (muss aber bei VMware nichts heissen).

Die Frage ob der OP evtl. noch so Dinge angemacht hat wie CPU HotAdd?

Gruss
Joerg

[clem]

Hallo zusammen,

bitte folgenden Artikel von Frank Denneman beachten:
https://frankdenneman.nl/2016/12/12/dec ... phere-6-5/


Es muss auf dem Host der Parameter gesetzt werden:
Numa.FollowCoresPerSocket = 1

Der korrespondierende Parameter auf VM-Ebene funktioniert nicht.
Hab die Details aber nicht mehr im Kopf. Wir hatten zu dem Thema mal ein Ticket bei VMWare.

Geprüft werden kann das ganze mit :

vmdumper -l | cut -d \/ -f 2-5 | while read path; do egrep -oi "DICT.*(displayname.*|numa.*|cores.*|vcpu.*|memsize.*|affinity.*)= .*|numa:.*|numaHost:.*" "/$path/vmware.log"; echo -e; done

Gruß
Clemens

[Dayworker]

Interessanter Artikel von Frank. Da er den Artikel schon Ende Dezember 2019 überarbeitet hat, stellt sich die Frage nach der Aktualität.
Ohne Rückmeldung vom TE kommen wir nicht weiter.

[Login]

hallo zusammen,

sorry, für das große delay... Danke für den sehr interessanten Link! Ich lese ihn heute Abend noch mal genauer.

Beim überfliegen verstehe ich den Hostparameter "Numa.FollowCoresPerSocket = 1" zu setzen, ist das richtig?

CPU HotAdd etc wurde nicht gemacht.

[Dayworker]

Der Parameter ist soweit ich das verstanden habe nur notwendig, wenn man die VM von einem älteren Host (6.0) migriert wurde bzw diesen migrieren muß. Damit erzwingt man auf neueren ESXi-Versionen das Verhalten wie unter ESXi 6.0. Wurde die VM dagegen ab 6.5 aufwärts erstellt, sollte der jeweilige ESXi automatisch die passenden Einträge für "numa.autosize.vcpu.maxPerVirtualNode" anlegen.

[irix]

Das Interessante in dem Artikel ist ja die Aussage das VMware das Thema vCore*vSockel was vCPU angeht losgeloest hat vom Thema vNUMA und somit einzig und alleine dem Thema OS Lizenzierung dient bzw. wenn man einem MS Desktop OS hat was auf 2 Sockel begrenzt ist.

Das erklaert warum die Umstellung bei den vCPUs bei TE nichts gebracht hat was NUMA angeht.

Gruss
Joerg

[Dayworker]

Hinsichtlich NUMA und dessen Auswirkungen auf RAM, Cache etc macht es meiner Meinung nach aber gerade Sinn, daß genauer und passend zur vorliegenden HW einzustellen. Ansonsten fängt man sich natürlich immer in Abhängigkeit zur laufenden SW zusätzliche, eigentlich unnötige "Wartezeiten" ein und die könnten bei 4- oder 8-Sockets schon deutlich spürbar werden. Für normale Wald- und Wiesen-SW braucht man auf der anderen Seite aber auch nur selten deutlich mehr wie 8 Kerne...

[Login]

Hinsichtlich NUMA und dessen Auswirkungen auf RAM, Cache etc macht es meiner Meinung nach aber gerade Sinn, daß genauer und passend zur vorliegenden HW einzustellen. Ansonsten fängt man sich natürlich immer in Abhängigkeit zur laufenden SW zusätzliche, eigentlich unnötige "Wartezeiten" ein und die könnten bei 4- oder 8-Sockets schon deutlich spürbar werden.

so sehe ich das auch. Ich verstehe aber nach wie vor nicht, warum im Gast zwei NUMA nodes angezeigt werden, wenn doch eigentlich genügend Kerne innerhalb eines physikalischen Knotens zur Verfügung stehen.

[Martin]

Für eine Erklärung dürfte es am effektivsten sein, bei VMware ein entsprechendes Ticket zu eröffnen.
(wie auch schon von Joerg in viewtopic.php?p=188750#p188750 vorgeschlagen )

Das Wissen hier im Forum geht wohl noch nicht "tief genug" in diesem Spezialthema, erst recht im ESXi 7.

[Login]

Hallo zusammen,

kleines Update: Die Frage wurde an den VMware Support weitergegeben.

Numa homenode der VM ist weiterhin 0/1, wobei MEM N%L mit 100 keine CPU scheduler Aktivität bzgl. NUMA remote/locality zeigt. N%L 100 sollte 100% local numa heißen.

Seit dem die vCPU vs vSocket Konfig komplett vom CPU scheduler abgekoppelt ist, hat die Umstellung von 16 vCPU auf 16 vSockets auf 16 vCPUs auf 2 vSockets auch keine Relevanz auf irgendwelche esxtop Werte.

Ich gehe daher davon aus, dass der CPU scheduler die 16 vCPUs aus reiner Vernunft auf zwei NUMA nodes verteilt, obwohl die eigentlich in ein node passen sollten.

Sobald ich Antwort vom Support habe, melde ich deren Aussage.

cheers,
Conrad

[irix]

Wir sind gespannt.

Ich glaube aber auch das das Thema NUMA etwas kuenstlich hochgekocht wird so wie damals das mit dem Block Alignment welche auch so in Wellen alle 2 Jahre hoch kam und man den Eindruck hatte das Abendland steht kurz vor dem Untergang.

Bei meinen SGI Origin Servern aus dem Jahr 1998 war (cc)NUMA bereits ein Thema weil die Kiste aus bis zu 128 Racks mit jeweils 8 Dual CPU Board zusammengefrickelt wurden und es Performancemaessig durchaus ein Sicht- und Messbarer Unterschied ob man lokalen Speicher hatte oder einen welcher 4 Hops weiter war.

Gruss
Joerg

[Login]

Autsch. Das Thema ist numa-sub cluster bzw. XPT prefetcher und wurde mit broadwell erstmalig eingeführt. Mit aktiver Bios-Einstellung (default) wird ein physikalischer Numa node in zwei logische sub-numa nodes unterteilt und so auch dem OS präsentiert. Das soll Themen wie memory locality etc. optimieren.

https://software.intel.com/content/www/us/en/develop/articles/intel-xeon-processor-scalable-family-technical-overview.html

VMware und in dem Fall auch HPE empfehlen, die Optionen aktiviert zu belassen.

Das ist der Grund weshalb extop als numa home node 0/1 angezeigt hat, obwohl doch alles in einen physikalischen numa node passt. Der Fallstrick entstand durch den Eindruck, dass numa home node 0/1 beide Sockel beschreibt. Tatsächlich fiel dabei nicht auf, dass es auch numa home node 2 und 3 (2.Sockel) gibt, da diese VM die einzige auf dem Host ist.

Ansonsten gebe ich Joerg recht. Leider viel Heiße Luft. Wobei Acronis damals mit ihrem Alignment tool sicherlich einiges ihres heutigen Kapitals generiert haben

cheers,
Conrad

[UrsDerBär]

Bei Latenzempfindlichkeit gibts doch mittlerweile unter ESXi 7 sogar extra Flags. CPU-Reservation und RAM-Reservation ist ja dann ein Muss, was da sonst noch gemacht wird, weiss ich dagegen nicht. Gibt aber ein paar Dinge wie hochexakter Timer usw. den man hinzufügen kann. Dann wird der Kram sogar tauglich für Banking oder gewisse Industriedinge. Eventuell noch mit einer genauen Zeituhr sycen.
--> Hab in den nächsten Monaten mal einen Versuch machen ob das wirklich tauglich für eine SPS ist. Würde Maschinen etwas unabhängiger von der Hardware machen und deutlich einfachere Tests mit Sicherheits-Updates erlauben. Zudem immer mit UPS versorgt.

[Login]

Noch eine aktuelle Beobachtung:

Wir mussten feststellen, dass sich der IO sensitive switch (Latenzempfiindlichkeit auf hoch) negativ auf die disk IOs auswirkt. Mit aktivem switch messen wir innerhalb der VM bei 64k 27000 IOPs und ohne aktiver Latenzempfindlichkeit dann 42000 IOPs - das ist im Zweifel nicht ganz unrelevant.

Ich bin mit VMware am klären, warum das so ist.

cheers,
Conne