Speicherbedarf von Debian -- staendiges Swappen

[mangrove84]

Hallo,

ich habe ein Problem damit, dass meine Neuinstallation von Debian staendig den Swap benutzt und dadurch manchmal extrem langsam ist. Auf meinem alten System, was nur die Haelfte an RAM hat, flutscht alles.

Auf meinen zwei Systemen habe ich im Wesentlichen dieselbe Software: Debian mit XFCE und ich nutze Firefox, Thunderbird, Dropbox, Maple, Gnuplot und eine Reihe Terminals zum Coden.

Einzige Unterschiede:
1) Der alte Rechner hat 4GB RAM, 24GB Swap, und es laeuft Stretch (9.5),
2) Der neue Rechner hat 8GB RAM, 8GB Swap, und es laeuft ein aktuelles Buster.

Der alte Rechner lief wunderbar, es sind 2GB RAM belegt und 5MB Swap.
Der neue Rechner laeuft teilweise wie eine Kruecke, es sind 7GB RAM belegt und 2.5GB Swap.

Woher kommt dieser Unterschied?
`top` zeigt mir, dass auf meinem neuen System Firefox etwa 10% RAM belegt, Maple 2%, Dropbox 1% und X 1%. Warum ist der RAM dann voll und das System ist staendig am Swappen? Es ist mir ein Raetsel.

Bitte um Hilfe! Ich habe schon gegooglet, aber konnte nichts hilfreiches finden und an so einem langsamen Computer zu arbeiten ist echt frustrierend... sogar das wechseln des Desktops zum Checken der RAM-Belegung eben hat mehrere Sekunden gedauert...

[pferdefreund]

irgendwo kann man das Swapverhalten einstellen. War glaube ich, irgendwas im /proc Dateisystem.
Ansonsten wundert mich das aber extrem - na ja Firefox ist ein Ram-Eater (deshalb nehme ich palemoon) und
ich habe hier eine Kiste mit stolzen 1 Gb Ram mit Debian 8 und da läuft ne riesige Postgresql-DB, ein MVS 3.8, ein Webserver und gerade Palemoon, da sieht es so aus - also alles im grünen Bereich. Gut - es läuft kein X-Server aber der braucht ja wohl
keine zig Gb. Wie sieht es denn bei dir aus, wenn Firefox nicht läuft ?

total used free shared buffers cached
Mem: 996 906 90 197 32 637
-/+ buffers/cache: 235 761
Swap: 1951 105 1846
pferd@kschadebian:~$
top - 08:35:03 up 52 days, 22:43, 5 users, load average: 2,18, 2,09, 2,03
Tasks: 152 total, 2 running, 150 sleeping, 0 stopped, 0 zombie
%Cpu(s): 16,5 us, 27,1 sy, 12,0 ni, 17,5 id, 26,1 wa, 0,0 hi, 0,7 si, 0,0 st
KiB Mem: 1020776 total, 930268 used, 90508 free, 33572 buffers
KiB Swap: 1998844 total, 107804 used, 1891040 free. 653320 cached Mem

[MSfree]

irgendwo kann man das Swapverhalten einstellen. War glaube ich, irgendwas im /proc Dateisystem.

Code: Alles auswählen

cat /proc/sys/vm/swappiness

zeigt den Wert für das aktuelle Swap-Verhalten an. Meines Wissens ist der per Default auf 60.

Code: Alles auswählen

echo 1 > /proc/sys/vm/swappiness

Schaltet den Swap praktisch ab und verwendet diesen wirklich nur dann, wenn es gar nicht mehr anders geht.

Meine persönliche Erfahrung ist, daß man swappiness auf 1 stellen sollte oder gleich ganz auf Swap verzichten sollte. OK, wenn man gelegendlich mehr Speicher braucht, als RAM vorhanden ist, kann man auch Swap einrichten. Meiner Meinung nach ist aber eine Maschine, die auslagern muß, schlicht unterdimensioniert. Ständiges swappen legt die Kiste lahm.

[pferdefreund]

legt nicht nur die Kiste lahm - Die Platte, egal ob hd, oder ssd wird von dem ständigen Geschreibsel auch nicht besser.

[Lord_Carlos]

Sicher das 7GB auch wirklich benutzt sind? Also nicht teil von buff/cache sind?

