Warum eine VM, die größer als ein CPU-Socket ist, oft langsamer läuft

Wenn eine virtuelle Maschine langsam ist, ist der Reflex, ihr mehr Kerne zu geben. Auf einem modernen Server mit zwei Sockets gibt es einen Punkt, an dem sich dieser Reflex gegen Sie wendet und die größere VM langsamer läuft als die kleinere, die sie ersetzt hat. Dieser Punkt ist die Größe eines CPU-Sockets, und der Grund heißt NUMA.

Was NUMA ist, in einem Absatz

Ein Server mit zwei Prozessoren ist in Wirklichkeit zwei Computer, die sich eine Brücke teilen. Jeder Socket hat seine eigenen Speicher-Controller und seine eigene, direkt angebundene Speicherbank. Ein Kern, der Speicher an seinem eigenen Socket liest, bekommt ihn mit lokaler Geschwindigkeit. Ein Kern, der Speicher am anderen Socket liest, muss den Interconnect zwischen den Sockets überqueren, und dieser Zugriff ist langsamer. Diese Anordnung ist der nicht uniforme Speicherzugriff: Jeder Kern erreicht den gesamten Speicher, aber nicht zu denselben Kosten. Jeder Socket mit seinem Speicher ist ein NUMA-Knoten.

Warum das Überschreiten der Grenze mehr kostet, als es aussieht

Ein entfernter Speicherzugriff dauert etwa 1,7-mal so lange wie ein lokaler. Das allein ist ein großer Nachteil für alles, was häufig auf den Speicher zugreift, also für fast alles. Und es ist nicht die ganze Rechnung:

• Cache-Kohärenz. Die beiden Sockets müssen ihre Caches konsistent halten. Wenn Threads auf beiden Seiten an denselben Daten arbeiten, springen Cache-Zeilen über den Interconnect hin und her, und jeder Sprung ist ein Stall.
• Sättigung des Interconnects. Die Verbindung zwischen den Sockets hat eine endliche Bandbreite. Eine ausgelastete VM, die über beide Sockets verteilt ist, konkurriert darum mit allem anderen auf dem Host.
• Scheduling. Eine VM, deren vCPUs nicht alle gleichzeitig auf einem Socket laufen können, wartet darauf, dass der Hypervisor auf beiden Platz findet, und ihre Threads landen dort, wo gerade Platz ist, oft weit weg von ihren Daten.

Diese Effekte multiplizieren sich, statt sich zu addieren. Eine Workload, die innerhalb eines Sockets sauber skalieren würde, kann einen großen Teil ihres Durchsatzes verlieren, sobald sie sich über zwei verteilt, und die zusätzlichen Kerne, die Sie hinzugefügt haben, bezahlen für dieses Privileg.

Lesen Sie die Topologie Ihres Hosts

Bevor Sie irgendetwas dimensionieren, sehen Sie nach, was der Host tatsächlich hat:

lscpu | grep -E 'Socket|Core|Thread|NUMA'
numactl --hardware

Typische Ausgabe auf einem Host mit zwei Sockets:

Thread(s) per core:  2
Core(s) per socket:  18
Socket(s):           2
NUMA node(s):        2
NUMA node0 CPU(s):   0-17,36-53
NUMA node1 CPU(s):   18-35,54-71

Die Zahlen, auf die es ankommt, sind die Kerne pro Socket und der Speicher pro Knoten, den numactl --hardware zusammen mit einer Distanztabelle ausgibt. Die Distanzen zeigen, wie viel teurer ein entfernter Zugriff gegenüber einem lokalen auf genau dieser Maschine ist.

Dimensionieren Sie nach physischen Kernen, nicht nach Hyper-Threads.

Die zwei Regeln der Dimensionierung

Aus der Topologie ergeben sich zwei Regeln, die leicht zu formulieren sind und die man nie brechen sollte:

