Softwareoptimierung für virtuelle Maschinen

Question

Wenn Sie wissen, dass Ihre Software (kein Treiber, nicht Teil des Betriebssystems, nur eine Anwendung) hauptsächlich in einer virtualisierten Umgebung läuft, gibt es Strategien, um Ihre Code- und/oder Compilereinstellungen zu optimieren? Oder irgendwelche Anleitungen für das, was Sie tun sollten und was nicht?

Hier geht es nicht um einen Leistungsgewinn von 0,0x%, aber vielleicht gibt es nur einfache Dinge, die die Leistung drastisch verbessern oder Dinge, die in virtuellen Umgebungen als katastrophal gelten. Zum Beispiel ist das Aktivieren von CONFIG_PARAVIRT in einem Kernel-Build einfach und kann die Leistung erheblich steigern. Jetzt suche ich nach ähnlichen Dingen für Anwendungen, wenn es welche gibt.

In meinem Fall wird es C++ Code und wahrscheinlich VMWare sein, aber ich möchte die Frage so sprach-/produktunabhängig wie möglich halten. Ich frage mich, ob es überhaupt solche Strategien gibt oder ob das eine völlige Zeitverschwendung wäre - schließlich ist das Konzept der Virtualisierung, dass man sich nicht zu sehr darum kümmern muss.

Answer 1

Der einzige Rat, den ich Ihnen geben kann, ist die sorgfältige Verwendung von mlock()/mlockall() .., während auf der Suche nach Buggy Ballontreibern. Wenn zum Beispiel ein Xen-Gast mit 1 GB gebootet wird und dann auf 512 MB aufgebläht wird, ist es sehr typisch, dass die privilegierte Domäne NICHT darauf schaut, wie viel Speicher der paravirtualisierte Kernel Prozessen (d. H. Committed_AS) tatsächlich verspricht. Eigentlich, mit Xen, hat der privilegierte Host keine Ahnung, was ein solcher Ballon tun wird, wenn er nicht auf Xenbus gesetzt wird. Ich glaube das stimmt auch mit KVM überein, je nachdem wie der Kernel konfiguriert ist .. aber deine Frage geht davon aus, dass wir nichts über solche Dinge wissen :)

Also, schütze Sachen (sei vorsichtig, aber umsichtig) das kann einfach nicht sein ausgelagert, immer für das Szenario "Himmel fällt" verantwortlich.

Auch die Verwendung von posix_fadvise()/posix_madvise(), um dem PV-Kernel zu sagen, wie viel Sie brauchen oder nicht gepuffert werden müssen, ist immer eine gute Idee.

Darüber hinaus gibt es sehr wenig, was Sie tun können, da Sie nur mit dem paravirtualisierten Kernel sprechen, der dafür sorgt, dass Prozesse von der Virtualisierung gar nicht erst erfasst werden.

Ich benutze KVM nicht viel (noch), obwohl ich plane, es in der Zukunft mehr zu erforschen. Allerdings sind 90% der Sachen, die ich in letzter Zeit geschrieben habe, speziell für paravirtualisierte Xen-Gäste gedacht. Leider ein wenig Xen/C centric sein, aber das ist, wo meine Erfahrung ist, und pv_ops ist in Hauptstrecke (bald auch xen-0 ops) :)

Gute Frage, :) btw

Edit:

Als ich "vorsichtig, aber vorsichtig" sagte, meinte ich einen Schritt über konservativ. Wenn Ihr Programm eine Jobstruktur zuweist, die die meisten Funktionen benötigen, sperren Sie sie. Wenn du Puffer allozieren willst, um große Dateien zu lesen, sperre sie nicht. Und sei sicher, posix_fadvise() aufzurufen, damit der Kernel weiß, dass du nur einmal darauf zugreifen willst (wenn das der Fall ist). Informieren Sie den Kernel auch über die Verwendung von Speicherabbilddateien, insbesondere, wenn sie der Organisation von Parallelität dienen.

Kurz gesagt, helfen Ihrem Host-Kernel verwalten Speicher, lassen Sie sich nicht kritisch zugeordnete Blöcke in schmutzige Paging geworfen bekommen, nicht davon ausgehen, Ihr Programm ist wichtiger als alles andere, indem sie alles Verriegelungs es ordnet :)

Entschuldigung für die Mehrdeutigkeit. Der beste Satz, den ich mir vorstellen konnte, war "vorsichtig, aber vorsichtig".

Answer 2

Mein einziger Rat ist, halten Sie Ihren Speicher und E/A-Einsatz niedrig, wenn möglich.

IO in einer VM ist im Vergleich zu physischer Hardware ziemlich langsam. Wenn Sie es vermeiden können, dann vermeiden Sie es.

Answer 3

Die Dinge, die auf echter Hardware langsam sind, sind noch langsamer, wenn das System virtualisiert wird. Es hängt von der verwendeten Virtualisierungstechnologie ab, wie viel langsamer sie werden.

Vermeiden Sie insbesondere alles, was I/O mit der Welt außerhalb der virtuellen Umgebung erfordert. Je nachdem, wie die Dinge eingerichtet sind, umfasst dies das Zeichnen auf dem Bildschirm, das Tauschen und das Disketten- und Netzwerk-I/O. Das ist ungefähr in einer abnehmenden Reihenfolge von Wichtigkeit.

Wenn möglich, täuschen Sie vor, dass Sie für einen zehn Jahre alten Computer schreiben. Wenn Ihre Anwendung auf einem 1999 Desktop-PC oder Laptop funktioniert, sollte es OK tun.

Answer 4

Ich habe festgestellt, dass es alles um I/O geht.

VMs saugen normalerweise sehr schlecht bei IO. Dies macht verschiedene Dinge viel schlimmer, als sie es auf richtigem Blech wären.

Swapping ist vor allem ein schlechter Killer - es macht VM-Performance komplett zunichte, sogar ein wenig, weil IO so langsam ist.

Die meisten Implementierungen haben eine große Menge an IO-Konflikte zwischen VMs, ich habe nicht gesehen, dass dies vermieden wird oder es sinnvoll behandelt.

Verwenden Sie also eine Ramdisc für temporäre Dateien, wenn Sie können, aber nicht zu tauschen, weil das noch schlimmer wäre.