Ich weiß, dass diese Frage schon einmal in ähnlicher Weise gestellt wurde, aber meine Frage ist spezifischer und die vorhandenen sind alt. Es könnte sich also einiges geändert haben (z. B. wenn man an Vektoranweisungen denkt).
Einfach gesagt, ich habe ein Python-Modul, das ich grundsätzlich immer verwenden muss, und mein Python-Code läuft auf VMs (Typ 1 und 2) viel langsamer (doppelte Laufzeit). Das Modul selbst ist hauptsächlich ein Wrapper/API in der C-Bibliothek, aber nicht exkursiv.
Ich versuche herauszufinden, ob Python selbst betroffen ist oder nur das Modul. Ist also bekannt, dass Python stark leidet, wenn es in einer VM ausgeführt wird?
Antwort1
Aus Ihrer Frage lässt sich nicht erkennen, ob Sie Äpfel mit Äpfeln vergleichen.
In einer richtig konfigurierten und angemessen ausgelasteten Virtualisierungsumgebung erwarte ich, dass die meisten Lasten höchstens ein paar Prozent langsamer laufen als auf Bare Metal. Wenn Ihr Code massiv skalierbar ist und alle verfügbaren Hardwareressourcen nutzen kann, erwarte ich, dass er in einer virtualisierten Umgebung deutlich schlechter abschneidet, insbesondere wenn die Ressourcen knapp sind. Wenn Ihr Code von bestimmter Beschleunigerhardware abhängig ist, sind die Auswirkungen der Virtualisierung implementierungsspezifisch.
Antwort2
Sie haben nichts bewiesen, Sie haben Unmengen von Variablen, die Sie nicht isoliert haben. Python-Version, Betriebssystemversion, Hardwareressourcen, VM-Ressourcenkontingente, CPU-Modell und so weiter.
Profilieren Sie, welche Funktionen in Ihrem Code besonders viel Zeit beanspruchen. Visualisieren Sie es mitFlammendiagramme.Python-basiertes Stack-SamplingEine Implementierung wäre nett, aber ich weiß nicht, wie gut das C-Funktionen erfasst. In diesem Fall sollten Sie betriebssystembasierte Profiler (eBPF, xperf) ausprobieren, die eine bessere Sichtbarkeit in die C-Bibliothek und das Betriebssystem bieten.
Untersuchen Sie im Detail, welche Funktionen langsam sind. Machen Sie sich ein Bild davon, was die Funktion tut, und besorgen Sie sich, wenn möglich, den Quellcode. Zählen Sie die Systemaufrufe, um zu messen, was vom Betriebssystem verlangt wird.
Finden Sie die limitierenden Ressourcen: CPU, Speicher, Festplatte, Netzwerk. Messen Sie diese Ressourcen auf Hostebene mithilfe von Leistungsüberwachungstools.
Vergleichen Sie die Ergebnisse in verschiedenen Umgebungen, auf Bare Metal, mit verschiedenen VM-Typen und unterschiedlicher Hardware. Überlasten Sie Ihre VM-Hosts nicht, weder die CPU noch den RAM. Das ist unfair im Vergleich zu einem dedizierten Bare-Metal-Host.
Dies ist eigentlich eine allgemeine Leistungsuntersuchung, um herauszufinden, welcher limitierende Faktor in Ihrer Umgebung vorliegt. Die Verwendung von Python kann die Codelaufzeit ändern, um ein Profil zu erstellen und zu optimieren.
Antwort3
Es besteht die Möglichkeit, dass der betreffende Code SEHR VIEL Kontextwechsel durchführt (und/oder der Hypervisor den Kontextwechsel verschlimmert, indem er den virtuellen Kern um physische Kerne herum verschiebt). Kontextwechsel können unter einem Hypervisor bis zu 100-mal teurer sein als auf Bare Metal. Cache-Fehler können ebenfalls ein großer Faktor sein, da der Hypervisor virtuelle Kerne um verschiedene physische Kerne herum plant.
Um einige dieser Overheads zu verringern, binden Sie die virtuellen Kerne in physische Kerne ein, legen Sie der VM die zugrunde liegende CPU-Topologie offen (Sockets/Kerne/Threads), halten Sie die VM vollständig innerhalb eines einzelnen NUMA-Knotens und geben Sie dem Gast nicht den vollständigen Satz an CPU-Kernen/Threads, den Sie auf dem Host haben, wenn Ihr Code Cache-/Speicherlatenz-empfindlich ist.
Bei verschiedenen Workloads kann die Leistung unter einem Hypervisor deutlich schlechter sein als auf Bare Metal.Die Zahlen dort sind von vor Jahren, aber ich teste diese Dinge relativ regelmäßig erneut und es hat sich im letzten Jahrzehnt nicht viel geändert.