PERFORMANCE TUNING OF LATENCY-SENSITIVE WORKLOADS IN

VSPHERE VMS

TUNING MAßNAHMEN

Inhalt

INHALT

1 Einführung ............................................................................................................................ 1

2 Tuning-Maßnahmen ............................................................................................................. 3

2.1 Empfohlene Reihenfolge der Tuning-Maßnahmen ............................................................. 3

2.2 BIOS Einstellungen ............................................................................................................ 4

2.3 Host-Energieverwaltungsrichtlinien .................................................................................... 6

2.4 VM Einstellungen ............................................................................................................... 6

2.4.1 Systemvoraussetzungen für NEVARIS Build ................................................................ 7

2.4.2 Latency Sensitivity ........................................................................................................ 8

2.4.3 Memory ........................................................................................................................ 9

2.4.4 Reservierung ................................................................................................................ 9

2.4.5 CPU .............................................................................................................................. 9

2.5 Gastbetriebssystem ......................................................................................................... 10

2.6 VMware Tools .................................................................................................................. 11

2.7 NUMA Einstellungen ........................................................................................................ 11

2.8 Einstellungen der physikalischen Netzwerkkarte .............................................................. 13

2.9 Einstellungen der virtuellen Netzwerkkarte ....................................................................... 14

2.10 LRO deaktivieren in Linux ................................................................................................ 15

2.11 LRO global deaktivieren in Windows ................................................................................ 16

Versionshistorie

VERSIONSHISTORIE

Datum Version Beschreibung Author

2017-10-16 1.00 Tuning VMware vSphere WESTERMANN Boris

Einführung | 1

1 Einführung

Der vSphere ESXi Hypervisor bietet eine leistungsstarke Plattform, die effektiv viele Tier-1

Programme in virtuellen Maschinen ausführen kann. Standardmäßig ist der ESXi Hypervisor

darauf ausgelegt den I/O-Durchsatz effektiv zu steuern, indem weniger CPU-Zyklen benötigt

werden und Energie gespart wird, wenn eine große Menge von Workloads ausgeführt werden.

Allerdings verlangen einige Anwendungen, dass die I/O-Latenz minimiert wird, auch auf Kosten

einer höheren CPU-Auslastung und eines höheren Stromverbrauchs.

Wir haben die Leistung von NEVARIS Build untersucht und herausgefunden, dass die Memory

Latenz eine herausragende Bedeutung für diese Applikation hat.

Den Empfehlungen folgend, die wir in diesem Best Practice Dokument beschrieben haben,

konnten wir die Memory Latenz von 17,313 ms auf 11,994 ms senken bzw. den Passmark Memory

Latenz Score von 37,3 auf 31,3 verbessern.1 Gleichzeitig war auffällig, dass nach der

Konfiguration, die Leistung gleichmäßig anfiel und nicht schwankte. Dies führt zu einer insgesamt

vorhersagbaren Leistungserbringung.

Beachten Sie bitte, dass die beschriebenen Einstellungen und die daraus resultierenden

Resultate von der eingesetzten Hardware und den darauf laufenden Workloads abhängig

sind. Bitte testen Sie die beschriebenen Einstellungen aus bevor Sie diese in einer

Produktivumgebung einsetzen.

1 https://www.passmark.com/products/pt.htm

2 | Einführung

Empfohlene Reihenfolge der Tuning-Maßnahmen | 3

2 Tuning-Maßnahmen

2.1 Empfohlene Reihenfolge der Tuning-Maßnahmen

In der folgenden Tabelle finden Sie eine Aufstellung der möglichen Maßnahmen. Wir haben für

unsere Tests alle grün unterlegten Maßnahmen durchgeführt und getestet.

BIOS

1. Power

Management

Static High/Max Performance

All versions of

vSphere Disable Processor C-states including C1E

Disable chipset power management

2. Processor

Options

Disable QPI Link Power Management

All versions of

vSphere

Enable Hyperthreading

Enable Virtualization Technology

Enable Intel VT-d

Enable SR-IOV

Enable Turbo Boost

Disable Node Interleaving

Host

3. Power

Management

Policy

High Performance vSphere 5.5 and

newer

NUMA

vCPU and

memory

affinities

VM Settings > Options tab > Advanced General > Configuration Parameters

numa.nodeAffinity = “0, 1, …”

vSphere 5.0 and

newer

PHYSICAL NIC

Disable

interrupt

moderation

esxcli system module parameters set -m <driver> -p "param=val" vSphere 5.0 and

newer

VIRTUAL NIC

Disable

interrupt

coalescing

VM Settings > Options tab > Advanced General > Configuration Parameters

ethernetX.coalescingScheme = "disabled"

vSphere 5.0 and

newer

Configuration > Advanced Settings > Net CoalesceDefaultOn = 0 vSphere 4.0/4.1

