Spielereien
Kanu
Geopolitik
Business
TopoDB
POI
Klettersteigen
History
TransPool
Thermal Baden
Brokenstuben
Goldwaschen
Blog
Contact
Wir haben immer wieder und häufiger Kunden mit grossen VM’s 16 Core VM, 32 Core VM… (all virtualized policy).
Und wenn die Last generieren sehen wir 1600% CPU usage bzw. 3200% CPU usage.
Hast Du mir irgend welche belastbare Dokumente/Links, dass grosse VMs quatsch sind? Bzw. wenn es kein Quatsch ist, kann ich damit leben…
Ich habe bis jetzt nichts brauchbares finden können:
Dynatrace: Virtualization’s Impact on Performance Management - Why System Metrics in the Guest Are Not Trustworthy
https://frankdenneman.nl/2010/12/16/impact-of-oversized-virtual-machines-part-1/
“This article does not focus on large virtual machines that are correctly configured for their workloads.”
“For a small percentage of workloads, for which CPU virtualization adds overhead and which are CPU-bound, there might be a noticeable degradation in both throughput and latency.”
Große VMs sind kein Quatsch.
ich habe Oracle MySQL 8.0 auf einer AMD Epyc 2nd Gen Single Socket Maschine ohne my.cnf betrieben, mit 400.000 QPS ohne irgendeine Optimierung (das ist keine VM, das war Bare Metal). Aktuelles MySQL skaliert gut, und mit Optimierung und Konfiguration kommt man leicht auf > 1M QPS.
Wir haben “memcached”-Queries (SELECT value from t where id =
Bei großen CPUs und großen VMs gilt aber:
NUMA ist eine Hünding. Am Besten ist es, eine Single Socket Kiste zu haben. Also eine große AMD EPYC mit einem Sockel und wenn man mehr will, eine 2. Kiste statt Dual-Socket. AMD gitb Dir 128 PCI Lanes mit Single Socket und 128 PCI Lanes mit Dual-Socket, weil die 2. 128 PCI Lanes für den Interconnect drauf gehen. NUMA dann dazu, also linker Socket auf Speicher vom rechten Socket = Additional Latenz = doof.
VMs pinnen. Bei Dual-Socket also “numactl -N 0 -m 0 command …” oder was auch immer. Das eine pinnt die Cores auf Socket 0, das andere den Speicher auf Sockets 0. Dadurch liegt die VM bei ihrem Speicher auf demselben Core fest.
Harte CPU kaufen. Wenn Du alle Cores auf einem Chip nutzt, wird die CPU langsamer, weil sie thermale Probleme bekommt. AMD ist da resilienter als Intel, und bei Intel sind die Dinger gestaffelt Scheiße. Siehe zum Beispiel die https://en.wikichip.org/wiki/intel/xeon_gold/6230#Frequencies Die 6230 ist (angeblich) eine harte CPU, aber sogar die macht 1 Core Busy 3900 MHz, alle Cores busy 2800 MHz.
Das - crosstalk - ist ein ernstes Problem bei VMs, die CPU-intensiv genutzt werden – Datenbanken eher nicht, die sind I/O und Memory.
Balance. 1 vCPU = 4 GB RAM, bei Datenbanken auch gerne 1:8 oder gar 1:16. Wenn Du zu wenig RAM hast, machst Du I/O und dann wartest Du schneller und mit mehr Cores. Nutzt gar nix eine Kiste imba zu bauen (imbalanced, also mit dem falschen Verhältnis Core - Memory - Netz)
RAM muß auch voll gemacht werden, also Daten von Platte laden und Daten kommen ultimativ auf die Platte aus dem Netz. Eine balanced Kiste ist also 1 core - 4 GB RAM und x MBit/s Netz, wir rechnen oft mit 100 MBit/s oder so. Du kannst Dir das ausrechnen, indem Du Dir überlegst, wie lange Du auf 1 GB, 100 GB oder 1 TB Daten warten magst. 200 MBytes/s sind eine Platte, und das sind 1600 MBit/s, also 1.6 GBit/s. 400 MBytes/s sind eine SSD linear, also 3200 MBit/s, 3.2 GBit/s, also 100 MBit/s bei einer 32 vCPU VM.
Firma B bis 2020: Baremetal Blade mit Dual 4110 (32 vCPU), 128 GB RAM, 10 GBit/s Netzwerkkarte, lokal 1x oder 2x 1.92 TB Micron SSD (800.000 IOPS, 1/20_000s clat).
Firma B jetzt (sagt man mir, ich bin ja nicht mehr da): EPYC Kisten 4 Gen mit imba viel RAM (2 TB, 4 TB) und dann dicht gepackt VMs drauf, jede beliebige Größe bis zu 1/2 Maschine (die haben dummerweise Dual-Socket gekauft).
Die Datenbanker freut das, viel RAM viel gut.
Ansonsten sind “32 Core VM” keine großen Maschinen. Das sind Butter und Brot Bare-Metal Blades bei Firma B für MySQL, davon habe ich 50.000 Stück gehabt, als ich bei Firma B Rechenzentren geplant habe. Es sind in etwa die kleinsten Maschinen, die man kosteneffektiv kaufen kann. Sie kommen Firma B 120 Euro/Monat (150 Euro/Monat für 2x NVME) teuer, bei einer Nutzungszeit von 5 Jahren. Dabei sind 50% der Kosten Abschreibung von Maschine, Chassis, Netzwerk- und Rackanteil, RZ-Kosten, und 50% Strom/Energiekosten.
Firma B und Oracle MySQL haben quartalsweise zusammengesessen und Dinge besprochen, seit 2015 oder so sind solche Maschinen für keine MySQL Version je ein Problem gewesen – sonst hätte ich den MySQL-Meschen da leider einen Schlag an den Hals geben müssen, weil sie im Job gepennt haben.
Bei unseren VM-Experimenten mit wirklich großen Maschinen (96 Core pro Socket, 192 vCPU) war wie gesagt lediglich das Pinning und Numa-Management ein Problem, weil alles schlimm wird, wenn man 128 GB Buffer Pool hat, von dem die Hälfte hinter der anderen CPU liegen und 3x langsamer sind.
–membind=nodes, -m nodes Only allocate memory from nodes. Allocation will fail when there is not enough memory available on these nodes. nodes may be specified as noted above.
–cpunodebind=nodes, -N nodes Only execute command on the CPUs of nodes. Note that nodes may consist of multiple CPUs. nodes may be specified as noted above.
Okay, “numactl -N 0 -m 0 blabla” zum Binden an Socket 0 und “-N 1 -m 1” für den anderen Socket.
Hi Kris, vielen Dank für Deine ausführliche Antwort! Ich fasse zusammen: VMware VMs mit “vielen” vCores (16 - 32) sind kein Problem auch wenn die CPU zu 100% user time ausgelastet sind (1600% - 3200% CPU user time, kein I/O da nur aus Buffer Pool gelesen wird). Sofern man beachtet, dass die VM auf eine Numa Node gepinnt ist… Ansonsten muss man mit 1/3 der Leistung rechnen… Habe ich das so in ewa richtig augefasst? LG, Oli
Wieviel weniger es ist ist variabel, da auch alle möglichen anderen Dinge passieren können, wenn man die Bridge zwischen den Cores dicht zieht. Da wird dann schnell alles schlimm und es ist schwer zu messen
Aber ja, soweit richtig. Bis 192 vCores habe ich ein 8.0 testen können, ist nicht schlimm, aber man muss es ggf. ein wenig befummeln
Wieso wird alles schlimm? Bei den meisten Intels sind Netz und I/o per Hardware an Sockel 0 angeflanscht. Macht man bei einer Intel die Bridge zwischen den Sockeln dicht, verhungert alles außer socket 0
Um das zu handhaben machen Gerätetreiber interrupts, Irq handling ist also meist zwangsweise auf socket 0. Will sagen, die Kisten sind nicht symmetrisch auf Hardware Ebene. In einer VM spielt das keine Rolle, aber auf dem Host schon
