Linux: worauf wartet der Prozess?

[Andreas S. (andreas) (Admin)]

Hallo,

ich habe hier den Fall, dass ein Programm (HVite) das von einem 
Shell-Skript mehrfach parallel gestartet wird die CPUs nicht voll 
auslasten möchte; d.h., top zeigt bei jedem Prozess nur ca. 50% 
Auslastung an, obwohl mehr CPUs (64) als Prozesse (50) vorhanden sind. 
Gesamt-CPU-Auslastung ist ca. 70%, iowait ist 0%. Trotzdem ist die 
system load teilweise über 70. Den Effekt habe ich bei anderen 
Programmen noch nicht beobachtet; wenn auf dem Rechner z.B. 64 
MATLAB-Instanzen rechnen, dann nutzt jeder Prozess 100% CPU und die Load 
ist exakt bei 64.

I/O scheint nicht der begrenzende Faktor zu sein. Kennt jemand ein Tool, 
mit dem ich feststellen kann worauf die Prozesse warten wenn sie nicht 
ausgeführt werden? Oder gibt es eine andere mögliche Erklärung für das 
Verhalten?

Gruß
Andreas

[Luxxer (Gast)]

drück mal 1 in Top, dann werden die CPUs einzeln angezeigt, bei so 
vielen Cores vielleicht unübersichtlich, aber vielleicht siehst du ob 
HVite eine CPU voll auslasten kann.

[Andreas S. (andreas) (Admin)]

Da sehe ich dass einige CPUs voll ausgelastet sind, einige nur zur 
Hälfte, und ein paar fast idle. Load ist trotzdem bei 80.

[Michael R. (Firma: Brainit GmbH) (fisa)]

was ist denn das für eine Maschine mit 64 Cores?

Könnte Hyperthreading was damit zu tun haben? Nachdem das keine 
vollwertigen und unabhängigen Cores sind, könnte das vielleicht einiges 
erklären...

Falls intel: hast mal i7z probiert? das gibt viele internas preis (u.a. 
auch den Unterschied physical/logical core)

Noch ein nachtrag: loadavg ist 80 bei wievielen Prozessen? (AFAIK ist 
die loadavg die Anzahl der prozesse die gerne laufen würden, wenn sie 
denn ressourcen bekämen, aber das kann sich inzwischen geändert 
haben...)

[Georg A. (georga)]

> Könnte Hyperthreading was damit zu tun haben? Nachdem das keine
> vollwertigen und unabhängigen Cores sind, könnte das vielleicht einiges
> erklären...

Das lastet trotzdem alle Möchtegern-Cores zu 100% aus...

Man könnte mal strace auf so einen 50%-Prozess werfen um zu sehen, was 
er so macht. Load entsteht ja eigentlich nur dann, wenn Prozesse warten 
müssen, obwohl sie rechnen könnten. Die sind also wohl im Kernel 
unterwegs und blockieren sich gegenseitig...

[Michael R. (Firma: Brainit GmbH) (fisa)]

Georg A. schrieb:
>> Könnte Hyperthreading was damit zu tun haben? Nachdem das keine
>> vollwertigen und unabhängigen Cores sind, könnte das vielleicht einiges
>> erklären...
>
> Das lastet trotzdem alle Möchtegern-Cores zu 100% aus...

stimmt auch wieder.

mich verwirrt die loadavg von 80 bei angeblichen 50 gestarteten 
Prozessen.

Was ich schon mal hatte, waren Prozesse die ununterbrochen geforkt und 
das child sich wieder beendet haben. Das ganze so schnell, dass man sie 
nie wirklich sehen konnte.

[Gerd E. (robberknight)]

Andreas Schwarz schrieb:
> Kennt jemand ein Tool,
> mit dem ich feststellen kann worauf die Prozesse warten wenn sie nicht
> ausgeführt werden? Oder gibt es eine andere mögliche Erklärung für das
> Verhalten?

Du könntest perf ( https://perf.wiki.kernel.org/ ) nehmen um zu 
analysieren was genau los ist.

Michael Reinelt schrieb:
> Was ich schon mal hatte, waren Prozesse die ununterbrochen geforkt und
> das child sich wieder beendet haben. Das ganze so schnell, dass man sie
> nie wirklich sehen konnte.

Ja, das kenne ich auch. Forken kann ganz schön Last erzeugen und das 
System in die Knie zwingen. Mit top alleine kommt man dem dann nicht auf 
die Spur.

[Georg A. (georga)]

> mich verwirrt die loadavg von 80 bei angeblichen 50 gestarteten
> Prozessen.

Das heisst, dass auch andere Prozesse im System im Kernel hängen...

[Jörg W. (dl8dtl) (Moderator)]

Andreas Schwarz schrieb:
> Kennt jemand ein Tool, mit dem ich feststellen kann worauf die Prozesse
> warten wenn sie nicht ausgeführt werden?

ps aux, sieh dir den "wchan" mal an.

Allerdings habe ich unter Linux teilweise auch seltsame Effekte in
dieser Hinsicht erlebt, da scheint die Lastberechnung manchmal aus
dem Ruder zu laufen.  Sind möglicherweise Synchronisationseffekte:
wenn man immer zur gleichen Zeit sampelt, ergibt sich u. U. ein
falsches Bild, wenn das gesampelte Ereignis synchron mit den
Zeitschritten läuft.  Habe ich vergleichsweise unter FreeBSD so noch
nie erlebt.

[Robert B. (goldcap)]

Um wirklich alle Prozesse ausnahmslos zu protokollieren, reichen ps, top 
& co nicht ganz, dann kann man das Accounting "acct" aktivieren.

mit "accton on" aktiviert man es
und mit "accton off" schaltet man es wieder aus.

mit z.b. lastcomm oder "dump-acct /var/account/pacct" gibt es dann den 
output.
Der sollte wirklich jeden "Pups" des Systems zeigen.
Angezeigt werden die Prozesses die während das accounting aktiv war 
beendet wurden.

Beispieloutput von lastcomm:

bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47
bomb.sh                root     pts/1      0.00 secs Mon Oct  7 20:47

In top kann man auch filtern, dass nur aktive Prozesse angezeigt werden, 
mit "i" toggelt man die Anzeige.

[Rene H. (Gast)]

Hallo Andreas,

mach doch mal ein strace auf den Prozess (resp. auf ein paar davon). 
Also strace -p <pid>. Dann solltest Du schnell sehen was die da so 
treiben.

Grüsse,
René

PS: Natürlich als root :-)

