Verursacher für Vollschreiben der Auslagerungsdatei finden

[paxtn]

Hallo zusammen,

ich betreibe aktuell ein Kubuntu 19.10 und ab und an passiert es mal, dass plötzlich die Auslagerungsdatei voll geschrieben wird und die SSD nur noch am Arbeiten ist, sodass das System hängen bleibt und es per Reset Knopf neu starten muss.
Das ist natürlich äußerst unschön.

Gibt es irgendwo ein Log oder so, wo ich nachsehen kann, welches Problem/welcher Dienst die Auslagerungsdatei so vollgeschrieben hat und das System damit zum Stillstand gebracht hat?

Vielen Dank im Voraus.

Viele Grüße
paxtn

 

[fixedwater]

Moin,

ein wenig komisch das. Wie viel Arbeitsspeicher ist denn am Start? Was sagt denn ksysguard dazu - also was verbraucht denn da richtig viel RAM?

 

[HisN]

Ich würde auch schauen was das RAM belegt, denn das ist ja der eigentlich Grund warum die Auslagerungsdatei genutzt wird.

 

[Piktogramm]

Ob etwas ins SWAP geschrieben wird entscheidet das Betriebssystem und keine Anwendung!

Ansonsten: https://blog.sleeplessbeastie.eu/2016/12/26/how-to-display-processes-using-swap-space/
Wobei es wie schon gesagt wurde, die Prozesse die Arbeitsspeicher benötigen sind die Schuldigen.

 

[paxtn]

Erstmal danke für die schnellen Antworten.

ein wenig komisch das. Wie viel Arbeitsspeicher ist denn am Start? Was sagt denn ksysguard dazu - also was verbraucht denn da richtig viel RAM?

16GB und in ksysguard konnte ich ja dann plötzlich nichts mehr sehen. Als ich zurück an den PC kam hatte ich nur in der Systemüberwachung in der Infoleiste gesehen, dass der RAM halb voll und die SWAP voll war und er war super langsam mit jeder Mausbewegung und die SSD war nur am Arbeiten. Also hatte ich den PC resettet, aber später fing er wieder an, dass der RAM und die SWAP unnötig voller wurde. Dann habe ich mal stückweise alle Programme beendet und als ich Cryptomator zugemacht habe, war die SWAP plötzlich wieder frei und die RAM Auslastung verringerte sich um ein paar GB.

Ich hatte mal nach einem Zusammenhang gegoogelt und scheinbar gibt es solche Fälle vereinzelt und auch selten auch bei anderen Nufzern. Aber eine richtige Lösung hierfür gibt es scheinbar noch nicht.

Ich würde auch schauen was das RAM belegt, denn das ist ja der eigentlich Grund warum die Auslagerungsdatei genutzt wird.

Interessant ist, dass der RAM nur halb voll ist und dann schreibt das System bereits in die SWAP. wie kann denn so etwas sein?

Ob etwas ins SWAP geschrieben wird entscheidet das Betriebssystem und keine Anwendung!

Ansonsten: https://blog.sleeplessbeastie.eu/2016/12/26/how-to-display-processes-using-swap-space/
Wobei es wie schon gesagt wurde, die Prozesse die Arbeitsspeicher benötigen sind die Schuldigen.

Ich schaue mir den Link mal an, danke dir.

 

[Piktogramm]

Interessant ist, dass der RAM nur halb voll ist und dann schreibt das System bereits in die SWAP. wie kann denn so etwas sein?

Die Frage ist dabei ja, wie du die Auslastung vom Ram feststellst. Je nach Programm wird das ja gern mal recht unterschiedlich interpretiert.
Ansonsten gibt es einen Kernelparameter namens swappiness, welcher das Verhalten beim Auslagern grob festlegt.

 

[Penman]

Sofern den System genügend RAM zu Verfügung hat, kannst du darüber nachdenken, die swappiness runterzusetzen.
Je niedriger der Wert, desto mehr versucht der Kernel alles im RAM zu behalten.

