Virtualisierung mit Server-CPUs: Leistungsbremse inklusive

Wer mit heute verfügbarer Hardware virtualisiert, der möchte verständlicherweise wissen, welche der angebotenen Technologien die beste ist. Dazu muss man einiges über Microbenchmarks wissen. Sie arbeiten zwar einzelne Stärken und Schwächen gut heraus, diese machen sich in der Praxis jedoch weniger dramatisch bemerkbar.

Nimmt man forkwait als Beispiel, so läuft die 64-Bit-Version auf einem AMD Opteron 2384 mit RVI in nur 3,879 Sekunden ab. Wählt man AMD-V, braucht die Maschine 124,317 Sekunden, also 3205 Prozent länger. Das mag erschrecken, relativiert sich jedoch, wenn man überlegt, was dieser Benchmark tut. Er startet eine Millionen Prozesse, die sich sogleich wieder beenden, ohne etwas Sinnvolles zu tun.

Page-Table-Update kommen in der Praxis selbstverständlich vor, aber nicht in der Häufigkeit, wie im Microbenchmark forkwait. Deutlich realistischer als forkwait sind getppid und vor allem memsweep. Allerdings übernimmt ein Server im Praxisbetrieb auch manchmal Aufgaben, die durch Virtualisierung so gut wie gar nicht beeinflusst werden. Das zeigt der Microbenchmark sum.

#include <stdio.h><br />  <br /> int main (int argc, char** argv, char** env) {<br />  <br />   unsigned long long i,s=0;<br />  <br />   for (i = 0; i < 1000000000; i++) {<br />     s = s + i;<br />   }<br />  <br />   printf(„s=%lld, c=%lldn“, s, i*(i-1)/2);<br />  <br />   return 0;<br /> }<br />
Bild 7: sum.c addiert Zahlen ohne größere Anforderungen an Hauptspeicher.

Man erkennt an den Benchmark-Ergebnissen, dass Virtualisierung keinen nennenswerten Einfluss nimmt. Die Ergebnisse liegen nah an der nativen Performance. Die einzige Erkenntnis ist, dass ein 64-Bit-Programm beim Hantieren mit positiven Integer-Zahlen oberhalb von gut vier Milliarden mehr Leistung bringt als ein 32-Bit-Programm.

Bild 10: sum zeigt bei jeder Form von Virtualisierung fast native Leistungswerte.

Bild 11: Da sum 64-Bit-Register nutzen kann, ist es in der 64-Bit-Variante schneller.

Folgt man der Empfehlung, die VMware-Principal-Engineer Ole Agesen auf der VMworld 2008 gegeben hat, so ist Binary Translation den Technologien VT-x und AMD-V in der Praxis überlegen. Für AMD-CPUs empfiehlt Agesen bei 32-Bit-Gastmaschinen auch dann Binary Translation, wenn die CPU über RVI verfügt, schränkt jedoch ein, dass man RVI in Einzelfällen testen sollte.

Bei 64-Bit-Gastmaschinen ist die Entscheidung für Intel-CPUs einfach. Da weder Binary Translation noch EPT auf aktuellen Core-2-CPUs möglich sind, bleibt VT-x. Die Performance ist dabei natürlich nicht optimal.

Bei 64-Bit-Virtualisierung auf AMD-Maschinen empfiehlt Agesen allerdings, RVI zu benutzen und Binary Translation als Plan B im Hinterkopf zu behalten. Zu der unterschiedlichen Einschätzung kommt er wegen des größeren Adressraums von 64-Bit-Betriebssystemen. Wenn das Betriebssystem weiterhin kleine Pages nutzt, erhöht sich dadurch die Größe der Page Tables. Dann habe RVI Vorteile.

Zu Nehalem äußert sich Agesen nicht und verweist auf dessen Nichtverfügbarkeit. Zur Zeit der VMworld 2008 gab es noch keine Nehalem-Desktops. Aus seinen Äußerungen lässt sich schließen, dass man auch bei VMware nicht zu 100 Prozent von AMDs RVI-Technologie überzeugt ist.

Im Endeffekt kann es nicht ausbleiben, dass jeder selbst überprüft, welche Technologie in der einzelnen Gastmaschine die beste Performance bietet. Man kommt nicht umhin, dies im Produktivbetrieb vorzunehmen und die Performance unter Umständen subjektiv "nach Gefühl" zu bewerten. Weder mit Microbenchmarks noch mit Load-Simulatoren kann man eine Produktivumgebung richtig einschätzen. In einer älteren Studie, die allerdings RVI und EPT noch nicht berücksichtigt, kann Agesen mit seinem Kollegen Keith Adams nachweisen, dass auch größere Macrobenchmarks zum Teil dramatische Unterschiede zwischen VT-x und AMD-V einerseits und Binary Translation andererseits aufweisen.

Nur eines lässt sich generell sagen. Wem Stabilität wichtiger ist als Performance, der sollte auf Binary Translation verzichten. Kommt ein Kernel-oder Treiber-Update, das eine selten verwendete Folge von privilegierten Befehlen nutzt, die VMware nicht vorhergesehen hat, oder einen Bug in der Binary Translation auftut, dann stürzt die Gastmaschine ab.