Disable LRO modprobe -r vmxnet3; modprobe vmxnet3 disable_lro=1 All versions of

vSphere

4 | BIOS Einstellungen

VM

Reduce idle-

wakeup

latencies

VM Settings > Options tab > Advanced Genera > Configuration Parameters

monitor_control.halt_desched = "false" OR For > 1 vCPU VMs:

monitor.idleLoopSpinBeforeHalt = "true" For 1 vCPU VMs:

monitor.idleLoopSpinBeforeHaltUP = "true"

vSphere 5.1 and

older

4. Latency

Sensitivity Edit Settings > VM Options tab > Advanced > Latency Sensitivity > High

vSphere 5.5 and

newer

5. VMware

Tools

Install Vmware Tools and use VMXNET 3 network driver and Vmware Paravirtual

SCSI controller.

All versions of

vSphere

GUEST OS

Disable

interrupt

coalescing

netsh int tcp set global rsc=disable

All versions of

vSphere 6. Enable High

Performance

powerplan

Powercfg -setacvalueindex scheme_min sub_processor PERFBOOSTMODE 2

Powercfg -setactive scheme_min

2.2 BIOS Einstellungen

Server mit neuen Intel- und AMD-Prozessoren bieten Energieeinsparungsfunktionen, die

verschiedene Techniken verwenden, um die Last auf einem System dynamisch zu erkennen und

verschiedene Komponenten des Servers, einschließlich der CPU, des Chipsatzes und

Peripheriegeräte, in Energiesparzustände zu setzen, wenn das System idle ist.

Es gibt zwei Bereiche des Powermanagements der ESXi Plattform:

o Die BIOS-Einstellungen für die Energieverwaltung, die beeinflussen, was das BIOS an den Hypervisor weitergibt.

o Die Hypervisor-Einstellungen für das Power Management. Diese Richtlinien beeinflussen, was zu tun ist, wenn der Hypervisor erkennt, dass das System im Leerlauf ist.

Die Powermanagement-Funktionen der verschiedenen Stromsparmodi führen zu einer erhöhten

Latenz. Deshalb empfehlen wir die BIOS-Einstellungen für das Powermanagement auf „Static

High“ zu setzen. Dies führt zu Deaktivierung sämtlicher Powermanagement-Funktionen im BIOS.

Beachten Sie, dass die Erreichung der geringstmöglichen Latenz im Widerspruch zu

Energieeinsparung (Stromverbrauch, Kühlung) steht.

Prozessoren ab der Intel Nehalem Klasse (Intel Xeon 55xx und neuere) bieten zwei weitere

Powermanagement Optionen: C-State und Intel Turbo Boost. Die Aktivierung der C-States kann

die Speicherlatenz erhöhen und wird daher nicht für Workloads mit niedriger Latenz empfohlen.

Auch der erweiterte C-State C1E, führt zu erhöhten Latenzen. Intel Turbo Boost erhöht die

Taktfrequenz des Prozessors, wenn ein VM-Workload mehr Leistung anfordert und sollte für Low-

latency und hoch performante Workloads aktiviert werden. Da Turbo Boost jedoch Teile der CPU

BIOS Einstellungen | 5

übertakten kann, sollte es deaktiviert bleiben, wenn die Anwendungen eine stabile, vorhersagbare

Leistung und eine geringe Latenzzeit mit minimalem Jitter erfordert.

Die Performance-Einstellungen unterscheiden sich bei den verschiedenen Server-Herstellern.

Hier z.B., für HP ProLiant Gen9 Server:

Gehe zu System Configuration > BIOS/Platform Configuration (RBSU)

o System Options > Processor Options: Setze “Hyperthreading” auf Enabled.

o System Options > Virtualization Options: Setze “Virtualization Technology” auf Enabled.

o System Options > Virtualization Options: Setze “Intel VT-d” auf Enabled.

o System Options > Virtualization Options: “Setze SR-IOV” auf Enabled.

o System Options > Serial Port Options: Disable alle seriellen Ports.

o Power Management: Setze das Power Profile auf ”Maximum Performance“.

o Power Management > Advanced Power Options: Setze ”Intel QPI Link Power Management“ auf Disabled.

o Performance Options: Setze “Intel Turbo Boost Technology” auf Enable.

o Performance Options > Advanced Performance Tuning Options: Setze “Node Interleaving” auf Disabled (aktiviert NUMA).

und für Dell PowerEdge Server:

o Memory Setting: Node Interleaving auf Disabled (aktiviert NUMA).

o Power Management: Setze Power Management auf Maximum Performance. Die manuelle Selektion (CPU Power and Performance Management, Fan Power and Performance Management, Memory Power and Performance Management) ist deaktiviert.

