Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
NUMA/vNUMA I/O sensitive switch high
NUMA/vNUMA I/O sensitive switch high
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!
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!
-
- King of the Hill
- Beiträge: 12945
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: Riesen VM -> vCPU
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.
Gruss
Joerg
PS: 16 vCPU und 96G vMEM ist nicht gross.
Re: Riesen VM -> vCPU
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![Roll eyes :roll:](./images/smilies/icon_rolleyes.gif)
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
![Roll eyes :roll:](./images/smilies/icon_rolleyes.gif)
-
- King of the Hill
- Beiträge: 12945
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: NUMA/vNUMA I/O sensitive switch high
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 ![Smile :)](./images/smilies/icon_smile.gif)
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![Smile :)](./images/smilies/icon_smile.gif)
Gruss
Joerg
![Smile :)](./images/smilies/icon_smile.gif)
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
![Smile :)](./images/smilies/icon_smile.gif)
Gruss
Joerg
-
- King of the Hill
- Beiträge: 13562
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Re: NUMA/vNUMA I/O sensitive switch high
@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...
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...
-
- King of the Hill
- Beiträge: 12945
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: NUMA/vNUMA I/O sensitive switch high
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
Die Frage ob der OP evtl. noch so Dinge angemacht hat wie CPU HotAdd?
Gruss
Joerg
Re: NUMA/vNUMA I/O sensitive switch high
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
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
-
- King of the Hill
- Beiträge: 13562
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Re: NUMA/vNUMA I/O sensitive switch high
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.
Ohne Rückmeldung vom TE kommen wir nicht weiter.
Re: NUMA/vNUMA I/O sensitive switch high
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.
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.
-
- King of the Hill
- Beiträge: 13562
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Re: NUMA/vNUMA I/O sensitive switch high
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.
-
- King of the Hill
- Beiträge: 12945
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: NUMA/vNUMA I/O sensitive switch high
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
Das erklaert warum die Umstellung bei den vCPUs bei TE nichts gebracht hat was NUMA angeht.
Gruss
Joerg
-
- King of the Hill
- Beiträge: 13562
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Re: NUMA/vNUMA I/O sensitive switch high
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...
Re: NUMA/vNUMA I/O sensitive switch high
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.
Re: NUMA/vNUMA I/O sensitive switch high
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.![Very Happy :D](./images/smilies/icon_mrgreen.gif)
(wie auch schon von Joerg in viewtopic.php?p=188750#p188750 vorgeschlagen
![Wink ;)](./images/smilies/icon_wink.gif)
Das Wissen hier im Forum geht wohl noch nicht "tief genug" in diesem Spezialthema, erst recht im ESXi 7.
![Very Happy :D](./images/smilies/icon_mrgreen.gif)
Re: NUMA/vNUMA I/O sensitive switch high
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
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
-
- King of the Hill
- Beiträge: 12945
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: NUMA/vNUMA I/O sensitive switch high
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
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
Re: NUMA/vNUMA I/O sensitive switch high
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
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.
![Embarassed :oops:](./images/smilies/icon_redface.gif)
Ansonsten gebe ich Joerg recht. Leider viel Heiße Luft. Wobei Acronis damals mit ihrem Alignment tool sicherlich einiges ihres heutigen Kapitals generiert haben
![Roll eyes :roll:](./images/smilies/icon_rolleyes.gif)
cheers,
Conrad
Re: NUMA/vNUMA I/O sensitive switch high
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.
--> 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.
![Very Happy :grin:](./images/smilies/icon_biggrin.gif)
Re: NUMA/vNUMA I/O sensitive switch high
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
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
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 8 Gäste