[Andreas S. (andreas) (Admin)]

Michael Reinelt schrieb:
> was ist denn das für eine Maschine mit 64 Cores?

Ein 4-fach Opteron 6274. Also 64 "relativ echte" Kerne (die teilen sich 
trotzdem noch einiges).

> Könnte Hyperthreading was damit zu tun haben?

Wäre auch mein erster Gedanke gewesen, aber bei anderen Programmen 
(MATLAB) ist so ein Effekt nie zu beobachten gewesen.

Rene H. schrieb:
> mach doch mal ein strace auf den Prozess

Hilft meiner Erfahrung nach nicht so viel, weil man trotzdem nicht sieht 
wo es hängt. Aber ich werde es mal installieren lassen und ausprobieren.

Jörg Wunsch schrieb:
> sieh dir den "wchan" mal an

Guter Tipp, das scheint genau das zu sein was ich brauche.

Gerd E. schrieb:
> Du könntest perf ( https://perf.wiki.kernel.org/ ) nehmen um zu
> analysieren was genau los ist.

Wow, "perf top" ist ja echt mal ein nützliches Tool.

Michael Reinelt schrieb:
> Was ich schon mal hatte, waren Prozesse die ununterbrochen geforkt und
> das child sich wieder beendet haben.

Das würde den Effekt erklären, aber ich bin mir ziemlich sicher dass das 
hier nicht der Fall ist.

Danke für die vielen Tipps, sobald der Rechner wieder frei ist werde ich 
sie ausprobieren.

[Jens G. (jensig)]

Kannst auch mal mit procstack (oder war's unter Linux pstack? Eins von 
beiden jedenfalls ... ;-) einfach mal mehrere Call-Stacks eines 
Prozesses ausdumpen lassen, dann sieht man oft, in welchem Codebereich 
sich der Prozess am häufigsten aufhält, und man kann evtl. anhand der 
Funktionsnamen vermuten, womit die evtl. beschäftigt sind, bzw. wo die 
warten. Wenn das evtl. irgendwelche IPC-Funktionen sind, dann würde ich 
mal vermuten, daß die sich mit anderen Prozessen synchronisieren müssen, 
und deswegen immer irgendwie mal herumhängen.

[Rene H. (Gast)]

pstack gibt es nicht per Default unter Linux, aber auf Solaris. Ich habe 
mir dafür (auf SLES) ein gdb Script gebastelt.

Aber wenn man es nicht oft braucht, mit gdb an den Prozess attachen und 
ein bt machen.

Grüsse,
René

[Jörg W. (dl8dtl) (Moderator)]

Andreas Schwarz schrieb:
>> sieh dir den "wchan" mal an
>
> Guter Tipp, das scheint genau das zu sein was ich brauche.

Es ist natürlich "ps alx", hatte mich vorhin vertan.

Leider wirst du für die Erklärung der wchans jedoch den Kernel-Code
zu Rate ziehen müssen.

[Stephan B. (matrixstorm)]

Hallo.

Fuehr doch bitte einmal "uname -a" bei dir aus und poste das Ergebnis.

Oder kurz: Welche Kernelversion hast du laufen.

Deine Beobachtung koennte vom Loadbalancer herfuehren. Mit vielen Kernen 
faengt dessen Leistungsfaehigkeit an zu leiden. Auch NUMA oder dein 
Arbeitsspeicher insgesamt (pagefault durch staendiges swappen?) kann 
einen Einfluss haben.

Sind die Prozesse die deinen CPU beanspruchen sollen immer rechenbereit, 
oder werden die nur immerwieder neu gestartet?

Installier ggf. einmal das tool "schedtool".
Dann teste einmal die Lastaufteilung von (mittels "killall openssl" 
aufraeumen):

#!/bin/bash

CPUCOUNT=$(cat /proc/cpuinfo | grep processor | wc | awk '{print $1}')

i=0
while [ ${i} -lt ${CPUCOUNT} ] ; do
        echo starting process ${i} ...
        ionice -c3 nice -n19 openssl speed &
        i=$(( i + 1 ))
done

und

#!/bin/bash

CPUCOUNT=$(cat /proc/cpuinfo | grep processor | wc | awk '{print $1}')

i=0
while [ ${i} -lt ${CPUCOUNT} ] ; do
        echo starting process ${i} ...
        ionice -c3 schedtool -N -n19 -a ${i} -e openssl speed &
        i=$(( i + 1 ))
done

und bitte berichte. Die 2. Version setzt CPU-Affinitaet ein und bindet 
jeden Prozess an genau eine CPU - der Loadbalancer ist hier nicht 
autmatisch aktiv und sollte es an keinen anderen Problemen liegen, 
sollte die Last schoen aufgeteilt sein.

MfG (gespannt auf Antwort wartend) Stephan