[gelöst] der OOM-Killer schlägt zu

[smutbert]

Hallo,

seitdem ich mehr mit sway als Gnome arbeite, passiert es mir gelegentlich, dass das System kurze Zeit einfriert und wenn es wieder reagiert, ich feststellen muss, dass der OOM einen Prozess gekillt hat, aber ich komme nicht hinter die eigentliche Ursache. Dabei mache ich noch nicht einmal etwas speicherintensives (es sind jedes Mal nur ein paar Terminals, firefox, mpv, gedit und thunderbird gelaufen) und ich habe 32GB Hauptspeicher (aber momentan keinen Swap).
Gekillt wird immer nur irgendetwas harmloses, einmal ein Prozess von sway (swaynag) und einmal ein selbst geschriebenes, simples Minishellskript, aber was gekillt wird hat ja nichts damit zu tun welcher Prozess verantwortlich ist (oder?).

Das Internet ist auch nicht sehr hilfreich, ich finde nur lauter Erklärungen, wieso es gut ist, dass free im Normalfall nur sehr wenig freien Speicher anzeigt. Das letzte Mal war ich auch gerade gar nicht am PC und nachdem ich wieder zurück war, waren laut free 28 GB Hauptspeicher frei, was wohl auch ein Zeichen dafür ist, dass davor jede Menge Speicher belegt gewesen sein muss.

lg smutbert

[whisper]

Kennst du ps_mem.py?
das lässt du mal in einem Terminal laufen, vielleicht entdeckst du den Speicherfresser daurch.
Viel Erfolg.
https://github.com/pixelb/ps_mem

[smutbert]

Nein, kannte ich nicht. Danke, werde ich mir merken.

Ich habe gerade einen neuen (für mich) Befehl entdeckt getconf aus libc-bin. Jetzt weiß ich, dass eine Memory Page bei mir 4096 Byte groß ist. Damit versuche ich die Ausgabe von dmesg, die ich mir aufgehoben habe, zu interpretieren.
Tatsächlich scheint swaynag dafür verantwortlich zu sein, auch wenn ich gar nicht weiß wieso das überhaupt gelaufen ist (das übernimmt in sway die Funktion von Dialogfeldern, zB um nachzufragen ob man sway wirklich beenden will). Ausschnitte vom „ersten Schlag“ des oom-Killers sehen so aus:

Code: Alles auswählen

[…]
[38796.888109] mpd.sh invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
[38796.888111] CPU: 0 PID: 397670 Comm: mpd.sh Not tainted 5.4.0-4-amd64 #1 Debian 5.4.19-1
[…]
[38796.888188] Tasks state (memory values in pages):
[38796.888189] [  pid  ]   uid   tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
[38796.888231] [   1579]  1000   1579  6940293    30945  1298432        0             0 WebExtensions
[38796.888266] [ 295894]  1000 295894  8393968  7254493 58236928        0             0 swaynag
[38796.888538] [ 397670]  1000 397670     1666       71    49152        0             0 mpd.sh
[…]
[38796.888586] Out of memory: Killed process 295894 (swaynag) total-vm:33575872kB, anon-rss:29017972kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:56872kB oom_score_adj:0
[…]

Ich habe mich dabei auf das wesentliche konzentriert, weil mir der Rest eh nichts sagt. Also der unschuldige Prozess, der das oom ausgelöst hat (das ist mein Skript mpd.sh) und die beiden Prozesse mit dem größten Speicherverbrauch (total_vm), wohl ein Teil von firefox (WebExtensions) und eben swaynag, das mir sonst nicht aufgefallen wäre.
Dann ist mir auch erst aufgefallen, dass der oom-Killer ja swaynag und nicht wie ich zuerst gedacht habe, mein Skript gekillt hat.

Etwas später hat der oom-Killer noch einmal zugeschlagen

Code: Alles auswählen

[…]
[40314.147280] Timer invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
[…]
[40314.147354] Tasks state (memory values in pages):
[40314.147354] [  pid  ]   uid   tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
[40314.147398] [   1579]  1000   1579  6935991    23973  1134592        0             0 WebExtensions
[40314.147454] [ 487972]  1000 487972  8393968  7195492 57765888        0             0 swaynag
[…]
[40314.147672] Out of memory: Killed process 487972 (swaynag) total-vm:33575872kB, anon-rss:28781968kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:56412kB oom_score_adj:0
[…]

Wenn ich das recht verstehe hat beim ersten Mal also mein Skript ganz bescheiden ein kleines bisschen Speicher angefordert und weil nichts mehr frei war, das oom ausgelöst. Der oom-Killer hat dann den Prozess mit dem größten Speicherverbrauch gekillt und das war swaynag (mit 8393968*4KB ~ 32 GB, also so ziemlich mein gesamter Hauptspeicher).

Was beim zweiten Mal das „Timer invoked oom-killer“ bedeutet, also wieso ein Timer so etwas auslösen (können) soll ist mir schleierhaft, aber der Rest stimmt weitgehend mit dem ersten Auftritt des oom-Killers überein.


Jetzt müsste ich noch herausfinden wieso swaynag überhaupt gelaufen ist, aber die Information ist verloren, weil der PC die Nacht nicht durchgelaufen ist. „Dialogfeld“ war jedenfalls keines zu sehen und heute läuft swaynag momentan (noch?) nicht.