Fehlersuche bei starker CPU-Auslastung; ggf. CPU Overprovisioning?

[T-A-Z]

Seit etwa 3 Wochen haben wir auf unserem ESXi eine deutlich erhöhte CPU Last. Sobald die VMs ein bisschen mehr gefordert werden, haben wir schnell 100% konstante Auslastung.
Bis jetzt hat es geholfen die weniger wichtigen VMs zu stoppen, und so die Grundlast zu veringern. Das dies hilft irretiert mich, da die gestoppten VMs eher ideln und kaum Last erzeugen.

Etwas mehr zu unserem System: Ein einzelner ESXi (6.5U1) auf einem Xeon E5-2630v3 (8*2,4 GHz) mit aktiviertem Hypterthreading. Darauf laufen 27 VMs, größtenteils Debian 9, 3x Windows, 1x vCSA. 3 der Linux VMs haben 4 vCPUs zugewiesen, alle anderen haben 2. Hier versteckt sich ggf. auch direkt das Problem: Habe ich zuviele vCPUs verteilt?
Allerdings sind in den letzten 3 Monaten nur 2 kleine VMs dazugekommen, wäre das Problem dann nicht früher aufgefallen?
Der Arbeitsspeicher der VMs ist nicht Over-Provisioned, alle VMs zusammen verbrauchen etwas weniger als dem Host zur Verfügung steht.

Im Rahmen der Fehlersuche habe ich die Community Edition von Veeam ONE installiert. Dieses meldet mir erhöhte Werte für CPU-ready und lässt Overprovisioning als Ursache vermuten. Zu diesem Thema lese ich mich parallel ein; was ich noch nicht finden konnte waren Richtwerte zum Verhältnis vCPUs und Prozessorkernen. Was sind hier übliche Werte?

Insgesamt irretiert mich dass das Problem erst ~Ende Juni aufgetreten ist, nachdem länger keine neue VM eingerichtet wurde. Zu diesem Zeitpunkt wurden nur die VMs gepatcht (reguläre OS-Updates), nicht jedoch der Host. Das werde ich jetzt nachholen.

Ich würde mich sehr über Tipps zur Fehlersuche freuen. Ebenfalls auch über Infos zum Thema CPU Overprovisioning und dessen Auswirkungen.

[irix]

Wer bereits vRO (vRealize Operations Manager) im Einsatz hat der kann diese und aehnliche Frage eigentlich immer beantworten.

Ansonsten.... habt ihr Mitigation gegen L1TF durchgefuehrt und evtl. auf den optional Scheduler v1 umgestellt. Mit 6.7u2latest gibts auch v2 (ob der uer 6.5latest gekommen ist weis ich nicht) wo HyperThreading teilweise wieder zum Einsatz kommt

Schau mal https://kb.vmware.com/s/article/55806

Gruss
Joerg

[T-A-Z]

vRO klingt sehr interessant, leider haben wir die Lizenz dafür nicht. Ich installiere trotzdem mal die Testversion, das möchte ich schonmal ausprobieren.

L1TF Mitigationen klingen nach einer sehr passenden Ursache für dieses Fehlerbild. Die VMs haben auch die entsprechenden Patches erhalten, der Hypervisor jedoch nicht. Ist der Schutz schon aktiv, und habe ich den Performance Malus, wenn nur die VMs gepatcht sind?

[JustMe]

Rechnen wir doch einfach mal schnell nach:
27*2 +3*2 = 60 vCPUs bei den VMs, und der Kernel selber moechte ja auch noch leben.
Und das auf einem einzelnen 8-Kerner, der selbst mit HT nur auf 16 Threads (aka Fake-Cores) kommt.
Zusammen mit dem bereits festgestellten Hinweis auf erhoehte CPU-Ready Werte: Ja, da kann man schon von Overprovisioning sprechen. Die "nicht ausgelasteten" VMs kommen trotzdem immer mal wieder dran, solange sie nicht tatsaechlich gestoppt sind. Und wenn's dann auch noch die 4-vCPU-VMs sind, die ideln, verstaerkt sich der Effekt noch.
Ich habe da was im Hinterkopf, dass man nicht ueber 1:3 (physisch zu virtuell) gehen sollte; manche streben auch eher 1:1 an, um zugesagte Ressourcen auch bereitstellen zu koennen. In frueheren Prae-YouTube-Zeiten erlaubte man fuer Desktops auch bis zu 1:20, aber das ist mittlerweile halt vorbei, wenn man die Anwender nicht dauernd maulend auf dem Teppich stehen haben moechte.
Das haengt selbstverstaendlich auch immer von der tatsaechlichen Auslastung der VMs ab.

Solche Prozessoren kommen ja doch meist in Dual-Socket-Boards zum Einsatz. Vielleicht sollte man einfach noch eine weitere CPU dazu packen? Na gut; haengt auch von der Anzahl der verfuegbaren Lizenzen ab...