Prozesse unter Mac OSX verheddern sich und fremde CPU-Auslastung

3233
Mani

Ich arbeite in einer wissenschaftlichen Einrichtung, und eine der Aufgaben, an denen ich gerade arbeite, umfasst das Ausführen von Simulationen und die Ausgabe der Daten, die von der Festplatte auf Festplatte erzeugt werden. Wenn ich "on-the-fly" sage, meine ich, dass das Programm selbst jede Sekunde Daten auf die Festplatte spuckt. Diese Simulationen sind rein in Single Thread C ++ geschrieben und werden auf einem Mac Pro ausgeführt. Die relevanten Spezifikationen dieses Mac sind wie folgt:

OSX Version: 10.6.8 Model Name: Mac Pro Model Identifier: MacPro4,1 Processor Name: Quad-Core Intel Xeon Processor Speed: 2.66 GHz Number Of Processors: 2 Total Number Of Cores: 8

Die Intel Xeons sind für bis zu 8 virtuelle Kerne mit Hyperthreading ausgestattet

Ich führe meine Simulationen in einer einfachen SH-Datei mit der folgenden Syntax aus:

nohup simulation1.o configfile 2> /dev/null > /dev/null & nohup simulation2.o configfile 2> /dev/null > /dev/null &

und so weiter...

Die Verwendung von nohup bedeutet, dass ich mich bei Remote-Arbeiten nicht um zufällige Verbindungsabbrüche kümmern muss.

Wenn ich psnach dem Ausführen von Simulationen, z. B. Simulationen mit meiner bash-Datei, nachsehe, stelle ich fest, dass die Prozesse in der Spalte STATE regelmäßig von "Laufen" zu "Stecken" wechseln. Darüber hinaus würde ich erwarten, dass die CPU-Auslastung für jeden Prozess 100% beträgt, aber stattdessen liegt jeder Prozess bei etwa 28%. (Ich gehe davon aus, dass die CPU-Auslastung für jeden Prozess 100% beträgt. Wenn ich nur eine dieser Simulationen durchführe, ist die CPU-Spalte maximal 100%, zusätzlich zu der Tatsache, dass die Kerne Hyperthreading haben. Dies sind sehr CPU-lastige Simulationen .)

Weiß jemand, was los ist? Speziell:

  • Was bedeutet "stecken" in Bezug auf ps
  • Warum ist die CPU nicht für jeden Prozess voll ausgelastet?

Ich würde mich sehr über eine Hilfe freuen.

4
Ich denke, da Daten on-the-fly auf die Festplatte geschrieben werden, ist es sehr wahrscheinlich, dass der Prozess darauf wartet, dass die Daten meistens geschrieben werden und weniger simuliert wird. Ich denke, Sie sollten einen separaten Thread zum Schreiben auf die Festplatte haben Ozair Kafray vor 12 Jahren 2
@OzairKafray: Das Betriebssystem sollte Schreibvorgänge vollständig asynchron machen, wenn genügend Speicher zum Puffern vorhanden ist. Wenn also der Schreibcode nicht beschädigt wird, ist es unwahrscheinlich, dass das Einfädeln hilft. Es ist viel wahrscheinlicher, dass er auf der Festplatte blockiert wird * liest *. David Schwartz vor 12 Jahren 1
@DavidSchwartaz Ich sehe, du hast höchstwahrscheinlich Recht! Ozair Kafray vor 12 Jahren 0

1 Antwort auf die Frage

1
Mani

Ich habe mein Problem behoben. Es stellte sich als ziemlich subtil heraus, aber dank Ozair traf er den Nagel auf den Kopf. Meine spezifische Simulation liest nicht sehr viele Daten (nur die Initialisierungsparameter), sondern verbringt viel Zeit damit, berechnete Daten auszuspucken. Die grobe Art und Weise, die ich ursprünglich mit dem Standard-C ++ implementiert habe, file.open("tobewritten.dat")ist sehr langsam, auch wenn dies von alleine geschieht. Wenn jedoch mehrere Instanzen ausgeführt werden, müssen die einzelnen Instanzen auf der Festplatte für die "Schreibzeit" lange warten.

Ich habe einige spezifische Lektionen gelernt:

  1. cout << std::endlspült den Puffer bei Gebrauch; Wenn der Puffer nicht voll ist, wird der schnellere Schreibvorgang in den RAM nicht optimal genutzt. Verwenden Sie "\n"und schließen Sie die Datei am Ende. c ++ behandelt den Puffer auf die Festplatte, wenn er voll ist.

  2. Wenn Sie mehrere massive Datendateien (ich spreche GBs) gleichzeitig schreiben, ist es am besten, den Puffer manuell anzugeben. Im Moment habe ich den Puffer auf 50 MB gesetzt. Die Verwendung großer Puffer bedeutet, dass Ihr System mehr Zeit zwischen dem RAM und der CPU aufbringt und nur im Abstand von 50 MB auf die Festplatte (das langsame Bit) speichert

  3. Verwenden Sie nicht einmal coutzum Schreiben in eine Datei. Es ist langsamer als sprintfund seine Varianten.

Mit den oben beschriebenen Methoden habe ich von 28% CPU-Auslastung für jeden Prozess zu 100% CPU-Auslastung gewechselt. Der "steckenbleibende" STATE erscheint nicht mehr.

Verwandte Probleme