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
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.
Da sehe ich dass einige CPUs voll ausgelastet sind, einige nur zur Hälfte, und ein paar fast idle. Load ist trotzdem bei 80.
:
Bearbeitet durch Admin
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...)
:
Bearbeitet durch User
> 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...
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.
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.
> mich verwirrt die loadavg von 80 bei angeblichen 50 gestarteten > Prozessen. Das heisst, dass auch andere Prozesse im System im Kernel hängen...
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.
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:
1 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
2 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
3 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
4 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
5 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
6 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
7 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
8 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
9 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
10 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
11 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
12 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
13 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
14 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
15 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
16 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
17 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
18 | bomb.sh root pts/1 0.00 secs Mon Oct 7 20:47 |
19 | 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.
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 :-)
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.
:
Bearbeitet durch Admin
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.
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é
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.
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):
1 | #!/bin/bash
|
2 | |
3 | CPUCOUNT=$(cat /proc/cpuinfo | grep processor | wc | awk '{print $1}') |
4 | |
5 | i=0 |
6 | while [ ${i} -lt ${CPUCOUNT} ] ; do |
7 | echo starting process ${i} ... |
8 | ionice -c3 nice -n19 openssl speed & |
9 | i=$(( i + 1 )) |
10 | done
|
und
1 | #!/bin/bash
|
2 | |
3 | CPUCOUNT=$(cat /proc/cpuinfo | grep processor | wc | awk '{print $1}') |
4 | |
5 | i=0 |
6 | while [ ${i} -lt ${CPUCOUNT} ] ; do |
7 | echo starting process ${i} ... |
8 | ionice -c3 schedtool -N -n19 -a ${i} -e openssl speed & |
9 | i=$(( i + 1 )) |
10 | 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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.