1. Eine VM bekommt nie mehr vCPUs, als ein Socket physische Kerne hat. Lassen Sie Reserve für den Hypervisor selbst, sodass auf einem Socket mit achtzehn Kernen eine vernünftige Obergrenze ein paar Kerne darunter liegt.
2. Eine VM bekommt nie mehr Speicher, als ein NUMA-Knoten bereitstellt. Sonst ist ein Teil ihres Speichers von vornherein entfernt, was auch immer der Scheduler tut.

Eine VM, die beide Regeln einhält, kann vollständig in einem Knoten leben, und ein guter Hypervisor hält sie dort.

Prüfen Sie, wo eine laufende VM tatsächlich lebt

Auf einem KVM-Host sehen Sie, wie der Speicher eines Gasts über die Knoten verteilt ist:

numastat -c qemu-kvm
virsh vcpuinfo <vm-name>
virsh numatune <vm-name>

Wenn numastat eine große VM mit erheblichem Speicher auf beiden Knoten zeigt, zahlt sie bei einem Teil ihrer Arbeit den Aufschlag für entfernte Zugriffe. Innerhalb eines Linux-Gasts zeigen lscpu und numactl --hardware die Topologie, die der Hypervisor ihm präsentiert.

Wenn ein Socket wirklich nicht reicht

Manche Workloads brauchen tatsächlich mehr, als ein Socket liefern kann. Es gibt bessere Antworten als eine riesige VM:

• Scale-out. Zwei VMs, die jeweils in einen Knoten passen, hinter einem Load Balancer oder als Mitglieder eines Clusters, schlagen in der Regel eine VM, die beide Sockets überspannt.
• Beheben Sie zuerst den Engpass. Eine VM, die scheinbar mehr Kerne braucht, wartet oft auf Storage, auf Locks oder auf einen einzelnen ausgelasteten Thread. Einer Workload Kerne hinzuzufügen, die sie nicht nutzen kann, ändert nichts außer dem NUMA-Nachteil.
• Wenn sie groß sein muss, machen Sie sie NUMA-bewusst. Präsentieren Sie dem Gast eine virtuelle Topologie, die den Host spiegelt, zwei virtuelle Knoten passend zu den zwei physischen, und binden Sie jeden virtuellen Knoten an seinen physischen. Ein Betriebssystem und eine Anwendung, die NUMA kennen, können Threads dann nahe bei ihren Daten halten. Enterprise-KVM-Manager, OLVM darunter, bieten dafür NUMA-Pinning an.

Größer ist ohnehin nicht linear schneller

Selbst innerhalb eines Sockets verdoppelt eine Verdopplung der vCPUs selten den Durchsatz. Teile jeder Workload sind seriell, Locks werden mit mehr Threads stärker beansprucht, Caches werden geteilt, und der Hypervisor braucht mehr Aufwand, um eine breite VM zu schedulen. Eine Verdopplung bringt üblicherweise nur einen Bruchteil der Verdopplung, und jenseits der Socket-Grenze kann sie negativ werden. Der ehrliche Weg zur Dimensionierung ist, die echte Workload in zwei Größen laufen zu lassen und zu messen. Die kleinere VM gewinnt öfter, als die meisten erwarten.

Wie wir es machen

Auf unseren Private Clouds mit OLVM und auf jeder anderen Plattform, die wir betreiben, gelten beide Regeln für jede VM: nie mehr vCPUs, als ein physischer Socket Kerne hat, nie mehr Speicher, als ein NUMA-Knoten bereitstellt, dimensioniert nach der tatsächlichen Topologie des Hosts. Wir dimensionieren genau auf das, was die Workload braucht, statt aufzurunden.

Wenn Ihre VMs nach Gefühl dimensioniert wurden oder einfach Anfrage für Anfrage gewachsen sind, sehen wir uns die Topologie und die Zahlen gern mit Ihnen an.

Mit einem Ingenieur sprechen

Related (rows[1])

Verwandte Themen: Private Cloud auf KVM mit OLVM · Performance- und Kapazitäts-Engineering · Dedizierte Cloud auf Apache CloudStack, nach Ihrer Spezifikation