free -m
Neuste version sollte bei "used" schon den cache abrechnen.
Oder htop. Da kann man auch leichte via F6 nach mem % sortieren.

[DeletedUserReAsG]

Ich würde dann doch erstmal abklären, woran es liegt. Dass eine Kiste mit 8GB ins Swappen kommt, ist definitiv nicht normal, sofern man kein entsprechendes Szenario fährt – und in dem Fall wüsste man selbst, woran es liegt.

In der Vergangenheit haben sich oft mal diese FS-Indexer/Desktopsuchmaschinen/wieauchimmerdasheuteheißt für solche Symptome verantwortlich gezeigt. Da würde ich mal gucken, ob vielleicht sowas (Amok) läuft.

Kleiner Tipp am Rande: den SysRq+f aktivieren und ggf. aufrufen, wenn sich mal so gar nix mehr bewegt. Das Ding ruft den OOM-Killer auf, der dann meist sogar den richtigen Prozess abschießt, so dass die Kiste erstmal wieder benutzbar wird.

[mangrove84]

Danke fuer eure Antworten und Tipps!

Ich habe heute morgen die Kiste neu gestartet um mal zu sehen, wann der RAM volllaeuft.
Noch bevor ich mich via xdm angemeldet habe, waren 400MB (auf der Konsole) belegt.
Nach dem Einloggen und starten von XFCE waren es um die 600MB und nachdem ich Firefox (12 offene Tabs) gestartet habe etwa 800MB. In der letzten halben Stunde ist das auf etwa 1GB gestiegen, aber der Swap ist erfreulicherweise immer noch bei 0KB. Mal sehen, wie es weitergeht.

Was ich noch checken kann:
1) /proc/sys/vm/swappiness ist 60. Das stelle ich dann mal auf 1, wie vorgeschlagen.
2) Wenn ich Firefox beende, dann wird nur relativ wenig RAM freigegeben. Vor dem Reboot habe ich saemtliche Programme geschlossen und als nichts mehr gelaufen ist, abgesehen von XFCE waren 5GB RAM belegt und 100MB Swap.
3) Eure anderen Tipps werde ich anschauen, wenn der RAM wieder voll ist.

[mangrove84]

PS: interessant, die /proc/sys/vm/swappiness auf meinem alten System ist auf "0" gestellt. Vielleicht ist das der wesentliche Unterschied?

[uname]

Poste mal die Ausgabe von

Code: Alles auswählen

free -m

[wanne]

Meine persönliche Erfahrung ist, daß man swappiness auf 1 stellen sollte

Die 60 sind nicht sinnvoll für einen Desktop. Und einige Systeme laufen mit 1 auch besser als mit 60. Das gilt aber nur für ein sehr ausgewähltes Systeme, die viel aber nicht ganz viel RAM haben.
Die meisten echten Dekstop Distros haben 10 – Was ein sinnvoller Wert ist.

Obwohl richtig wird das oft missverstanden:

Meiner Meinung nach ist aber eine Maschine, die auslagern muß, schlicht unterdimensioniert. Ständiges swappen legt die Kiste lahm.

Nein, ein vernünftiges System muss den swap nicht nutzen. (Weswegen sie mit 0, 1 oder auch ohne swap gut laufen.)
Aber nur wenige Systeme können die vollständige Platte als cache im RAM halten. Es ist durchaus sinnvoll, selten genutzte Programme in den SWAP zu verdrängen um mehr platz für Festplattencache zu machen. Ständiges swappen legt die Kiste lahm. Muss für jeden Klick erstmal das genutzte Programm aus dem SWAP geholt werden ist die Kiste lahm. Aber wenn du deinen KDM in den SWAP verlagerst stört dich das kein bisschen so oft meldest du dich nicht an. Es ist aber ein bisschen mehr an RAM ~150MiB für den Cache, die deinen Rechner schneller machen können. Gerade Firefox und Thunderbird sind froh um jedes MiB Cache, dass sie bekommen können.
Am Ende ist es heute aber eine zunehmends sinnlose herumtunerei. Auf einem Gesunden Desktop-System hast du so ca. Programm-4GiB-RAM in Benutzung von 2-3GiB allein für den Browser drauf gehen und entsprechend nicht geswappt werden sollten. Ob selbst wenn die swappieness auf 75 steht swappt das weniger als 100MiB von deinen 16GiB.
Der Zugewinn an Cache ist also irgend wo kleiner als 1% gegenüber gar keinem Swap. – Und zugegriffen wird darauf auch genau ein mal beim runter fahren. Mehrken von dem langsameren SWAP tut man also auch nichts.
Problematisch sind die systeme die Ammok laufen. Da sehen dann die Leute die GiB Swap die genutzt werden, um das system noch am Leben zu halten. Die wahrheit ist aber auch, dass das System ohne dann längst abgekratzt wäre.

