Re: Top, Userprozesse und Systemprozesse
Rolf Reintjes - 05.06.19, 23:28:
> Am 28.05.2019 um 12:02 schrieb ternaryd:
> > Da ich wirklich keine Ahnung habe, woran das
> > liegen kann, weiß ich auch nicht recht, welche
> > weiteren Informationen helfen könnten, die
> > Ursache zu finden. Wenn jemand eine Idee hat,
> > reiche ich das gerne nach.
>
> Die einzige Idee, die mir dazu eingefallen ist: mal htop anstatt top
> verwenden und damit rumspielen.
>
> Bist du in der Sache denn schon irgendwie weiter gekommen?
Ich halte für wichtig, sich erst mal ein konkretes, systematisches (!)
Vorgehen zu überlegen, anstatt auf gut Glück rumzustochern. Ich verweise
dazu auf die systematischen Methoden, die Brendan Gregg in seinem Buch
"Systems Performance" erwähnt¹.
Die USE-Methode² ist bei Resourcen-Auslastung gut, nur ist mir aus dem
Mailinglisten-Thread nicht mal klar, inwiefern da eine Resource wirklich
ausgelastet ist.
Da ich vom Lesen des Threads nicht den Eindruck hatte, dass die CPUs
wirklich ausgelastet sind – stimmt das? – wäre auch die On/Off-CPU-
Analyse eine Idee³.
Ansonsten bliebe das Vergleichen fortzusetzen, jedoch auf systematische
Weise: Erst mal ein Schaubild machen, was es alles für Komponenten gibt
im System und dann mit Checkliste vergleichen, um sicherzustellen, dass
du auch wirklich an allen dir bekannten Stellen geschaut hast. Auch so
könnte das sehr aufwendig sein. Und dann stellt sich die Frage, ob sich
der Aufwand lohnt.
Eine zündende Idee hab ich nicht, da perf auf den Systemen offenbar nicht
funktioniert, und es bislang danach klingt, dass das irgendwie mit
Kernel und/oder Hardware zu tun hat. Hier dennoch mal ein paar Ideen:
Sysdig wäre noch eine Idee, das braucht aber ein Extra-Kernel Modul (in
Debian ab 9 als dkms-Paket enthalten) und scheidet deshalb
wahrscheinlich auch aus.
Es wäre noch eine Idee mit atop[4] mal drauf zu schauen, da es System-
Aspekte etwas ausführlicher anzeigt als top und atop. Atop hat auch die
Möglichkeit, Aufzeichnungen zu machen und sich diese später anzuschauen
oder mit atopsar zu analysieren. Es nutzt das Process Accounting des
Kernels und bekommt daher auch mit, was zwischen Mess-Intervallen
passiert – falls ein Prozess unterhalb einer Sekunde kurzfristig
Maximal-Last erzeugt.
Vielleicht funktioniert auch latencytop auf den Boards. Das braucht aber
CONFIG_LATENCYTOP im Kernel. Das dient dazu, anzuzeigen, welche Prozesse
auf welche Kernel-Operationen warten. Im Debian-Kernel 4.19 ist das
standardmäßig nicht aktiv.
[1] http://www.brendangregg.com/sysperfbook.html
[2] http://www.brendangregg.com/usemethod.html
[3] http://www.brendangregg.com/offcpuanalysis.html
[4] https://atoptool.nl/
https://blog.proact.de/2014/10/28/echtzeit-monitoring-welches-top-darfs-denn-sein/
https://www.linux-community.de/ausgaben/linuxuser/2014/08/top-htop-atop-und-glances-im-vergleich/
Ciao,
--
Martin
Reply to: