Verwenden Sie auf /390-Servern nach Möglichkeit dedizierte CPUs (siehe Abschnitt "VM2000-Scheduling (/390-Server)"):
Im VM2000-Betrieb ohne zusätzliche CPU-Pools werden alle verfügbaren realen CPUs für das Scheduling der (virtuellen) CPUs aller Gastsysteme verwendet. Für Systeme, an die besonders hohe Performance-Anforderungen gestellt werden (z.B. für Produktivsysteme, im Gegensatz zu Test- oder Entwicklungssystemen), empfiehlt sich daher ein Betrieb, der einem Native-Betrieb sehr nahe kommt.
- Stellen Sie solchen Systemen so viele reale CPUs zur Verfügung, wie es (in Summe) zugeschaltete virtuelle CPUs in den betreffenden Gastsystemen gibt.
Dies führt dazu, dass jede virtuelle CPU eine eigene reale CPU zur exklusiven Nutzung zur Verfügung hat ("dedizierte CPU"). Somit wird unnötiger Overhead durch vermeidbare Cache-Verluste und Wartezeiten auf eine freie, reale CPU oder auf Multiprozessor-Locks verhindert.
Folgende Konfiguration ist beispielsweise dafür geeignet:
- Richten Sie neben dem Standard-CPU-Pool einen weiteren CPU-Pool für kritische Produktivsysteme mit dedizierten realen CPUs ein.
Alle anderen Gastsysteme verwenden den Standard-CPU-Pool mit den verbleibenden realen CPUs (oder weitere CPU-Pools, die sie sich jeweils teilen). Nutzen Sie auf /390-Servern für VMs mit dedizierten CPUs zusätzlich das VM-Attribut VM-ACTIVE-IDLE.
Diese Funktion verhindert, dass virtuelle CPUs im Wartezustand ("Idle") die reale CPU verlassen. Es gibt kaum Hypervisor-Overhead.
Eine Messung auf einem /390-Server mit 4 CPUs und nur einer VM hat gezeigt, dass sich bei Verwendung dedizierter CPUs und Nutzung des VM-Attributs VM-ACTIVE-IDLE der VM2000-Overhead um 75% gegenüber der Verwendung dedizierter CPUs ohne Nutzung des VM-Attributs VM-ACTIVE-IDLE reduziert.Für VMs mit VM-ACTIVE-IDLE ist keine Auswertung der VM-ACTIVE-Zeiten möglich (/SHOW-VM-STATUS oder VM-Report von openSM2).