Liebe Linux-Gurus,
seit ein paar Tagen (ärgerlicherweise genau seit ich es für einen Vortrag brauchte ...) ist mein Laptop unerträglich reaktionsschlecht und friert immer wieder für mehrere Sekunden ein. Inzwischen ist es eigentlich unbrauchbar. Auf Grund der Plötzlichkeit verdächtige ich v.a. ein Update - das war kürzlich recht üppig ausgefallen, was mich aber nicht sonderlich beunruhigt hatte, weil ich das Gerät länger nicht benutzt hatte.
Ich hatte solche Ressourcen-Probleme in der Vergangenheit schon mit ein paar Programmen wie Firefox oder Atom, die wohl potenziell ziemlich problematisch sind und v.a. riesige Mengen Speicher binden.
Es war aber nicht der Fall: Nach einem Neustart habe ich dieses Bild (htop, vom tty1-Terminal fotografiert) gesehen:
(und ich habe keine 32 Cores ;-) sondern nur 4).
Nach exakt 5 Minuten Uptime erschien dann auch endlich der Desktop! (aber natürlich weitestgehend unbrauchbar).
Beim Neustart mit dem vorherigen Kernel erschien der Desktop zwar bereits nach 2 Minuten, der Load average ging aber trotzdem in den nächsten Minutne in diesen Bereich hoch. Und ist auch jetzt, nach einer Viertelstunde, dauerhaft im zweistelligen Bereich.
Wie kann ich vorgehen, um die Situation zu analysieren und den "Übeltäter" zu finden? Die Prozess-Anzeige in htop zeigt keine *so* gravierenden Probleme. Auffällig ist aber, dass die vier Cores etwa im Sekundentakt zwischen (4 mal) 2% und 60% alternieren.
Ich könnte die Updates rekonstruieren, da sie mit etckeeper geloggt werden. Aber das erscheint mir irgendwie uferlos, und ich wäre froh, wenn ich eher direkt nach Prozessen suchen könnte, die solch eine Überlast verursachen.
Für jeden Hinweis wäre ich dankbar Urs
Am Samstag, 06. Oktober 2018 22:57 CEST, "Stefan Ziegler" stefan.ziegler_zst@gmx.de schrieb:
Hallo Urs,
Hallo zusammen,
Am wichtigsten bei der Load von 19 ist die CPU-Spalte in der Prozessliste von top/htop.
Die Hauptspeichernutzung spielt kaum eine Rolle für eine Überlastung, soweit nicht geswappt wird.
Hmm, so ganz richtig ist das leider nicht. Die Load zeigt eben gerade nicht an wie sehr die CPU(s) ausgelastet sind sondern wie viele PRozesse gerne laufen würden aber nicht können. Zwar ist es durchaus möglich dass die CPU zum Flaschenhlas wird (passiert gerne bei Realtime-Audio mit zu viel Effekten), es gibt aber auch andere Gründe für Staus in der Warteschleife. Eine wichtige Ursache ist Disk-IO. Zwar wird ein Prozess der auf die Platte wartet von Scheduler erst einmal übergangen, das klappt aber leider nicht mehr so ganz wenn der Kernel selbst auf I/O warten muss. Das kann bei NFS eine hängende TCP-Verbindung sein, es reicht aber auch eine sterbende Platte, ein kapputer Controller etc. Die Tatsache dass das schon beim Bootvorgang hängt macht zumindest IO-Probleme wahrscheinlich.
Gruss RalfD
On Sun, Oct 07, 2018 at 11:04:55AM +0200, Ralf Mattes wrote:
Am Samstag, 06. Oktober 2018 22:57 CEST, "Stefan Ziegler" stefan.ziegler_zst@gmx.de schrieb:
Hallo Urs,
Hallo zusammen,
Hoi
was sagt vmstat? Auffälligkeiten in den syslogs (wie sie dieser Tage auch immer heissen mögen)?
lg -- t
Am Sonntag, 07. Oktober 2018 11:23 CEST, tomas@tuxteam.de schrieb:
Hoi
was sagt vmstat? Auffälligkeiten in den syslogs (wie sie dieser Tage auch immer heissen mögen)?
Na, ich denke Urs wird schon dmesg aufgerufen haben, oooder? Das Problem beim debuggen wird ja wohls sein dass die ganzen Tools kaum noch zu starten sind. Falls vmstat funzt schauen ob bi/bo hoch sind und si/so niedrig, falls ja kann man mit iostat erforschen wer (welches device) der Übeltäter ist. Wenn's wirklich IO ist dann hilft iotop weiter.
Gruss RalfD
lg -- t
Ah, und wer's etwas genauer nachlesen will - from my friends at tummy.com:
https://www.tummy.com/articles/isolating-heavy-load/
Gruss RalfD
Am Sonntag, 07. Oktober 2018 11:38 CEST, "Ralf Mattes" rm@mh-freiburg.de schrieb:
Am Sonntag, 07. Oktober 2018 11:23 CEST, tomas@tuxteam.de schrieb:
Hoi
was sagt vmstat? Auffälligkeiten in den syslogs (wie sie dieser Tage auch immer heissen mögen)?
Na, ich denke Urs wird schon dmesg aufgerufen haben, oooder? Das Problem beim debuggen wird ja wohls sein dass die ganzen Tools kaum noch zu starten sind. Falls vmstat funzt schauen ob bi/bo hoch sind und si/so niedrig, falls ja kann man mit iostat erforschen wer (welches device) der Übeltäter ist. Wenn's wirklich IO ist dann hilft iotop weiter.
Gruss RalfD
lg -- t
Hallo Ralf et al.,
erstmal vielen Dank für die Hinweise, die ich zu befolgen versucht habe.
Am 07.10.2018 um 11:38 schrieb Ralf Mattes:
Am Sonntag, 07. Oktober 2018 11:23 CEST,tomas@tuxteam.de schrieb:
Hoi
was sagt vmstat? Auffälligkeiten in den syslogs (wie sie dieser Tage auch immer heissen mögen)?
Na, ich denke Urs wird schon dmesg aufgerufen haben, oooder?
Ganz ehrlich? Daraus werde ich überhaupt nicht schlau :-(
Das Problem beim debuggen wird ja wohls sein dass die ganzen Tools kaum noch zu starten sind.
Nun, das geht schon einigermaßen, *zumindest* auf tty1.
Falls vmstat funzt schauen ob bi/bo hoch sind und si/so niedrig,
Ich weiß nicht, was "hoch" heißt. si/so sind immer "0", bi/bo sind i.d.R. im 2-3-stelligen Bereich, mit einzelnen Ausbrüchen bei bi bis 13000 und bo 3500.
falls ja kann man mit iostat erforschen wer (welches device) der Übeltäter ist.
iostat zeigt mir folgende Devices: sda, dm-0, dm-1, dm-2 Dabei sind sda und dm-2 offenbar gekoppelt, dm-0 hat immer ganz geringe Werte und dm-1 ist überall 0. Auffällig erscheinen mir folgende Einträge: wrqm% util% zwischen 50 und 95% wkB oft hoch, bis 11200 avg-cpu: idle meist über 75%
So, nun aber zu der wichtigsten Beobachtung: Die Überlast ist ganz offensichtlich mit dem grafischen Desktop verbunden. Wenn ich mich nicht grafisch, sondern nur auf tty1 einlogge, dann bleibt die Last im normalen Bereich, fängt also mit ca. 1-2 an und fällt dann dauerhaft unter 1. Logge ich mich anschließend grafisch ein, beginnt die Überlast wieder wie sonst auf 19 zu steigen und sich nach ca. 10 Minuten auf ca. 10 einzupendeln. Nach dem Ausloggen fällt die Last langsam wieder.
Während des ganzen Vorgangs zeigt htop eigentlich keine wirklich auffälligen Prozesse (alles bleibt bei wenigen Prozent CPU, manchmal 10 oder so). Aber es ist eindeutig, dass Cinnamon in irgendeiner Form der Urheber ist. Die Prozesse am oberen Ende sind fast immer Prozesse aus cinnamon-settings-daemon/..., manchmal taucht auch nemo-desktop und nm-applet oben auf.
Diese Prozesse sind es auch, die bei iotop am oberen Ende erscheinen.
Das klingt ein bisschen so, als ob - vielleicht durch Updates - mal wieder ein Desktopmanager unanständig viele Ressourcen frisst (?) Mein PC hat allerdings dasselbe System und kein Problem. Allerdings läuft auf dem PC eine SSD und auf dem Laptop "nur" eine HDD. Aber ich kann mir kaum vorstellen, dass *das* wirklich so fundamentale Unterschiede macht ???
Hmmm.
Wenn's wirklich IO ist dann hilft iotop weiter.
Gruss RalfD
lg -- t
Hallo Urs,
On 10/07/2018 11:27 PM, Urs Liska wrote:
Die Überlast ist ganz offensichtlich mit dem grafischen Desktop verbunden. Wenn ich mich nicht grafisch, sondern nur auf tty1 einlogge, dann bleibt die Last im normalen Bereich, fängt also mit ca. 1-2 an und fällt dann dauerhaft unter 1. Logge ich mich anschließend grafisch ein, beginnt die Überlast wieder wie sonst auf 19 zu steigen und sich nach ca. 10 Minuten auf ca. 10 einzupendeln. Nach dem Ausloggen fällt die Last langsam wieder.
Was verwendest Du für einen Desktop? Hilft es mal einen anderen zu verwenden? Am besten was einfaches wie lxde oder openbox.
Liebe Grüße Uwe
On Sun, Oct 07, 2018 at 11:27:07PM +0200, Urs Liska wrote:
Hallo Ralf et al.,
[...]
Falls vmstat funzt schauen ob bi/bo hoch sind und si/so niedrig,
Ich weiß nicht, was "hoch" heißt. si/so sind immer "0",
Das sind "swap in/swap out". Dieser Tage des billigen (und riesigen!) RAMs swappt keiner mehr[1]. Null ist also gut :-)
bi/bo sindi.d.R. im 2-3-stelligen Bereich, mit einzelnen Ausbrüchen bei bi bis 13000 und bo 3500.
Das ist "das andere" I/O, also gelesene (i) und geschriebene Blocks. Was die Zahlen genau bedeuten kann ich nicht aus dem hohlen Bauch beantworten -- wird auch davon abhängen, was Deine Platte "kann".
Interessanter in diesem Kontext ist die CPU-Spalte: ist sie voll mit userspace (us) beschäftigt, mit Kernelspace (sy), oder wartet sie die ganze Zeit auf die Platte (io)? Letztenfalls, wie Ralf schrieb...
falls ja kann man mit iostat erforschen wer (welches device) der Übeltäter ist.
iostat zeigt mir folgende Devices: sda, dm-0, dm-1, dm-2 Dabei sind sda und dm-2 offenbar gekoppelt, dm-0 hat immer ganz geringe Werte und dm-1 ist überall 0.
Du hast ein LVM: dm-x sind alle "in" sda, die Summe aller dm-x sollte also grob sda ergeben; auf was ist dm-2 gemountet?
Auffällig erscheinen mir folgende Einträge: wrqm% util% zwischen 50 und 95% wkB oft hoch, bis 11200 avg-cpu: idle meist über 75%
Hm. Iostat ist nicht in meinem Hirncache -- vielleicht können andere mehr dazu sagen.
So, nun aber zu der wichtigsten Beobachtung: Die Überlast ist ganz offensichtlich mit dem grafischen Desktop verbunden [...]
Ist jetzt nicht sehr konstruktiv, ich weiss, aber das bestätigt mich darin, dass ich vor rund 10 Jahren schreiend vor allem, was nach "desktop" riecht davongelaufen bin...
Während des ganzen Vorgangs zeigt htop eigentlich keine wirklich auffälligen Prozesse (alles bleibt bei wenigen Prozent CPU, manchmal 10 oder so). Aber es ist eindeutig, dass Cinnamon in irgendeiner Form der Urheber ist. Die Prozesse am oberen Ende sind fast immer Prozesse aus cinnamon-settings-daemon/..., manchmal taucht auch nemo-desktop und nm-applet oben auf.
Vielleicht "zu viele" Prozesse? Aber zuerst würde ich mal die I/O Frage oben klären. Riecht mehr danach, dass etwas Deine I/O-Bandbreite verstopft.
Diese Prozesse sind es auch, die bei iotop am oberen Ende erscheinen.
Das klingt ein bisschen so, als ob - vielleicht durch Updates - mal wieder ein Desktopmanager unanständig viele Ressourcen frisst (?)
Machen die das nicht immer (sorry, ich weiss ;-)
Mein PC hat allerdings dasselbe System und kein Problem. Allerdings läuft auf dem PC eine SSD und auf dem Laptop "nur" eine HDD. Aber ich kann mir kaum vorstellen, dass *das* wirklich so fundamentale Unterschiede macht ???
Wenn I/O-Bandbreite der Flaschenhals ist (und der Zugriff nicht "linear" ist, so dass die Festplatte auch noch mit der Spurwechsellatenz zu kämpfen hat), dann kann es durchaus einen Unterschied machen.
Hmmm.
Dem kann ich mich anschliessen :-)
Cheers -- t
-
Ralf Mattes -
Ralf Mattes -
Stefan Ziegler -
tomas＠tuxteam.de -
Urs Liska -
Uwe Kleine-König