o Processor Setting: Setze Logical Processor auf Enabled. (aktiviert Hyper Threading)

o Processor Settings: Setze Virtualization Technology auf Enabled.

o Processor Settings: Setze Turbo Mode auf Enabled.

o Processor Settings: Setze C1E auf Disabled.

o Processor Settings: Setze C States auf Disabled.

6 | Host-Energieverwaltungsrichtlinien

Anmerkungen

o Integrierte Geräte: VMware empfiehlt, Deaktiviere im BIOS alle nicht benötigten Geräte, wie z.B. serielle Ports, USB Ports, Floppy Drive.

o Processor Prefetchers: Die verschiedenen Prozessor Architekturen haben eventuell weitere “Processor Settings”, wie z.B. Hardware Prefetcher, Adjacent Cache Line Prefetch, DCU Streamer Prefetcher, Data Reuse, DRAM Prefetcher, usw. Die Standard-Einstellung ist Enabled, und generell sollten diese Einstellungen so belassen werden, da sie die Performance verbessern. Für sehr seltene, memory-intensive Workloads, können sie die einzelnen Einstellungen deaktivieren, um zu prüfen ob die Performance gesteigert wird.

Für weitere Empfehlungen schauen sie bitte in die Server-Dokumentation des jeweiligen

Herstellers.

2.3 Host-Energieverwaltungsrichtlinien

ESXi kann die Vorteile aus den verschiedenen Energieverwaltungsfunktionen, die von der

Hosthardware bereitgestellt werden, nutzen, um das Verhältnis von Leistung und Stromverbrauch

auszutarieren. Sie können steuern, wie ESXi diese Funktionen nutzt, indem Sie eine

Energieverwaltungsrichtlinie auswählen.

Die Auswahl einer Richtlinie für hohen Energieverbrauch bietet im Allgemeinen mehr absolute

Leistung, jedoch eine niedrigere Effizienz (Leistung pro Watt). Richtlinien für weniger

Energieverbrauch bieten weniger absolute Leistung, aber eine höhere Effizienz.

ESXi bietet fünf Energieverwaltungsrichtlinien (Hochleistung, Ausgeglichen, Geringer

Energieverbrauch, Benutzerdefiniert, nicht unterstützt). Wenn die Energieverwaltung vom Host

nicht unterstützt wird oder die BIOS-Einstellungen festlegen, dass das Hostbetriebssystem die

Energie nicht verwalten darf, steht nur die Richtlinie „Nicht unterstützt“ zur Verfügung.

Sie wählen mit dem vSphere Web Client eine Richtlinie für einen Host aus. Wenn Sie keine

Richtlinie auswählen, verwendet ESXi standardmäßig die Richtlinie „Ausgeglichen“. Wenn Sie

sicherstellen wollen, dass die VMs immer die höchste Performance erhalten, dann sollten Sie die

Richtlinie auf „Hochleistung“ stellen. Hierzu gehen Sie im vSphere Web Client zu Select Host >

Select Configure tab > Hardware > Power Management > Click Edit > Change Power Management

Rule auf „Hochleistung“ setzen.

Weitere Informationen finden sie hier:

https://docs.vmware.com/de/VMware-vSphere/6.0/com.vmware.vsphere.resmgmt.doc/GUID-4D1A6F4A-

8C99-47C1-A8E6-EF3865603F5B.html

2.4 VM Einstellungen

Generell gilt für virtuelle Maschinen, dass nur die notwendigen Ressourcen konfiguriert werden!

Bitte entfernen sie alle Geräte, die nicht benötigt werden, wie u.a. Floppy Controller, Serielle Ports.

VM Einstellungen | 7

Überprovisionierung ist zu vermeiden, da die Konfiguration von zu vielen Ressourcen sich

nachteilig auf die Performance auswirkt. Der VMkernel Scheduler schafft es eventuell nicht die

Ressourcen in schnellstmöglicher Zeit zur Verfügung zu stellen, was wiederum Latenzen

verursacht. Insbesondere dann, wenn viele VMs auf einem Host zusammen laufen und im Falle

einer Überprovisionierung der Hostressourcen (Summe des Arbeitsspeicher aller VMs ist größer

als der physikalische Arbeitsspeicher des Hosts, Summe der vCPUs ist größer als die Summe der

logischen Prozessoren des Hosts) sich die VMs um die Ressourcen streiten müssen. Weiterhin ist

auch der CPU Core-Takt mitentscheidend für Memory-Latenzen. Umso höher der Core-Takt, umso

niedriger die Memory-Latenz! Die Anzahl der Prozessoren ist nicht entscheidend für die Memory-

Latenz, solange alle VMs genügend CPU-Ressourcen finden.

2.4.1 Systemvoraussetzungen für NEVARIS Build

Einzelplatz-VM Normal-User

