Das Hinzufügen von mehr Kernen zu virtualbox macht Anwendungen ab 16 Kernen langsamer

Question

Derzeit teste ich eine Anwendung auf einem Server mit 64 Kernen. Auf diesem Server ist virtualbox installiert, das bis zu 32 Kerne verwenden kann, aber nicht mehr (dieses Limit wird von virtualbox angegeben). Aufgrund der Tatsache, dass ich mininet verwende, um meine Anwendung zu testen, benötige ich Root-Rechte, um sie auszuführen. Ich habe keine Root-Rechte auf dem Server, sondern in der VM. Also mein Setup ist:

• Host-64 Kerne hat und ubuntu installiert

• Virtualbox VM mit ubuntu hat 1-32 Kerne

• Meine Anwendung wird auf 16 MININET Hosts laufen, jeder Wirt Ausführen eines Programms, das Multicast und Unicast verwendet, um miteinander zu kommunizieren, aber nicht zu viele Anfragen für jetzt. Etwa 5 Anfragen pro Host nach dem Start. Der Start mit einer Verzögerung von 3 Sekunden Engpässe zu Beginn

• Meine Anwendung verwendet mehr Threads zu vermeiden, aber jede Anwendungsinstanz auf dem Host ist independend der anderen

• Meine Anwendung der APScheduler von Python verwendet und Vollständig in Python geschrieben

Ich dachte, es mit 32 Kernen laufen würde das Beste sein. Aber wenn ich das mache, fängt alles an zu hängen. Ich bekomme Timeouts in APScheduler und die Systemlast ist extrem hoch.

Also versuchte ich es mit jeder Anzahl von Kernen zwischen 1 und 32. Hier sind einige Beispiele:

1 Kern

4 Kerne

8 Kerne

12 Kerne

16 Kernen

20 Kerne

23 Kerne

27 Kerne

32 Kerne

Die x-Achse ist in halben Sekunden, die y-Achse ist die CPU-Auslastung, die von top -b -n 1 in Prozent gemeldet wird. Ich lief die App mit jeder Kernzählung für etwa 10 Minuten. Die blaue Linie ist die durchschnittliche CPU-Auslastung meiner Anwendung. Die rote Linie ist meine Anwendung, die grüne Linie ist die Gesamtsystemlast.

Wie Sie sehen können, wird die Last niedriger bis zu 16 Kernen. Bei Verwendung von mehr als 16 Kernen wird es langsamer und ab ca. 23 Kernen wird es extrem langsam. Sogar so langsam, dass der Prozess, der die CPU-Auslastung protokolliert, nicht einmal mehr aufgerufen wird. Aus diesem Grund sind die Graphen in den letzten Diagrammen kürzer ...

Hat jemand eine Idee, was könnte das Problem sein? Ist das ein bekannter Fehler von virtualbox? Ist das ein Mininet-Problem? oder ein Linux-Problem? Woher weiß ich, welche Teile die extreme Belastung verursachen?

Wenn Sie weitere Informationen benötigen, schreiben Sie bitte einen Kommentar und ich werde die Frage bearbeiten.

Die Last auf dem Gastsystem war nie höher als 50%, also denke ich, das ist nicht das Problem.

Ist es möglich, dass VMWare schneller wäre?

EDIT ich überprüfte die Plots und festgestellt, dass die blaue Linie, die die mittlere CPU-Last meiner Anwendung (Durchschnitt über alle Instanzen auf alle MININET Hosts) beschreibt, wird noch immer höher als 1 bis 2 bis 3 Ändern ... 16 Kerne. Aber von 1 bis 16 Kernen steigt die CPU-Last meiner App nur sehr sehr langsam an. Während dies zunimmt, sinkt die Gesamtsystemlast (was meiner Meinung nach sinnvoll ist, da Ubuntu seine Aufgaben auf verschiedenen Kernen erledigen kann, was schneller ist, solange keine gemeinsamen Ressourcen vorhanden sind).

Warum steigt der Mittelwert? Und warum steigt es ab 16 Kernen exponentiell?

Answer 1

Dieses Verhalten tritt auf, wenn ein Programm über eine Prozessor-Socket-Grenze hinweg ausgeführt wird. Im Allgemeinen werden Sie ein unvorhersehbares Timing-Verhalten feststellen, sobald Ihre Anwendung auf Prozessorkernen mit unterschiedlichen physischen Prozessoren ausgeführt wird.

Angenommen, Ihre 64-Core-Maschine hat vier Prozessorsockel mit jeweils 16 Kernen. Wenn Sie davon ausgehen, dass Ihr Scheduler ein vernünftiger Scheduler ist, der versucht, die Threads einer Anwendung im selben Socket zu gruppieren, sollte Ihre Anwendung eine gute parallele Beschleunigung erhalten zwischen 1 und 16 Kernen, aber es wird beginnen, schlecht zu laufen, wenn es mehr als 16 Kerne verwendet, da einige von denen sich in einem separaten Socket befinden müssen.

Dies gilt sowohl für reguläre Maschinen als auch für virtualisierte Maschinen, aber eine virtuelle Maschine kann noch eine weitere Ebene der Unvorhersehbarkeit hinzufügen, wenn der Scheduler diese Socket-Grenzen nicht kennt.