SuSE Linux SLES 10: Hohe load average bei hohem Idle Wert

[CoderGrizzly]

Hallo zusammen,

wir haben bei einem Kunden, welcher ESXi 5 einsetzt, ein SuSE Linux SLES 10 als virtuelle Maschine laufen. Wenn sich der Kunde dort einloggt, sieht er, dass die Maschine einen relativ hohen Idle Wert hat (zwischen 90 und 100). Allerdings ist die load average ziemlich hoch.

Erwarten würde man (bei einer VM mit 1 virtuellen CPU):

load average: 0.xx
Idle < 100

load average: 1.00
Idle = 0

load average: 2.00
Idle = 0

Bei dem Kunden sieht die Sache - wie gesagt - jedoch anders aus. Er hat einen hohen load average und eine niedrige Idle. Ich habe mich auch schon mit einem Freund, welcher in dem Bereich fit ist, beraten.

Meine Vermutung ist, dass der Rechner ja eine vitruelle CPU mit bspw. 2.4 GHz von VMware vorgespielt bekommt. Da die physikalische CPU aber durch andere VMs ausgelastet ist, bekommt unsere VM nicht 2.4 GHz, sondern nur ein Bruchteil. Dadurch laufen Prozesse in unserem System auf, welche die CPU benötigen, was den load average in die Höhe schnellen lässt. Die Idle bleibt jedoch hoch, da von den 2.4 GHz nur ein Teil abgerufen wurde (Sprich die CPU Last wird damit indirekt gedeckelt).
Gleiches gilt natürlich auch, wenn durch feste CPU Reservierungen in VMware unsere VM nicht zum Zug kommt.

Mein Freund hat dem zugestimmt. Allerdings habe ich zu dem Problem nichts bei VMware oder sonst im Internet gefunden. Weiß von Euch jemanden einen Artikel, der sich zu dem Thema äußert? Am besten von VMware - damit wird das dem Kunden vorlegen können.

[Dayworker]

Wenn ihr eine CPU mit 2.4GHz habt, wird diese in dieser Form auch der VM durchgereicht und nichts vorgespielt. VMware ist nicht qemu, eine VMware-VM kann daher nur die in der Host-CPU vorhandenen CPU-Eigenschaften durchreichen.
Falls ihr Reservierungen hinsichtlich der CPU vornehmt, bleibt die CPU-Geschwindigkeit immer noch bei 2.4GHz und wird nicht runtergetaktet. Was sich ändert, ist die für die VM zur Verfügung stehende CPU-Zeit. Falls ihr mit der Ausführungszeit einer VM unzufrieden seit, setzt einfach mal die vCPU-Anzahl auf Eins runter. Eine VMware-VM braucht zur Ausführung die in der VMX-Datei eingetragene Anzahl an freien CPU-Kernen oder sie wird beim RR-Mechanismus von VMware erstmal übergangen und erhält dafür einen Bonus in der nächsten Runde. Falls ihr VMs mit Dauervolllast habt, sollten nicht mehr VMs als vorhandene-CPU-Kerne-minus-Eins auf diesem Host laufen. Der ESXi will neben pRAM auch noch einen Kern für seine Verwaltungstätigkeit haben. Steht ihm dieser nicht zur Verfügung, nimmt er sich diesen und die Gesamtsystemperformance sinkt.

Ohne genaue Kenntnis der Gast-Last bzw wodurch die Gast-Last produziert wird, lassen sich keine Vergleiche bei Load Average und Idle anstellen. Dazu ist jedes OS zu unterschiedlich und die Angaben können auch nur einen Mittelwert abbilden, da jede halbwegs aktuelle CPU tausenfach in einer Millisekunden zwischen sämtlichen CPU-Zuständen hin- und herschaltet.

[CoderGrizzly]

Wenn ihr eine CPU mit 2.4GHz habt, wird diese in dieser Form auch der VM durchgereicht und nichts vorgespielt. VMware ist nicht qemu, eine VMware-VM kann daher nur die in der Host-CPU vorhandenen CPU-Eigenschaften durchreichen.
Falls ihr Reservierungen hinsichtlich der CPU vornehmt, bleibt die CPU-Geschwindigkeit immer noch bei 2.4GHz und wird nicht runtergetaktet. Was sich ändert, ist die für die VM zur Verfügung stehende CPU-Zeit.

Okay, war vielleicht etwas unglücklich von mir ausgedrückt, aber das meinte. Das System hat den physikalischen Kern nicht 100% der Zeit. Wobei der Scheduler von Linux davon ausgeht, dass es den Kern die ganze Zeit hat.

Falls ihr mit der Ausführungszeit einer VM unzufrieden seit, setzt einfach mal die vCPU-Anzahl auf Eins runter. Eine VMware-VM braucht zur Ausführung die in der VMX-Datei eingetragene Anzahl an freien CPU-Kernen oder sie wird beim RR-Mechanismus von VMware erstmal übergangen und erhält dafür einen Bonus in der nächsten Runde. Falls ihr VMs mit Dauervolllast habt, sollten nicht mehr VMs als vorhandene-CPU-Kerne-minus-Eins auf diesem Host laufen. Der ESXi will neben pRAM auch noch einen Kern für seine Verwaltungstätigkeit haben. Steht ihm dieser nicht zur Verfügung, nimmt er sich diesen und die Gesamtsystemperformance sinkt.

