clone () / fork () / Die Erstellung von Prozessen ist auf manchen Rechnern langsam

8

Das Erstellen neuer Prozesse ist auf einigen meiner Maschinen sehr langsam und nicht auf anderen.

Die Maschinen sind alle ähnlich, und einige der langsamen Maschinen laufen genau auf derselben Hardware und demselben Kernel (2.6.32-26, Ubuntu 10.04) wie einige der schnellen Maschinen. Aufgaben, bei denen keine Prozesse erstellt werden, weisen auf allen Computern die gleichen Geschwindigkeiten auf.

Zum Beispiel wird dieses Programm ca. 50 mal langsamer auf den betroffenen Rechnern ausgeführt:

%Vor%

Was könnte dazu führen, dass die Erstellung von Aufgaben viel langsamer vonstatten geht, und welche anderen Unterschiede könnte ich in den Maschinen suchen?

Edit1: Laufende Bash-Skripte (da sie viele Unterprozesse erzeugen) sind auf diesen Rechnern auch sehr langsam, und strace auf den langsamen Skripten zeigt die Verlangsamung im clone() -Kernaufruf.

Edit2: vmstat zeigt auf den schnellen vs langsamen Maschinen keine signifikanten Unterschiede. Sie alle haben mehr als genug RAM für ihre Arbeitslasten und gehen nicht zum Tausch.

Edit3: Ich sehe nichts Verdächtiges in dmesg

Edit4: Ich bin mir nicht sicher, warum das jetzt auf stackoverflow ist, ich frage nicht nach dem obigen Beispielprogramm (nur um das Problem zu demonstrieren), sondern über Linux Administration / Tuning, aber wenn Leute denken, dass es hier gehört , cool.

    
Knio 22.03.2011, 06:56
quelle

5 Antworten

2

Wir hatten das gleiche Problem mit unserem Anwendungs-Stack und bemerkten eine massive Verschlechterung der Anwendungsleistung und längere Clone-Zeiten mit strace. Mit Ihrem Testprogramm über 18 Knoten reproduzierte ich Ihre Ergebnisse auf den gleichen 3, mit denen wir langsame Klonzeiten hatten. Alle Knoten wurden auf die gleiche Weise bereitgestellt, jedoch mit geringfügig unterschiedlicher Hardware. Wir haben das BIOS, vmstat, vm.overcommit_memory geprüft und den RAM ohne Verbesserung ersetzt. Wir haben dann unsere Laufwerke auf die aktualisierte Hardware verschoben und das Problem wurde behoben.

CentOS 5.9 2.6.18-348.1.1.el5 # 1 SMP Di Jan 22 16:19:19 EST 2013 x86_64 x86_64 x86_64 GNU / Linux

"schlecht" und "gut" lspci:

%Vor%     
ggriffin 14.03.2013 13:13
quelle
1

Ich könnte mit strace beginnen, um zu sehen, welche Systemaufrufe ausgeführt werden und wo die langsamen hängen. Ich bin auch neugierig, wie Sie waitpid () hier verwenden. Auf meinen Systemen ist die Signatur für waitpid

%Vor%

Es sieht so aus, als ob Sie wait () verwenden, aber die pid des Kindprozesses anstelle eines int "status" übergeben, der ein OR der Statusflags hat, für die Sie testen möchten. Das könnte dazu führen, dass einige seltsame Dinge passieren, würde ich erwarten, wenn die PID als Statusmaske interpretiert wurde.

    
malcolmpdx 22.03.2011 18:55
quelle
0

Zu unterscheiden sind der Kernel (Parameter, Gerätetreiber, aktive Module) und die Hardware (CPU-Version, Anzahl der CPUs, Speicherkonfiguration, Peripheriegeräte).

Außerdem: Ändern Maschinen das Verhalten nach einem Neustart / Aus- und wieder Einschalten?

BEARBEITEN:

Die geringe Leistung hängt wahrscheinlich mit der (virtuellen) Speicherhierarchie zusammen. Diese Hierarchie ist sehr komplex und diese Komplexität kann zu seltsamen Effekten führen. Irgendwo auf dem Weg von TLB zu Datencaches zum Hauptspeicher können merkwürdige Konflikte auftreten. Diese können durch ein etwas anderes Speicherlayout der Kernel der verschiedenen Maschinen verursacht werden, oder weil die Speicherhierarchie (Hardware) tatsächlich etwas anders ist.

Natürlich könnte es andere Gründe geben, ein seltsames Peripheriegerät (Interrupts generieren), eine andere Arbeitslast (z. B. Anzahl aktiver Prozesse), ...

Wenn Sie dieses Problem lösen können, teilen Sie bitte die Ergebnisse! Danke.

    
Mackie Messer 24.03.2011 10:50
quelle
0

Haben Sie die BIOS-Konfiguration überprüft, für den Fall, dass die CPU-Caches deaktiviert sind oder die Stromversorgung gestört ist oder wenn einige Systeme überhitzen oder ein Teil des Speichers untertaktet ist ...

    
rodrigo 09.01.2012 22:16
quelle
0

Sind die Werte von /sbin/sysctl vm.overcommit_memory für alle Systeme gleich? Wenn nicht, könnte das den Unterschied erklären.

Wenn Sie eine Überbelegung zulassen, wird fork() viel schneller. Dies bedeutet jedoch, dass neu zugewiesene Seiten nicht durch RAM oder Swap gesichert werden. Wenn / wenn Sie eine nicht gesicherte Seite berühren, muss das Betriebssystem Unterstützung dafür finden - und wenn dies nicht möglich ist, wird der Prozess beendet. Dies ist kein Problem, wenn das gesamte untergeordnete Element exec() ist, wie es in einem system() -Aufruf der Fall ist, da alle nicht gesicherten Seiten verworfen werden. Es könnte jedoch für andere Benutzer von fork() zu ernsthaften Problemen führen.

    
Stephen Sprunk 09.01.2012 22:09
quelle

Tags und Links