Hi!
Ein paar Anmerkungen:
Der ESX ist NICHT im wesentlichen ein RedHat Linux, sondern eine komplette Eigenentwicklung von VMware.
Beim Speichermanagement gibt es mehrere Mechanismen: Transparent Page Sharing (das wohl codeguru mit Speicherdeduplizierung gemeint hat), Memory Compression, den Balloon Treiber und letztendlich Swapping.
Ziel ist immer, jeder VM genau soviele Resourcen zur Verfügung zu stellen, wie sie benötigt, nicht weniger, aber auch nicht mehr.
Beim Benchmarken in VMs sollte man genau wissen, was der Benchmark macht. Je nach Art der Auslastung spielt der Overhead durch die Virtualisierung eine mehr oder weniger markante Rolle. In der Praxis ist es am besten, wirklich mit der Applikation zu messen, die man auch betreiben will.
Wirklich ausschlaggebend ist der Overhead aber in der PRaxis eh nicht, man will ja konsolidieren, weil die Server sonst nicht gut ausgelastet sind.
Zum Troubleshooting von CPU Problemen als erstes die schon angesprochenen CPU Ready Werte anschauen.
Für eine einzelne VM mehrere vCPUs oder Core, macht Sinn, wenn die Applikation das auch nutzt. Beim Umstellen den Hadware Abstraction Layer (HAL) im Gast beachten! Und immer drauf achten, dass man mehr physikalisch mehr logische CPUs hat als die größte VM auf dem ESX.
Beim Speicher mit overcommittment vorsichtig sein, und am besten die ballooning und swapping werte vom ESX
Bei höheren Konsolidierungsraten (sowie sich das hier im Thread anhört): CPU und RAM sind nicht die einzigen Resourcen: Meist ist die IO Performance zuerst der Engpass.
Wie sind denn die Disk-Latenzzeiten der VMs?
Etwas Referenzliteratur:
http://www.cs.cmu.edu/~15712/papers//waldspurger02.pdf
http://www.vmware.com/files/pdf/techpap ... d-Perf.pdf
http://www.vmware.com/pdf/Perf_Best_Pra ... ere5.1.pdf
http://pubs.vmware.com/vsphere-51/topic ... -guide.pdf
Viele Grüße,
Jörg