[mangrove84]

Poste mal die Ausgabe von

Code: Alles auswählen

free -m

Momentan sieht es so aus

Code: Alles auswählen

              total        used        free      shared  buff/cache   available
Mem:           7776        1462        3439         186        2874        5858
Swap:          7988           0        7988

Wie gesagt, habe die Kiste gerade rebootet, und noch nicht vollstaendig benutzt, deshalb geht's noch ohne Swap.
In den letzten zwei Stunden ist alledings die "used" auf knappp 1.5GB angestiegen, obwohl ich nur 2 oder 3 Tabs im Firefox geoeffnet und wieder geschlossen (!) habe, plus ein paar Terminals...

Wer benoetigt diese 700MB an RAM? Und was genau ist "buff/cache" RAM?

[whisper]

Wer benoetigt diese 700MB an RAM? Und was genau ist "buff/cache" RAM?

Buffers werden von vielen Prozessen belegt und beispielsweise als Eingangsqueues und ähnliches benutzt. Zumeist jedoch sind Buffers Ausgaben irgendeines Prozesses und Dateipuffer. Einfach ausgedrückt erlauben sie Prozessen Daten vorübergehend im Speicher zu halten, bis der Prozess Zeit findet diese zu verarbeiten.

Cache bedeutet typischerweise Festplattenpuffer und beinhaltet häufig vorkommende Plattenzugriffe. Wenn mehrere Prozesse auf die selben Dateien zugreifen, werden die meisten dieser Dateien im Cache zwischengespeichert und die Zugriffsgeschwindigkeit auf diese Weise deutlich erhöht.
Siehe auch hier:
Linux_Speichermanagement
Da habe ich das geklaut.

[MSfree]

Momentan sieht es so aus

Code: Alles auswählen

              total        used        free      shared  buff/cache   available
Mem:           7776        1462        3439         186        2874        5858
Swap:          7988           0        7988

...

Wer benoetigt diese 700MB an RAM? Und was genau ist "buff/cache" RAM?

Welche 700MB sind denn hier gemeint?

Mein Stretch-System belegt kurz nach dem Booten mit KDE und Firefox

Code: Alles auswählen

# free
              total        used        free      shared  buff/cache   available
Mem:        8042140      865376     6377752      236996      799012     6702972
Swap:             0           0           0

An die Grenze habe ich das System noch nie gebracht, trotz fehlendem Swap. Buster ist allerdings noch nicht stabil, es ist vorstellbar, daß da noch das ein oder andere Programm unverhältnismässig viel Speicher belegt oder unter einem Memory-Leak leidet. Ich würde mal

Code: Alles auswählen

ps augx

ausführen, das listet dir alle laufenden Prozesse detailiert auf.

[mangrove84]

Welche 700MB sind denn hier gemeint?

Ich meinte die zusaetzlichen 700MB an RAM, die innerhalb von zwei Stunden belegt wurden, ohne dass ich wesentliches am System gearbeitet habe. Nur 2/3 Tabs im Firefox geoeffnet und geschlossen und ein paar Terminals gestartet. Es wundert mich, dass dadurch 700MB RAM "verbraucht" werden.

Jetzt am Abend ist noch ein halbes GB RAM "verbraucht"

Code: Alles auswählen

# free -m
              total        used        free      shared  buff/cache   available
Mem:           7776        1748        2835         213        3192        5537
Swap:          7988           0        7988

Habe nur wenige Tabs geoeffnet und diese auch alle wieder geschlossen. Ein Gnuplot-Fenster ist offen, aber nicht viel mehr als am Morgen. Komisch, dass sich das schleichend fuellt... Mal sehen, wie die naechsten Tage weitergehen...

[whisper]

