ich habe gelesendieser Linkgerade eben, und es hat mich zum Nachdenken gebracht.
Vor einiger Zeit habe ich Simulationen auf bis zu 30 Kernen einer 32-Kern-VM gestartet und dazu ein Wrapper-Skript verwendet, nohup perl ...<rest of command>...das STOUT/STDERR aufgerufen und umgeleitet hat. Ich bin nicht sicher, ob die Einzelheiten so relevant sind, daher erspare ich Ihnen die Details.
Vom Konzept her bin ich mit Multithread-Tasking zufrieden, aber ich bin naiv davon ausgegangen, dass es ausreicht, jeden Prozess in meinem Nohup-Aufruf in den Hintergrund zu stellen (jeder Prozess war eine separate Simulation, die dann mehrere Wochen lang lief), um jeden untergeordneten Prozess auf einem eigenen Kern/Thread zu platzieren und dann einfach bis zum Abschluss weiterzumachen, ohne auf GNU Parallels oder etwas Ähnliches zurückzugreifen.
Ich habe sie regelmäßig überprüft und immer gesehen, dass 30 vCPUs an den Aufgaben arbeiteten. Alles wurde in angemessener Zeit abgeschlossen, also scheint an meiner Logik bislang alles in Ordnung zu sein ...
Jemand (ich glaube, irgendwo auf einer SO-Seite) hat mir gesagt, dass dies letztendlich zu „CPU-Thrashing“ führen könnte.
Meine Frage besteht aus mehreren miteinander verbundenen Teilen:
- Erstens: Habe ich mich geirrt, als ich annahm, dass nohup und/oder die Ausführung im Hintergrund ausreichen, um einen Prozess auf einem bestimmten Kern zu fixieren? (Und kann der Prozess, der auf einem bestimmten Kern läuft, im Terminal angezeigt werden? Top sagt Ihnen meines Wissens nur, welche Kerne beschäftigt sind, nicht, welche Aufgabe sie ausführen?)
- Zweitens: Kommt es zu CPU-Thrashing, auch wenn zwei Ersatz-CPUs für die anderen Systemaufgaben zur Verfügung stehen?
- Und schließlich, wenn ich mich nicht geirrt habe, wird ein bestimmter Prozess an eine bestimmte CPU gebunden,und nur diese CPU, oder springen sie je nach Aufrufreihenfolge/Zeitpunkt usw. zwischen Threads hin und her, d. h. wenn ich eine Schleife über Dateien ausführe, wird dann die erste an CPU 0 fixiert, dann 1, 2 und so weiter, bis sie abgeschlossen ist?
Antwort1
Erstens, war ich falsch, als ich annahm, dass nohup und/oder backgrounding ein Prozess ist, der auf einem bestimmten Kern läuft und im Terminal angezeigt wird? Top sagt einem nur, welche Kerne beschäftigt sind, nicht, welche Aufgabe sie meines Wissens nach ausführen?)ausreichend, um einen Prozess auf einem bestimmten Kern zu halten? (Und kann das
Nohup führt Befehle genauso aus, als ob sie ohne ausgeführt würden. Der einzige Unterschied besteht darin, dass sie aus einer Liste von PIDs entfernt werden, an die beim Beenden ein Signal gesendet wird. (Disown funktioniert für Prozesse, die nicht mit Nohup gestartet wurden).
Zweitens: Kommt es zu CPU-Thrashing, auch wenn zwei Ersatz-CPUs für die anderen Systemaufgaben zur Verfügung stehen?
Nur wenn die CPU-Überlastung ohne Nohup auftritt ...
Und schließlich, wenn ich mich nicht geirrt habe: Wird ein bestimmter Prozess an eine bestimmte CPU und nur an diese CPU gebunden, oder springen sie je nach Aufrufreihenfolge/Zeitpunkt usw. zwischen den Threads hin und her, d. h. wenn ich eine Schleife über Dateien ausführe, wird dann der erste an CPU 0 gebunden, dann 1, 2 und so weiter, bis er abgeschlossen ist?
dasselbe wie ohne Nohup ...
Mit PS können Sie anzeigen, auf welchem CPU-Kern ein Prozess ausgeführt wird, und mit Taskset können Sie die Grenzwerte für Kerne begrenzen oder ändern.
ps -eo pid,sgi_p,cmd --sort sgi_p
taskset -c -p 0 1234
Antwort2
nohuprichtet nichts ein, um einen Prozess auf einem bestimmten Kern zu halten. Normalerweise verwenden Sietasksetzusammen mit, nohupum das zu tun. topkann zeigen, auf welchem Kern ein Prozess zuletzt geplant war, es ist die PSpalte.
Die Prozess- und Threadplanung ist im Laufe der Jahre ziemlich komplex geworden, da immer mehr Faktoren berücksichtigt werden müssen: CPU-Affinität, Cache-Affinität, Interrupt-Behandlung, Leistungsumschläge ... Ich würde jedoch keine Leistungseinbußen erwarten, wenn Sie weniger Jobs starten, als Ihnen Kerne zur Verfügung stehen, vorausgesetzt, das System ist nicht zu sehr mit anderen Aufgaben beschäftigt. In ähnlicher Weise können Sie nicht wirklich vorhersagen, auf welcher CPU eine Aufgabe ausgeführt wird, aber wenn es angemessen ist, wird der Scheduler sie wahrscheinlich auf demselben Kern belassen, sobald er einen Kern ausgewählt hat.