https://linuxhint.com/understanding_vm_swappiness/

Wenn RAM und Swap ausgeschöpft sind, kommt das System in Bedrängnis und der Kernel versucht, den OutOfMemory zu vermeiden, bis der Prozess mit dem höchsten oom_score der Situation zum Opfer fällt.

Wo der Kernel natürlich nichts mehr retten kann, sind z.B. Dateisysteme im RAM wie oftmals /tmp. Wenn dort eine riesige Datei geschrieben wird, ist der RAM schnell voll.

 

[Uridium]

/tmp. Wenn dort eine riesige Datei geschrieben wird, ist der RAM schnell voll.

Und einem Überlauf kann man vorbeugen, indem man die Ordnergröße limitiert.

Bei 16GB würde ich gar kein Swap aktivieren. Im Bedarfsfall kann man das jederzeit kurzfristig aktivieren. Ist mir seit Jahren aber noch nicht passiert.

Hilfreich zur Identifikation des Prozesses könnte ulimit -Sv 500000 sein (Speicherlimitierung pro Prozess auf 500MB). Dann wird sich der Prozess früher oder später schon melden (müssen).

 

[BFF]

als ich Cryptomator zugemacht habe, war die SWAP plötzlich wieder frei

Dann gib das mal an die Entwicker von der Software rueber.

Nicht das diese Software ab z.B. 4 Gbyte auslagert und Dir deshalb die Swap voll pustet.

BFF

 

[mensch183]

Die entscheidende Nachfrage hat @Piktogramm in #6 gestellt. Solange sie unbeantwortet bleibt, wird sich der Thread hier auf wildes Orakeln beschränken müssen.

 

[shinXdxd]

Gib mal cat /proc/sys/vm/swappiness ins Terminal ein. Der Wert kann zwischen 0 und 100 sein. Desto höher, umso eher wird geswappt geschrieben. Der Standardwert ist 60. Umso höher der Wert umso eher wird geswappt. Also kannst du versuchen ob es hilft den Wert niedriger zu setzen.

Für die momentane Sitzung kannst du die swappiness mit
sudo sysctl vm.swappiness=10
ändern.

Für eine permanente Änderung musst du in der Datei
/etc/sysctl.conf
folgende Zeile einfügen: vm.swappiness=10
Statt 10 den gewünschten Wert eintragen.
Quelle: AskUbuntu

Eine weitere Möglichkeit ist zram.

Ist aber halt alles nur Symptom-Bekämpfung ohne das Problem an der Ursache anzugehen.

 

[lokon]

Hilfreich zur Identifikation des Prozesses könnte ulimit -Sv 500000 sein (Speicherlimitierung pro Prozess auf 500MB). Dann wird sich der Prozess früher oder später schon melden (müssen).

Manche Gnome Software mag so etwas gar nicht wegen "Gigacages" - dann mag zB epiphany (der gnome Web-Browser) einfach nicht starten. Grad nochmal in einer VM überprüft (Ubuntu 18.04) und verifiziert.

webkit2gtk (2.20.0-2) unstable; urgency=medium

webkit2gtk 2.20.0 contains a security feature named Gigacage that
requires a virtual memory region of several gigabytes and is used for
variable-length random-access allocations.

One consequence of this is that webkit-based applications may not run if
their maximum virtual memory size is restricted (e.g. using ulimit -v).

If it's not possible to remove the VM size limits the Gigacage can be
disabled by setting the environment variable GIGACAGE_ENABLED=no. Keep
in mind that you will be making your system less secure by doing this.

plötzlich die Auslagerungsdatei voll geschrieben wird und die SSD nur noch am Arbeiten ist, sodass das System hängen bleibt