Hast du dir den Wiki Artikel durchgelesen?
Oder hier: http://virtualthreads.blogspot.com/2006 ... linux.html
Da wird erklärt, warum die Anzeige missverständlich ist

[MSfree]

Ich meinte die zusaetzlichen 700MB an RAM, die innerhalb von zwei Stunden belegt wurden, ohne dass ich wesentliches am System gearbeitet habe.

Ich kann da "nur" 300MB zusätzlich erkennen.

Nur 2/3 Tabs im Firefox geoeffnet und geschlossen und ein paar Terminals gestartet.

Die Anzahl der Tabs im Firefox sind nicht ausschlaggebend. Was zählt ist, was in jedem Tab dargestellt werden muß. Ein Tab mit dem Debianforum braucht kaum Speicher, ein Tab mit der T-Online Startseite braucht hingegen auch mal über 100 Megabytes.

Und, wie gesagt, das, was free liefert, muß man schon zu interprätieren wissen. Eine deutlich detailliertere Ansicht auf die Speicherbelegung liefert

Code: Alles auswählen

cat /proc/meminfo

und hier vor allem der Wert hinter MemAvailable

Code: Alles auswählen

grep MemAvailable /proc/meminfo

Was einzelne Prozesse belegen (ich wiederhole mich), bekommst du mit

Code: Alles auswählen

ps augx

raus. Statt also von 2-3 Tabs und Firefox zu reden, solltest du einfach mal schauen, welcher Prozeß wieviel belegt.

[whisper]

Noch was nützliches.
https://github.com/pixelb/ps_mem/
dieses kleine python tool ps_mem.py habe ich schon vor längerer Zeit benutzt, es half damals bei der Analyse eines ähnlichen Problems.

[mangrove84]

Nur 2/3 Tabs im Firefox geoeffnet und geschlossen und ein paar Terminals gestartet.

Die Anzahl der Tabs im Firefox sind nicht ausschlaggebend. Was zählt ist, was in jedem Tab dargestellt werden muß. Ein Tab mit dem Debianforum braucht kaum Speicher, ein Tab mit der T-Online Startseite braucht hingegen auch mal über 100 Megabytes.

Was ich damit sagen wollte, ist, dass wenn ich ein Tab oeffne und wieder schliesse, dann sollte der benoetigte Speicher eigentlich wieder freigegeben werden. Oder nicht?
Deshalb wunderte ich mich, dass der belegte Speicher angestiegen ist, obwohl sich an den laufenden Anwendungen eigentlich nichts geaendert hat.

Und nun geht das Swappen los!

Code: Alles auswählen

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7776        5910         509         148        1356        1454
Swap:          7988         143        7845

Ich habe vier Instanzen meines Codes laufen (ohne Memory-Leak ), welche jeweils ~800MB RAM belegen. Deshalb ist der "used" Wert jetzt deutlich hoeher. Aber trotz der 1.5GB available/ 500MB free, sind schon 140MB im Swap und ein `git diff` hat gerade etliche Sekunden benoetigt...

Die anderen Links von @whisper schaue ich mir gleich an. Den ersten habe ich schon gelesen, der war sehr interessant!

[MSfree]

Was ich damit sagen wollte, ist, dass wenn ich ein Tab oeffne und wieder schliesse, dann sollte der benoetigte Speicher eigentlich wieder freigegeben werden. Oder nicht?

Nein, der Speicher, den ein Prozeß einmal vom Kernel angefordert hat, wird nicht mehr dem Kernel zurückgegeben. Der Prozeß kümmert sich allerdings intern darum, den einmal reservierten Speicher zu recyclen. Wenn also erneut eine Speicheranfrage nötig ist, wird der intern reservierte Speicher zuerst wiederverwendet bevor mehr vom System angefordert wird.

OK, es gibt natürlich auch Mechanismen, mit denen ein Prozeß nicht mehr benötigten Speicher dem System zurückgeben kann. In der Regel wird das aber nicht ausgenutzt, so daß ein Prozeß meistens nur wächst.

[mangrove84]

Was ich damit sagen wollte, ist, dass wenn ich ein Tab oeffne und wieder schliesse, dann sollte der benoetigte Speicher eigentlich wieder freigegeben werden. Oder nicht?