o Dual Core ab 2,4 GHZ

o Min. 4 GB RAM (32bit) bzw. 8 GB RAM (64bit)

o Min. 4 GB freier Festplattenspeicher

8 | VM Einstellungen

Einzelplatz-VM Power-User

o Quad Core ab 2,4 GHZ

o Min. 4 GB RAM (32bit) bzw. 8 GB RAM (64bit)

o Min. 4 GB freier Festplattenspeicher

Terminalserver

o Quad Core ab 2,4 GHz

o Min. 8 GB RAM plus 4 GB für jeden User

o Min. 4 GB freier Festplattenspeicher

o Empfehlung Pro aktivem Benutzer:

1 logischer Prozessorkern

2.4.2 Latency Sensitivity

Seit vSphere 5.5 gibt es eine VM-Option namens Latency Sensitivity, die standardmäßig auf Normal

gesetzt ist. Wird diese Einstellung auf High gesetzt kann das zu signifikant niedrigeren Latenzen

und Jitter führen, als Folge der folgenden Mechanismen, die im ESXi Hypervisor wirksam werden:

o Exklusiver Zugriff auf physische Ressourcen, einschließlich pCPUs für vCPUs ohne konkurrierende Threads für die Ausführung auf diesen pCPUs.

o Full-Memory-Reservierung eliminiert Ballooning oder Hypervisor Swapping, dies führt zu mehr vorhersagbarer Leistung ohne Latenzoverheads aufgrund solcher Mechanismen.

o Wenn die vCPU im Leerlauf ist führt das Halting im VM-Monitor, zu einem schnelleren vCPU-Wake-up von Halt unter Umgehung des VMkernel Scheduler für die Bereitstellung der pCPU. Dies schont auch die Leistung, da das Stoppen die pCPU in einen Low-Power Modus bringt, verglichen mit dem Spinnen im VM Monitor mit der "monitor_control.halt_desched=FALSE" Option.

o Deaktivieren der Interrupt-Koaleszenz und LRO automatisch für VMXNET 3 Netzwerkkarten.

o Optimierter Interrupt-Delivery-Pfad für VM DirectPath I/O- und SR-IOV Passthrough-Geräte, mittels heuristischer Daten aus dem Gast-OS über die optimale Platzierung von physikalischen Interrupt-Vektoren auf physischen CPUs abzuleiten.

Um mehr über dieses Thema zu erfahren, schauen Sie sich bitte das folgende technische

Whitepaper an:

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/latency-sensitive-perf-

vsphere55-white-paper.pdf

VM Einstellungen | 9

2.4.3 Memory

Jede virtuelle Maschine verbraucht Arbeitsspeicher auf der Grundlage der für sie konfigurierten

Größe, sowie einen zusätzlichen Overhead-Arbeitsspeicher für die Virtualisierung.

Die konfigurierte Größe ist die Größe des Arbeitsspeichers, der dem Gastbetriebssystem zur

Verfügung gestellt wird. Dieser Wert unterscheidet sich von dem physischen Arbeitsspeicher, der

der virtuellen Maschine zugeteilt ist. Der Letztere hängt von den Ressourceneinstellungen (Anteile,

Reservierung, Grenzwert) und dem Grad der Arbeitsspeicherbelastung auf dem Host ab.

Wenn Ihre Anwendung eine große Menge an physischem Speicher benötigt, wenn sie nicht

virtualisiert ausgeführt wird, sollten sie ihre VM auch mit viel RAM konfigurieren. Aber prüfen sie

den tatsächlichen Verbrauch des Arbeitsspeichers, um gegebenenfalls die Anforderungen zu

reduzieren. Sie können sich die Speicherstatistik im vSphere-Client Select Host and Clusters >

Select Host > Configure tab > Hardware > Memory ansehen, um zu sehen, wie viel Speicher Sie für

die VMs konfigurieren können, nachdem der gesamte Virtualisierungs-Overhead (System)

berücksichtigt wurde.

2.4.4 Reservierung

Die Reservierung ist eine garantierte Untergrenze für die Menge an physischem Arbeitsspeicher,

die der Host für eine virtuelle Maschine reserviert, auch wenn der Arbeitsspeicher mehrfach

vergeben wird. Die Reservierung sollte so festgelegt werden, dass die virtuelle Maschine über

ausreichend Arbeitsspeicher verfügt, um eine effiziente Ausführung ohne übermäßiges Paging zu

gewährleisten.

Für Memory-latenzsensitive VMs empfiehlt es sich den gesamten Arbeitsspeicher zu reservieren.

Gehen Sie hierfür zu vSphere Web Client > Select VM > Edit Settings > Expand Memory Category >

Select “Reserve all guest memory (all locked)”.

2.4.5 CPU

