RAM zu swap scheitert?

[iwconfig]

Hi,

auf meinem PC hatte ich vor dem upgrade auf stretch das folgende Problem noch nicht. Seit dem update auf stretch habe ich gelegentlich das Problem, daß der PC für mehrere Sekunden einfriert.

Nach längerem hin und her habe ich festgestellt, daß das genau dann passiert, wenn RAM voll ist (4GB). Früher hat er dann einfach irgendwas in den swap rübergeladen, jetzt scheint er das fast gar nicht mehr zu tun (es sind manchmal so 50MB von den 4,5GB swap belegt). Stattdessen friert er für ein paar Sekunden ein (kann bis zu Minuten gehen).

Wo könnte ich anfangen, nachzuforschen, woran das liegt? Ideen?

[smutbert]

sozusagen das Gegenteil von dem was ich hatte: viewtopic.php?f=33&t=167056

Bist du sicher, dass es am nicht oder kaum verwendeten swap liegt?
Bei mir friert unter Gnome nämlich auch gelegentlich die grafische Oberfläche ein, von einigen Sekunden bis hin zu so lange, bis ich die Geduld verliere und gnome-shell kille und neu starte. (Bei dem was ich hier meine, ist aber wirklich nur die GUI eingefroren - die anderen VTs reagieren prompt.)
Wie man geordnet vorgeht um die Ursache von Mikrorucklern bis hin zu einem einige Zeit lang eingeforenen System zu finden, würde mich allerdings auch interessieren. Ich habe versucht über ssh von einem anderen PC das System mit top, iotop und htop im Auge zu behalten, war mir aber auch nicht sicher auf was ich achten muss, abgesehen vom Offensichtlichen wie z. B. der CPU-Last.

[iwconfig]

Bist du sicher, dass es am nicht oder kaum verwendeten swap liegt?

Naja, also ich habe festgestellt, daß das Einfrieren (oder Ruckeln mit langen Pausen) immer genau dann losgeht, wenn der RAM voll wird. Und selbst wenn es dann so weit ist, wird eigentlich nicht mehr Platz im Swap beansprucht ...

Von daher: Das Problem ist natürlich, daß der RAM voll wird. Aber eigentlich ist der Swap ja dann dazu da, ein bißchen was aus dem RAM zu übernehmen.

Keine Ahnung, ob es noch andere Ursachen geben könnte ...

[MSfree]

Naja, also ich habe festgestellt, daß das Einfrieren (oder Ruckeln mit langen Pausen) immer genau dann losgeht, wenn der RAM voll wird.

Woran erkennst du, daß das RAM "voll" ist?

Was gibt

Code: Alles auswählen

cat /proc/meminfo | grep MemAvailable

in so einem Fall aus?

Wie ist bei dir der Swappiness-Parameter eingestellt?

Code: Alles auswählen

cat /proc/sys/vm/swappiness

Wie alt ist deine Festplatte und hat sie eventuell schon Defekte?

[iwconfig]

Was gibt

Code: Alles auswählen

cat /proc/meminfo | grep MemAvailable

in so einem Fall aus?

Der letzte Wert, den ich vorm Einfrieren bekommen habe, war 33708 kB. Nach dem Einfrieren, jetzt gerade so 10 Sekunden lang, hatte er dann tatsächlich etwas in den swap geschaufelt, dann war wieder etwas mehr RAM frei: 79696 kB -- D.h., swap scheint zu funktionieren, nur dauert es viel zu lang.

Wie ist bei dir der Swappiness-Parameter eingestellt?

Code: Alles auswählen

cat /proc/sys/vm/swappiness

Auf 60.

Wie alt ist deine Festplatte und hat sie eventuell schon Defekte?

Es ist eine SSD, jetzt vielleicht 4 Jahre alt. Ich habe jetzt zuletzt auch befürchtet, das es daran liegen könnte; habe mit der Festplatte aber bisher sonst keine Probleme.

[MSfree]

vorm Einfrieren bekommen habe, war 33708 kB. Nach dem Einfrieren, jetzt gerade so 10 Sekunden lang, hatte er dann tatsächlich etwas in den swap geschaufelt, dann war wieder etwas mehr RAM frei: 79696 kB --

Mit anderen Worten, das System hat 10s gebraucht, um 46MByte RAM-Inhalt in den Swap zu schaufeln. Pi mal Daumen bedeutet das, daß 46MByte auf die SSD geschrieben werden müssen, und auch 46MByte von der Platte gelesen werden müssen. Das ergibt also eine IO-Geschwindigkeit von rund 10MByte/s.

D.h., swap scheint zu funktionieren, nur dauert es viel zu lang.

Swap ist immer lahm. 10MByte/s sind aber für eine SSD eher unterdurchschnittlich. Mehr als 100MByte/s würde ich aber selbst bei einer SSD nicht erwarten, was dann immer noch 1s warten bedeuten würde.

Code: Alles auswählen

cat /proc/sys/vm/swappiness

Auf 60.

Du kannst den Wert im laufenden Betrieb ändern, indem du z.B.

Code: Alles auswählen