Nein, der Speicher, den ein Prozeß einmal vom Kernel angefordert hat, wird nicht mehr dem Kernel zurückgegeben. Der Prozeß kümmert sich allerdings intern darum, den einmal reservierten Speicher zu recyclen. Wenn also erneut eine Speicheranfrage nötig ist, wird der intern reservierte Speicher zuerst wiederverwendet bevor mehr vom System angefordert wird.

OK, es gibt natürlich auch Mechanismen, mit denen ein Prozeß nicht mehr benötigten Speicher dem System zurückgeben kann. In der Regel wird das aber nicht ausgenutzt, so daß ein Prozeß meistens nur wächst.

Heisst das, dass ich tatsaechlich den Firefox regelmaessig komplett beenden muss, damit der Speicher wieder fuer andere Prozesse frei wird?

[retabell]

Ich würde dann doch erstmal abklären, woran es liegt. Dass eine Kiste mit 8GB ins Swappen kommt, ist definitiv nicht normal,

Was sich manchmal doch als schwierig entpuppt, der TE hat auch keine weitere Systemdaten angegeben.

habe diesen Thread mal gelesen nachdem ich mit einem Kanotix(buster) live iso ähnliche Symptome habe, der Speicher "läuft einfach langsam voll.." (nach einigen Stunden ist das System unbedienbar)

ich vermute zur Zeit rtlwifi als Übeltäter.

https://github.com/lwfinger/rtlwifi_new/issues/401

in 4.20 ist mittlerweile der Patch drin

https://git.kernel.org/pub/scm/linux/ke ... f0a6ad73f2

Das Problem existiert wohl seit 4.18

[novalix]

Ich habe vier Instanzen meines Codes laufen (ohne Memory-Leak ), welche jeweils ~800MB RAM belegen.

Und auf stretch belegt Dein Code weniger Arbeitsspeicher?
Nach dem, was ich aus Deinen Angaben hier erlesen kann, scheint mir das Problem weniger im Speichermanagement des Betriebssystems zu liegen, als in der Software, die Du relativ unspezifisch als Deinen "Code" bezeichnest. 800MB pro Instanz ist ja keine Kleinigkeit. Was macht denn Dein Code, Moleküle falten, Deep Learning?

[mangrove84]

Was sich manchmal doch als schwierig entpuppt, der TE hat auch keine weitere Systemdaten angegeben.

Was fuer Daten haettest du denn gern?

[mangrove84]

Ich habe vier Instanzen meines Codes laufen (ohne Memory-Leak ), welche jeweils ~800MB RAM belegen.

Und auf stretch belegt Dein Code weniger Arbeitsspeicher?
Nach dem, was ich aus Deinen Angaben hier erlesen kann, scheint mir das Problem weniger im Speichermanagement des Betriebssystems zu liegen, als in der Software, die Du relativ unspezifisch als Deinen "Code" bezeichnest. 800MB pro Instanz ist ja keine Kleinigkeit. Was macht denn Dein Code, Moleküle falten, Deep Learning?

Mein Code fuehrt physikalische Simulationen aus, genauer: Zeitentwicklungen von partiellen Differentialgleichungen. Der Code ist 100% selbst geschrieben, deshalb bezeichne ich ihn unspezifisch als meinen Code.


Ueber Weihnachten/Neujahr war ich in Urlaub, deshalb erstmal keine Probleme mit dem Speicher. Nun bin ich seit zwei Tagen wieder auf Arbeit. Den Rechner habe ich gestern neu gestartet und heute habe ich schon wieder bloss 100MB freien RAM Mein Code laeuft noch nicht. Nichts laeuft, ausser X, Firefox und Thunderbird. Vielleicht muss ich mich von Firefox verabschieden, da scheinen einige Tabs sehr speicherhungrig zu sein...

[bluestar]

Ueber Weihnachten/Neujahr war ich in Urlaub, deshalb erstmal keine Probleme mit dem Speicher. Nun bin ich seit zwei Tagen wieder auf Arbeit. Den Rechner habe ich gestern neu gestartet und heute habe ich schon wieder bloss 100MB freien RAM

Vielleicht wäre es jetzt mal an der Zeit die Ausgabe von ps faux zu posten, wir wissen doch alle nicht, was auf deinem Rechner so im Hintergrund läuft... Ich denke da gerade an so Späße wie Datenbanken oder Web-Server oder ähnliches.