NEVARIS Build profitiert von einem Mehrprozessorsystem. Für latenzempfindliche Anwendungen

sollten Sie jedoch nicht mehr vCPUs in einer VM, als physikalisch vorhandene CPUs (pCPUs) auf

einem ESXi-Host, konfigurieren. Zum Beispiel, wenn Ihr Host 8 CPU-Cores hat, beschränken Sie

die Anzahl vCPUs für Ihre VM auf 7. Dies stellt sicher, dass der ESXi VMkernel Scheduler eine

bessere Chance hat, ihre vCPUs auf pCPUs zu platzieren, die nicht von anderen Scheduling-

Kontexten benutzt werden, wie vCPUs von anderen VMs oder ESXi helper worlds. Darüber hinaus

sollten Sie, wenn möglich nie mehr vCPUs einer VM zu ordnen, als pCPUs in einem CPU-Socket.

Der ESXi Hypervisor versucht auf einem NUMA-System (siehe auch: Kapitel 2.7 NUMA

Einstellungen) die vCPUs einem NUMA-Node zuzuordnen.

Wenn Sie sicherstellen möchten, dass der ESXi VMkernel Ihre VM nicht ausplant (deschedule),

wenn die vCPU im Leerlauf ist, können Sie die folgende Konfigurationsoption hinzufügen.

10 | Gastbetriebssystem

Gehen sie zu vSphere Web Client > Select VM > Edit Settings > VM Options Tab > Advanced >

Configuration Parameters > Edit Configuration und fügen sie den Parameter

"monitor_control.halt_desched" mit dem Wert "false" hinzu. Diese Einstellung bitte nicht anwenden,

wenn Sie bereits den Latency Sensitivity Schalter verwenden.

Bitte prüfen Sie den Einsatz dieser Option, da sie die vCPU effektiv dazu zwingt, alle ihre

zugeordnete pCPU-Zeit zu verbrauchen, so dass der VM-Monitor, wenn diese vCPU im VM-

Leerlauf ist, die CPU nicht an den VMkernel Scheduler zurück gibt, bis die vCPU wieder in der VM

laufen muss. Für extrem latenzempfindliche VMs, die die Latenz nicht tolerieren können, geplant

und ausgeplant zu werden, könnte diese Option helfen.

Ein etwas leistungssparender Ansatz, der zu niedrigeren Latenzen führt, wenn der Gast nach dem

Leerlauf aufgeweckt werden muss, sind die folgenden fortgeschrittenen Konfigurationsparameter