Das Problem ist eigentlich "bekannt" - siehe zB Kernel Bug (2017) oder in Ubuntu (2013) - und taucht immer wieder mal wieder auf.
Vielleicht hängt das System nicht richtig (sondern nur der Desktop/Grafische Oberfläche) und kann mit Sysreq überredet werden weiterzumachen / kontrolliert zu rebooten.
Ansonsten enthält die Glaskugel (welcher Prozess / Programm? siehe #4 #6) nicht so viel andere Tipps für Einsteiger.

 

[paxtn]

Die Frage ist dabei ja, wie du die Auslastung vom Ram feststellst. Je nach Programm wird das ja gern mal recht unterschiedlich interpretiert.
Ansonsten gibt es einen Kernelparameter namens swappiness, welcher das Verhalten beim Auslagern grob festlegt.

Die Auslastung wird mir einmal im Systemmonitor und in einem SystemInfo-Widget für Kubuntu angezeigt.
Ich werde mich vor allem anhand der Informationen von shinXdxd mal mit swappiness auseinandersetzen.

Sofern den System genügend RAM zu Verfügung hat, kannst du darüber nachdenken, die swappiness runterzusetzen.
Je niedriger der Wert, desto mehr versucht der Kernel alles im RAM zu behalten.

https://linuxhint.com/understanding_vm_swappiness/

Wenn RAM und Swap ausgeschöpft sind, kommt das System in Bedrängnis und der Kernel versucht, den OutOfMemory zu vermeiden, bis der Prozess mit dem höchsten oom_score der Situation zum Opfer fällt.

Wo der Kernel natürlich nichts mehr retten kann, sind z.B. Dateisysteme im RAM wie oftmals /tmp. Wenn dort eine riesige Datei geschrieben wird, ist der RAM schnell voll.

Danke für die tolle Erklärung. Ich werde mich am Wochenende mal mit swappiness auseinandersetzen.

Und einem Überlauf kann man vorbeugen, indem man die Ordnergröße limitiert.

Bei 16GB würde ich gar kein Swap aktivieren. Im Bedarfsfall kann man das jederzeit kurzfristig aktivieren. Ist mir seit Jahren aber noch nicht passiert.

Hilfreich zur Identifikation des Prozesses könnte ulimit -Sv 500000 sein (Speicherlimitierung pro Prozess auf 500MB). Dann wird sich der Prozess früher oder später schon melden (müssen).

Bewirkt der Befehl, dass der Prozess dann gekillt wird? manche Programme, wie Firefox benötigen manchmal eindeutig mehr RAM.

Dann gib das mal an die Entwicker von der Software rueber.

Nicht das diese Software ab z.B. 4 Gbyte auslagert und Dir deshalb die Swap voll pustet.

BFF

Könnte aber auch sein, dass das Problem nur bei mir wegen einer Fehlkonfiguration im System oder so existiert. Erst wenn ich das Problem auf Cryptomator festnageln könnte, könnte ich das an die Entwickler melden.

Gib mal cat /proc/sys/vm/swappiness ins Terminal ein. Der Wert kann zwischen 0 und 100 sein. Desto höher, umso eher wird geswappt geschrieben. Der Standardwert ist 60. Umso höher der Wert umso eher wird geswappt. Also kannst du versuchen ob es hilft den Wert niedriger zu setzen.

Für die momentane Sitzung kannst du die swappiness mit
sudo sysctl vm.swappiness=10
ändern.

Für eine permanente Änderung musst du in der Datei
/etc/sysctl.conf
folgende Zeile einfügen: vm.swappiness=10
Statt 10 den gewünschten Wert eintragen.
Quelle: AskUbuntu

Eine weitere Möglichkeit ist zram.

Vielen Dank für die Erklärungen. Ich werde mir das am Wochenende mal anschauen und ausprobieren (bin aktuell beruflich unterwegs).

Vielleicht hängt das System nicht richtig (sondern nur der Desktop/Grafische Oberfläche) und kann mit Sysreq überredet werden weiterzumachen / kontrolliert zu rebooten.

Es hängt ja auch nicht per se, es ist nur so extrem langsam, dass das Bewegen der Maus Minuten dauert und daher mache ich dann einen Reset.
Wie könnte ich Sysreq denn nutzen?

 

[I'm unknown]

Könnte aber auch sein, dass das Problem nur bei mir wegen einer Fehlkonfiguration im System oder so existiert. Erst wenn ich das Problem auf Cryptomator festnageln könnte, könnte ich das an die Entwickler melden.

Du könntest falls es permanent auftritt mehrere Versuche starten mit deaktiviertem Cryptomator. Tritt es dann nicht mehr auf ist zumindest mit einer starken Tendenz zu rechnen. Kann man Cryptomator nicht mit JVM-Parametern "einbremsen"? Verwende es selbst gerade nur Testweise unter Windows.

 

[Uridium]

Bewirkt der Befehl, dass der Prozess dann gekillt wird? manche Programme, wie Firefox benötigen manchmal eindeutig mehr RAM.

So war das ja gedacht. Du setzt das kurzzeitig auf und wartest bis der vermeintliche Übeltäter (Prozess) in die Falle tappt (zu viel Speicher veranschlagt). Wenn das nicht verhältnismäßig ist, bzw. sich nicht mit deiner Desktopumgebung verträgt, versuche etwas anderes. War nur eine spontane Idee.

 

[Piktogramm]

Die Auslastung wird mir einmal im Systemmonitor und in einem SystemInfo-Widget für Kubuntu angezeigt.
Ich werde mich vor allem anhand der Informationen von shinXdxd mal mit swappiness auseinandersetzen.

und was sagt free -h?

 

[paxtn]

Auf Basis der Beiträge von shinXdxd & Penman habe ich die SWAP mal auf 0 gestellt, also deaktiviert (per vm.swappiness=0 in der /etc/sysctl.conf) und bin gespannt, wie sich das System nun verhält. Es müsste ja im Notfall das jeweilige Programm einfach beenden, um das System zu schützen.

Ich habe auch Screenshots vom Verhalten des Systems gemacht (dabei habe ich auch free -h verwendet, wie von Piktogramm empfohlen):
Cryptomator aktiv:

Wenn ich Cryptomator beendet habe, dann schaut es so aus:

Also im System-Monitor zeigt er mir ca. 500 MB Belastung für Cryptomator an, aber wenn ich die App beende, werden plötzlich 1,6 GB frei. Das ergibt irgendwie keinen Sinn.

Ich verstehe auch nicht, wieso das System bei 8,1 GB nach nur 1 h Nutzung war, obwohl ich neben Cryptomator nur wenige Programme offen hatte (Firefox mit wenig Tabs, Thunderbird, KeepassXC, Dolphin, Tresorit und Dropbox).

So war das ja gedacht. Du setzt das kurzzeitig auf und wartest bis der vermeintliche Übeltäter (Prozess) in die Falle tappt (zu viel Speicher veranschlagt). Wenn das nicht verhältnismäßig ist, bzw. sich nicht mit deiner Desktopumgebung verträgt, versuche etwas anderes. War nur eine spontane Idee.

Ich habe es mal auf 600MB begrenzt und warte mal ab, was sich so ergibt.

Update 19.01. 19:07 Uhr:
Ich habe gerade mal einen langen Test laufen lassen. Firefox 4K Youtube Video abspielen. Das hat für eine lange Zeit problemlos funktioniert. RAM-Auslastung lag bei 9,5 - 9,8 GB (SWAP deaktiviert).

Mit einmal wieder dieser Freeze und ich hatte extra den Systemmonitor offen gelassen. Dort habe ich bei der CPU-Auslastung gesehen, dass neben Thunderbird die plasmashell in disk sleep Modus geschoben wurde. Sobald es in diesen Modus geht, ist das System wie eingefroren. Ich versuche aktuell im Internet herauszufinden, wie man so etwas vermeiden kann. Das Problem gibt es wohl ab und an mal.