Ohne genaue Kenntnis der Gast-Last bzw wodurch die Gast-Last produziert wird, lassen sich keine Vergleiche bei Load Average und Idle anstellen. Dazu ist jedes OS zu unterschiedlich und die Angaben können auch nur einen Mittelwert abbilden, da jede halbwegs aktuelle CPU tausenfach in einer Millisekunden zwischen sämtlichen CPU-Zuständen hin- und herschaltet.

Wir haben das gleiche System auf unserem ESXi aufgesetzt und hatten das Problem nicht. Wobei bei uns deutlich weniger VMs laufen und diese auch sehr viel weniger Last produzieren. Deswegen gehe ich davon aus, dass - wie von Dir angesprochen - der Kunde halt (deutlich) mehr virtuelle Kerne an laufende VMs vergeben hat, als der Host überhaupt physikalische Kerne hat. Mein Freund hat das auch schon zu bedenken gegeben.

Gibt es bezüglich der Anzahl Kerne (physikalische vs. virtuelle) irgendeinen Artikel von VMware?

[kastlr]

Hallo zusammen,

habt Ihr mal die CPU Ready Time für die VM überprüft?
Troubleshooting ESX/ESXi virtual machine performance issues

Examine the %READY field for the percentage of time that the virtual machine was ready but could not be scheduled to run on a physical CPU.

Under normal operating conditions, this value should remain under 5%. If the ready time values are high on the virtual machines that experience bad performance, then check for CPU limiting.

Schönes Wochenende,
Ralf

[CoderGrizzly]

Hallo zusammen,

habt Ihr mal die CPU Ready Time für die VM überprüft?
Troubleshooting ESX/ESXi virtual machine performance issues

Examine the %READY field for the percentage of time that the virtual machine was ready but could not be scheduled to run on a physical CPU.

Under normal operating conditions, this value should remain under 5%. If the ready time values are high on the virtual machines that experience bad performance, then check for CPU limiting.

Schönes Wochenende,
Ralf

Nein, bisher noch nicht. Danke für den Tipp und ebenfalls schönes Wochenende.

[Dayworker]

Okay, war vielleicht etwas unglücklich von mir ausgedrückt, aber das meinte. Das System hat den physikalischen Kern nicht 100% der Zeit. Wobei der Scheduler von Linux davon ausgeht, dass es den Kern die ganze Zeit hat.

Schau dir mal an, mit welchem internen Takt eure Distro arbeitet. Während der Kernel 2.4.X damals noch mit gemächlichen 100Hz lief, hatte Linus den Takt für 2.6.X auf 1000Hz hochgeschraubt. Inzwischen scheinen sich 250Hz eingebürgert zu haben. Unter Umständen gehen dem Linux-Kernel deshalb einige Takte und somit interne Ausführungszeit "verloren", was auf einem virtualisierten System aufgrund der variablen Zeit natürlich häufiger vorkommt.

Wir haben das gleiche System auf unserem ESXi aufgesetzt und hatten das Problem nicht. Wobei bei uns deutlich weniger VMs laufen und diese auch sehr viel weniger Last produzieren. Deswegen gehe ich davon aus, dass - wie von Dir angesprochen - der Kunde halt (deutlich) mehr virtuelle Kerne an laufende VMs vergeben hat, als der Host überhaupt physikalische Kerne hat. Mein Freund hat das auch schon zu bedenken gegeben.

Gibt es bezüglich der Anzahl Kerne (physikalische vs. virtuelle) irgendeinen Artikel von VMware?

Wie muß man deine Aussage "das gleiche System auf unserem ESXi aufgesetzt" einordnen? Läuft die VM nur auf einem anderen ESXi nicht oder kommt dort eine andere VMware-Virtualisierungslösung zum Einsatz?
Prinzipiell kann eine VMware-VM nie mehr vCPUs bzw Kerne bekommen, als der Host zur Verfügung hat. Eine Quad-VM auf einem Dualcore-Host wird daher mit dem Hinweis auf unzureichende CPU-Ressourcen erst garnicht gestartet.

Eigentlich bei allen VMware-Produkten geht man laut deren offizieller Doku immer von max 4 VMs pro CPU-Kern aus, da ansonsten mehr Zeit für Verwaltungsarbeit aufgebracht werden muß, als den VMs am Ende noch zur Verfügung steht. Das kann bei lastreichen VMs natürlich bereits deutlich zu hoch gegriffen sein, bei nur im Leerlauf befindlichen VMs kann die neben der Verwaltungstätigkeit verbleibende Systemperformance aber immer noch ausreichend sein. Kastlr's Link sollte dir da weiterhelfen, die Sache einzugrenzen.