(siehe auch http://kb.vmware.com/kb/1018276):

o Für VMs mit mehr als einer vCPU, setze "monitor.idleLoopSpinBeforeHalt" auf true

o Für VMs mit einer vCPU, setze "monitor.idleLoopSpinBeforeHaltUP" auf true

Diese Option wird dazu führen, dass der VM-Monitor für eine kleine Zeitspanne dreht (Standard

sind 100 ns, konfigurierbar durch den Parameter "monitor.idleLoopMinSpinUS") bevor die CPU

wieder zurückgegeben wird an den VMkernel Scheduler, die dann die CPU im Leerlauf laufen

lassen kann, wenn es keine andere Arbeit gibt. Diese Einstellungen bitte nicht anwenden, wenn

Sie bereits den Latency Sensitivity Schalter verwenden.

2.5 Gastbetriebssystem

Bitte beachten Sie bei der Konfiguration der Ressourcen für das Betriebssystem einer Memory-

latenzsensitiven VM darauf, dass Sie die Architektur des Host-Systems beachten. Geben Sie einer

virtuellen Maschine nie mehr Arbeitsspeicher als einem einzelnen NUMA-Node (CPU-Socket)

zugeordnet ist und gleichzeitig n-1 vCPUs, als einem CPU-Socket zugeordnet ist. Damit stellen Sie

sicher das der ESXi-Hypervisor den lokalen Arbeitsspeicher, der dem CPU-Socket zugeordnet ist

für die VM verwendet und damit auch die niedrigste Latenz hat.

Bitte achten Sie darauf, dass Sie für das Gastbetriebssystem die Energiesparpläne für Memory-

Latenzsensitive VMs auf High Performance stellen und wenn notwendig auch den Turbo Boost

Modus aktivieren. Hierzu geben Sie folgende Befehle an der Kommandozeile ein:

# Powercfg -setacvalueindex scheme_min sub_processor PERFBOOSTMODE 2

# Powercfg -setactive scheme_min

VMware Tools | 11

Die erste Befehlszeile setzt im High Performance Energiesparplan den Processor Performance

Boost Mode auf aktiv. Und der zweite Befehl aktiviert den High Performance Energiesparplan.

Mittel des folgenden Befehls können Sie überprüfen welcher der aktive Energiesparplan ist.

# Powercfg /getactivescheme

Siehe hierzu auch: https://msdn.microsoft.com/en-us/library/windows/hardware/dn567635.

2.6 VMware Tools

Die VMware Tools sind eine Suite von Utilities, die die Leistung des Gastbetriebssystems der

virtuellen Maschine und die Verwaltung der virtuellen Maschine verbessert. Aus der

Performancesicht sind hierbei der VMXNET 3 Treiber (siehe hierzu Kapitel „Einstellungen der

virtuellen Netzwerkkarte“) und der Paravirtual SCSI Controller wichtig. Achten Sie bei der

Konfiguration des Betriebssystems der VM darauf, sowohl den „VMXNET 3“ wie auch den

„VMware Paravirtual SCSI“ Controller zu verwenden.

Siehe hierzu auch: https://kb.vmware.com/kb/1010398.

2.7 NUMA Einstellungen

Durch die Verbreitung von Systemen mit mehreren Kernen werden NUMA-Architekturen

zunehmend eingesetzt, da mit diesen Architekturen eine bessere Leistungsskalierung von

speicherintensiven Arbeitslasten erzielt werden kann. Bei den modernen Intel- und AMD-Systemen

ist die NUMA-Unterstützung im Prozessor integriert.

Normalerweise können Sie BIOS-Einstellungen verwenden, um NUMA-Funktionen zu aktivieren

und zu deaktivieren. Wenn NUMA aktiviert ist, wird vom BIOS eine Tabelle für die Zuteilung von

Systemressourcen (SRAT, System Resource Allocation Table) erstellt, die vom ESXi Hypervisor

verwendet wird, um die in Optimierungen verwendeten NUMA-Informationen zu generieren. Um

eine gleichmäßige Planung sicherzustellen, werden NUMA-Optimierungen nicht für Systeme mit

zu wenig Kernen pro NUMA-Knoten oder zu wenig Kernen insgesamt aktiviert. Zur Änderung

dieses Verhaltens können Sie die Optionen "numa.rebalancecorestotal" und

"numa.rebalancecoresnode" ändern.

ESXi nutzt einen anspruchsvollen, NUMA-fähigen Scheduler, um die Prozessorbelastung und den

Speicherort dynamisch auszugleichen.

Für die beste Leistung von latenzempfindlichen Anwendungen in Gastbetriebssystemen sollten

alle vCPUs auf demselben NUMA-Knoten geplant werden, und der VM-Arbeitspeicher sollte aus

dem der CPU zugeordneten lokalen physischen Speicher zugewiesen werden, der an diesen

NUMA-Knoten angeschlossen ist.

12 | NUMA Einstellungen

Prozessor-Affinität für vCPUs, die auf bestimmten NUMA-Knoten geplant werden sollen, sowie die

Memory-Affinität für den VM-Arbeitsspeicher, die von diesen NUMA-Knoten zugewiesen werden

sollen, können mit dem vSphere-Client unter Edit Settings > VM Options > Advanced >

Configuration Parameters > Edit Configuration konfiguriert werden. Hierzu wird die Einstellung

"numa.nodeAffinity = 0, 1, ...", wobei 0, 1 usw. die Prozessorsockelnummern sind, vorgenommen.

Beachten Sie, dass Sie, wenn Sie die NUMA-Knoten-Affinitäten konfigurieren, die Fähigkeit des

NUMA-Schedulers beeinträchtigen, ein Load Balancing für die virtuellen Maschinen über alle

vorhandenen NUMA-Knoten durchzuführen. Geben Sie die NUMA-Knotenaffinität nur an, wenn

das automatische Load Balancing nicht zu den gewünschten Resultaten führt. Beachten Sie auch,

dass, wenn eine VM (z.B. mit vMotion) zu einem anderen Host mit einer anderen NUMA-Topologie

migriert wird, diese erweiterten Einstellungen möglicherweise nicht optimal auf dem neuen Host

angewendet werden können und dies zu einer suboptimalen Leistung Ihrer Anwendung auf dem

neuen Host führt. Sie müssen diese erweiterten Einstellungen für die NUMA-Topologie eventuell

erneut für den neuen Host neu anpassen.

Ab ESXi 5.0 unterstützt der Hypervisor auch vNUMA. Hierbei wird die NUMA-Architektur des

zugrunde-liegenden physischen Hosts dem Gast-Betriebssystem offen gelegt, indem bestimmte

ACPI-BIOS-Tabellen für das Gast-Betriebssystem sichtbar werden. Das Aufdecken der NUMA-

Topologie des physischen Hosts an die VM hilft dem Gast-OS-Kernel, bessere Terminierungs- und

Platzierungsentscheidungen für Anwendungen zu schaffen, um Arbeitsspeicherzugriffslatenzen zu

minimieren.

vNUMA wird automatisch für VMs aktiviert, die mit mehr als 8 vCPUs konfiguriert sind, die breiter

sind als die Anzahl der Kerne pro physischem NUMA-Knoten. Für bestimmte latenzempfindliche

Workloads, die auf physischen Hosts mit weniger als 8 Kerne pro physischem NUMA-Knoten

laufen, kann vNUMA vorteilhaft sein. Dies wird durch Hinzufügen eines Eintrags für "numa.vcpu.min

= N" erreicht, wobei N kleiner als die Anzahl der vCPUs in der VM ist. Die Einstellung nehmen Sie

im vSphere Web Client unter Edit Settings > VM Options > Advanced > Configuration Parameters >

Edit Configuration vor.

Um mehr über dieses Thema zu erfahren, verweisen wir auf folgende Links:

http://www.vmware.com/files/pdf/techpaper/VMware-vSphere-CPU-Sched-Perf.pdf

https://blogs.vmware.com/performance/2017/03/virtual-machine-vcpu-and-vnuma-rightsizing-rules-of-

thumb.html.

Einstellungen der physikalischen Netzwerkkarte | 13

2.8 Einstellungen der physikalischen Netzwerkkarte

Die meisten 1GbE- oder 10GbE-NICs (Network Interface Cards) unterstützen eine Funktion namens

Interrupt-Moderation oder Interrupt-Throttling, die Interrupts von der Netzwerkkarte zum Host

zusammenführt, so dass der Host nicht überbeansprucht wird und alle CPU-Zyklen benutzt um die

Interrupts zu verarbeiten.

Die Zeit, die die Netzwerkkarte für die Zustellung eines Interrupts (sendend oder empfangend)

benötigt erhöht die Latenz des Workloads.

Die meisten NICs bieten einen Mechanismus, in der Regel über das ethtool command und/oder

Modulparameter, um die Interrupt-Moderation zu deaktivieren. Unsere Empfehlung besteht darin,

die physische NIC-Interrupt-Moderation auf dem ESXi-Host wie folgt zu deaktivieren:

# esxcli system module parameters set -m ixgbe -p "InterruptThrottleRate=0"

Dieses Beispiel gilt für den Intel 10GbE-Treiber namens ixgbe. Sie finden den passenden

Modulparameter für Ihre Netzwerkkarte, indem Sie zuerst den Treiber mit dem folgenden esxcli

auslesen:

# esxcli network nic list

Die Liste der Modulparameter für den verwendeten Treiber finden Sie folgendermaßen:

# esxcli system module parameters list -m <driver>

Beachten Sie, dass die Deaktivierung der Interrupt-Moderation auf der physikalischen

Netzwerkkarte extrem hilfreich ist für die Verringerung der Latenz von latenzempfindlichen VMs.

Dies kann aber zu Leistungseinbußen für andere VMs auf dem ESXi-Host führen, sowie auch eine

höhere CPU-Auslastung nach sich ziehen, da eine größere Anzahl von Interrupts verarbeitet wird.

Das Deaktivieren der physischen NIC-Interrupt-Moderation kann auch den Nutzen von Large

Receive Offloads (LRO) behindern, da einige physische NICs (wie z.B. Intel 10GbE NICs), LRO

auf der Netzwerkkarte unterstützen, diese automatisch deaktivieren, wenn die Interrupt-Moderation

deaktiviert ist. Die ESXi-Implementierung von Software-LRO hat weniger Pakete die bei jedem

Interrupt in größere Pakete verschmolzen werden. LRO ist ein wichtiges Feature für einen

erhöhten Datendurchsatz bei reduzierter CPU-Auslastung. Dies sollte bei Ihrer Entscheidung

sorgfältig berücksichtigt werden.

14 | Einstellungen der virtuellen Netzwerkkarte

2.9 Einstellungen der virtuellen Netzwerkkarte

Virtuelle Maschinen können mit einem der folgenden Netzwerkkartentypen

(http://kb.vmware.com/kb/1001805) konfiguriert werden:

o Vlance

o VMXNET

o Flexible

o E1000

o VMXNET 2 (Enhanced) oder

o VMXNET 3

Wir empfehlen Ihnen, VMXNET 3 für Ihre latenzempfindlichen oder anderweitig leistungskritischen

VMs zu wählen. VMXNET 3 ist die neueste Generation der paravirtualisierten Netzwerkkarten. Es

bietet erweiterte Funktionen wie Multi-Queue-Unterstützung: Receive Side Scaling, IPv4/IPv6

Offloads und MSI/MSI-X Interrupt Delivery. Moderne Enterprise-Linux-Distributionen, die auf 2.6.32

oder neueren Kerneln basieren, wie RHEL6 und SLES11 SP1, liefern eine Out-of-the-Box-

Unterstützung für VMXNET 3 NICs.

VMXNET 3 unterstützt standardmäßig auch einen adaptiven Interrupt-Coalescing-Algorithmus, wie

er auch in physikalischen Netzwerkkarten implementiert ist. Diese virtuelle Interrupt-Koaleszenz

hilft, hohe Datendurchsätze bei VMs mit mehreren vCPUs mit parallelisierten Workloads (z. B.

mehrere Threads) zu steuern, während gleichzeitig versucht wird, die Latenz der virtuellen

Interrupt-Lieferung zu minimieren.

Wir empfehlen, bei latenzempfindlichen Workloads die virtual interrupt coalescing für VMXNET 3,

wie folgt, zu deaktivieren:

Gehe zu vSphere Web Client > VM Settings > VM Options Tab > Advanced > Configuration

Parameters > Edit Configuration und füge den Parameter "ethernetX.coalescingScheme" mit dem

Wert "disabled" hinzu.

Bitte beachten Sie, dass diese neue Konfigurationsoption nur in ESXi 5.0 und höher verfügbar ist.

Eine alternative Möglichkeit, virtual interrupt coalescing für alle virtuellen NICs auf dem Host zu

deaktivieren, betriff alle VMs, nicht nur die Latenz-sensitiven. Hierfür können Sie folgende

Einstellung vornehmen:

Gehe zu vSphere Web Client > Select Host and Clusters > Select Host > Configure tab > System >

Advanced System Settings > Edit und setze den Wert auf "0" für den Parameter

"Net.CoalesceDefaultOn".

Für Details siehe auch: http://communities.vmware.com/docs/DOC-10892.

LRO deaktivieren in Linux | 15

Ein weiteres Feature von VMXNET 3, das einen hohen Durchsatz bei geringerer CPU-Auslastung

ermöglicht, ist Large Receive Offload (LRO). Mit Large Receive Offload können Sie den CPU-

Overhead bei der Verarbeitung von Paketen, die mit hoher Frequenz aus dem Netzwerk eingehen,

reduzieren.

LRO fasst eingehende Netzwerkpakete zu größeren Puffern zusammen und überträgt die so

entstandenen größeren und weniger zahlreichen Pakete an den Netzwerk-Stack des Hosts oder

der virtuellen Maschine. Die CPU muss nun weniger Pakete als bei deaktiviertem LRO verarbeiten,

was ihre Nutzung im Netzwerk reduziert, besonders bei Verbindungen mit hoher Bandbreite.

Um die höhere Leistung mit LRO zu nutzen, aktivieren Sie LRO entlang des gesamten Datenpfads

auf dem ESXi-Host. Dazu gehören auch VMkernel und Gastbetriebssystem. LRO ist

standardmäßig im VMkernel und den VMXNET3-Adaptern von virtuellen Maschinen aktiviert.

2.10 LRO deaktivieren in Linux

Daher sollten Sie auch die Deaktivierung von LRO berücksichtigen, wenn Ihre latenzempfindliche

Anwendung auf TCP angewiesen ist. Um dies für Linux-Gäste zu tun, müssen Sie den vmxnet3-

Treiber im Gast neu laden:

# Modprobe –r vmxnet3

Fügen Sie die folgende Zeile in der Datei "/etc/modprobe.conf" hinzu (abhängig von Linux

Distribution):

options vmxnet3 disable_lro=1

Anschließend den Treiber neu laden:

# modprobe vmxnet3.

16 | LRO global deaktivieren in Windows

2.11 LRO global deaktivieren in Windows

Um LRO auf einem VMXNET3-Adapter auf einer virtuellen Maschine unter Windows 8 oder

Windows Server 2012 (und höher) zu verwenden, müssen Sie LRO global für das

Gastbetriebssystem aktivieren. Unter Windows wird die LRO-Technologie auch als

„Empfangsseitige Zusammenfügung (Receive Side Coalescing, RSC)“ bezeichnet.

Prozedur

1. Um zu überprüfen, ob LRO global auf einem Windows 8- oder Windows Server 2012-Gastbetriebssystem (und höher) deaktiviert ist, führen Sie den Befehl netsh int tcp show global an der Eingabeaufforderung aus.

Netsh int tcp show global

Der Befehl zeigt den Status der globalen TCP-Parameter an, die auf dem Windows 8.x-

Betriebssystem festgelegt sind.

Wenn LRO auf dem Windows 8- oder Windows Server 2012-System (und höher) global

deaktiviert ist, wird die Eigenschaft „Status Empfangssegmentzusammenfügung“ als

deaktiviert angezeigt.

2. Um LRO global für das Windows-Betriebssystem zu deaktivieren, führen Sie den Befehl netsh int tcp set global an der Befehlszeile aus:

netsh int tcp set global rsc=disabled.