cat 90 > /proc/sys/vm/swappiness

ausführst. Das führt zu aggressiverem Swappen. Möglicherweise werden deine Wartephasen dadurch etwas besser verteilt. Statt einmal 10s wartest du dann "nur noch" 20 mal 0.5s.

Es ist eine SSD, jetzt vielleicht 4 Jahre alt. Ich habe jetzt zuletzt auch befürchtet, das es daran liegen könnte; habe mit der Festplatte aber bisher sonst keine Probleme.

Eventuell mal fstrim auf die Datenpartitionen durchführen und die Swappartition mit und ohne Trim-Option ausprobieren: siehe https://wiki.ubuntuusers.de/SSD/TRIM/#T ... -Partition

Mich würde aber mal interessieren, welche Prozesse bei dir so viel Speicher belegen, daß das System überhaupt swappen muß. Ich fahre meine Systeme komplett ohne Swap, wenn mehr als 1GB RAM im System stecken. Eventuell hat eines deiner genutzten Programme ein Speicherleck und "klaut" sich immer mehr Speicher, ohne nicht mehr genutzten Speicher wieder freizugeben.

Speicheraufrüstung auf 8GB?

[iwconfig]

Mit swappiness=90 hat es jetzt ziemlich glatt geklappt, danke. Das Problem ist als vorerst gelöst; ich werde noch ein paar Tage rumprobieren.

Eine Frage dazu: Die debian-Wiki empfiehlt, swappiness bei SSDs sogar nur auf 1 zu stellen (damit die SSD länger lebt): https://wiki.debian.org/SSDOptimization ... the_kernel -- wie schädlich ist dann ein Wert von 90? Ist es möglicherweise sinnvoll, mein Swap auf die HDD zu verlegen, die ich eingebaut habe? (Ich weiß, die wäre natürlich langsamer als die SSD, aber mit hohem swapiness-Wert scheint das ja kein Problem zu sein).

Programme: Thunderbid, TeXstudio jeweils 300-400MB, Firefox 700-800MB; wenn man dann noch ein bißchen Bilder mit gimp bearbeitet, wird es ganz schnell sehr voll ...

[MSfree]

Eine Frage dazu: Die debian-Wiki empfiehlt, swappiness bei SSDs sogar nur auf 1 zu stellen (damit die SSD länger lebt): ... wie schädlich ist dann ein Wert von 90?

90 ist nicht schädlicher als 60. Ein Wert von 1 bedeutet, daß nur im absolut äussersten Notfall geswapt wird, und normalerweise eben gar nicht. Nur "gar nicht" schützt letztlich vor vermehrten Schreibvorgängen. Schau dir mal die SMART-Werte deiner SSD an. Da sollte es auch einen Wert für TBW (= total Bytes written) geben. Der gibt Aufschluß darüber, wie lange die SSD noch leben könnte, denn die Hersteller geben in der Regel einen Wert an, wieviele TBytes an Schreibvorgängen die SSD mindestens halten sollte. In der c't war vor ca. einem Jahr ein extremer Dauerschreibtest mit SSDs durchgeführt worden, bei denen kein Exemplar weniger als das 3-fache der Herstelleangabe an Schreibvorgängen geschafft hat.

Konkrete Werte kann ich dir aber nicht liefern. Ich fahre meine Rechner alle ohne Swap. Die 120GB-SSD in meinem Heimserver hat in 4 Jahren z.B. 527GByte an Daten schreiben müssen. Die Herstelelrangabe für meine SSD liegt bei 60TByte. Lebenserwartung nach Hochrechnung also 480 Jahre. Siehe auch hier:
https://www.heise.de/newsticker/meldung ... 55009.html

Meiner Meinung nach sollte man sich keine allzu großen Sorgen um seine SSD machen. Man kann sein Gewissen aber beruhigen, wenn man die Datenmenge, die bisher geschrieben wurde, per SMART ausliest und ins Verhältnis zum Alter der SSD und zur Herstellerangeb für TBW setzt und das dann noch mit 3 multipliziert.

Ach ja, ich versuche seit 10 Jahren, die nur 8GB kleine SSD in meinem Linuxrouter mit Squid, Mail und Logs kaputt zu schreiben. Bisher erfolglos.

Programme: Thunderbid, TeXstudio jeweils 300-400MB, Firefox 700-800MB; wenn man dann noch ein bißchen Bilder mit gimp bearbeitet, wird es ganz schnell sehr voll ...

Ist das die virtuelle Größe oder die resident Größe? Siehe mal mit top nach. 800MB für Firefox halte ich für arg viel. Meiner liegt im Moment bei 220MB resident size.

[iwconfig]

Okay, super, vielen Dank für die Infos bzgl. SSDs!

Zu firefox-esr: Aktuell hat es laut top 762MB resident size. Keine Ahnung, woran das liegt. Ist ein uraltes Profil, vielleicht schleppt das irgendwas mit? Habe gerade 15 tabs offen (aber zum Großteil seit dem Starten von firefox nicht angeschaut, d.h., sie sind ja eigentlich noch gar nicht geladen) ...