Freier RAM verschwindet - Speicherverlust?

Auf einem neu gestarteten System werden freeetwa 1,5 G RAM verwendet (insgesamt 8 G RAM, Ubuntu 12.04 mit LightDM und Plasma-Desktop, ein Konsolenfenster gestartet). Wenn die von mir verwendeten Apps ausgeführt werden, verbraucht es immer noch nicht mehr als 2G. Wenn das System jedoch einige Tage läuft, verschwindet immer mehr mein freier Arbeitsspeicher - ohne in der Liste der verwendeten Apps zu erscheinen: Während smem --pie=nameweniger als 20% verwendet werden (und 80% verfügbar sind), sagt alles andere anders. free -mZum Beispiel Berichte über Tag 7:

             total       used       free     shared    buffers     cached
Mem:          7459       7013        446          0        178        997
-/+ buffers/cache:       5836       1623
Swap:         9536        296       9240

(Sie sehen also, es sind nicht die Puffer oder der Cache). Heute endete dies schließlich mit einem vollständigen Absturz des Systems: Der Windows-Manager war weg, Apps "hingen in der Luft" (rahmenlos) - und ein Popup, das mich über "zu viele offene Dateien" informierte. Syslog-Berichte:

kernel: [856738.020829] VFS: file-max limit 752838 reached

Also habe ich die Anwendungen geschlossen, die ich schließen konnte, und X mit Strg-Alt-Rücktaste beendet. X versuchte danach erneut, mit failafeX aufzurufen, konnte dies jedoch nicht, da es seine Konfiguration nicht mehr erkennen konnte. Also wechselte ich mit Strg-Alt-F2 zu einer Konsole, erfasste alle Informationen, die mir einfielen (vmstat, free, smem proc/meminfo, lsof, ps aux) und startete schließlich neu. X hat sich erneut FailsafeX ausgedacht. Dieses Mal sagte ich ihm, er solle "von meiner gesicherten Konfiguration wiederherstellen", wechselte dann zu einer Konsole und verwendete sie erfolgreich startx, um die grafische Umgebung aufzurufen.

Ich habe keine wirkliche Ahnung, was dieses Problem verursacht - obwohl es entweder mit X selbst oder mit einigen auf X ausgeführten Benutzerprozessen zu tun haben muss -, da die free -mAusgabe nach dem Beenden von X folgendermaßen aussah:

             total       used       free     shared    buffers     cached
Mem:          7459       2677       4781          0         62        419
-/+ buffers/cache:       2195       5263
Swap:         9536         59       9477

(~ 3,5 GB werden freigegeben) - zum Vergleich mit der Ausgabe nach einem Neustart:

             total       used       free     shared    buffers     cached
Mem:          7459       1483       5975          0         63        730
-/+ buffers/cache:        689       6769
Swap:         9536          0       9536

Zwei weitere hilfreiche Ausgaben werden von bereitgestellt memstat -u. Kurz vor dem Absturz:

User     Count     Swap      USS      PSS      RSS
mail         1        0      200      207      616
whoopsie     1      764      740      817     2300
colord       1     3200      836      894     2156
root        62    70404   352996   382260   569920
izzy        80   177508  1465416  1519266  1851840

Nachdem X getötet wurde:

User     Count     Swap      USS      PSS      RSS
mail         1        0      184      188      356
izzy         1     1400      708      739     1080
whoopsie     1      848      668      826     1772
colord       1     3204      804      888     1728
root        62    54876   131708   149950   267860

Und nach einem Neustart wieder in X:

User     Count     Swap      USS      PSS      RSS
mail         1        0      212      217      628
whoopsie     1        0     1536     1880     5096
colord       1        0     3740     4217     7936
root        54        0   148668   180911   345132
izzy        47        0   370928   437562   915056

Bearbeiten: Ich habe gerade zwei Diagramme aus meinem Überwachungssystem hinzugefügt. Interessant zu sehen: Jedes Mal, wenn der Speicherverbrauch "springt", erreicht die CPU ebenfalls Spitzenwerte. Ich habe das gerade gefunden - und es erinnert mich an einen anderen Indikator, der auf X selbst zeigt: Wenn ich zu meinem Computer zurückkehrte und den Bildschirm entsperrte, fand ich oft etwas, das schwere Arbeit an meiner CPU leistete. Bei der Überprüfung topstellte sich heraus, dass es immer so war /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch -background none.

Also nach dieser langen Erklärung endlich meine Fragen:

1. Was könnten die möglichen Ursachen sein?
2. Wie kann ich beteiligte Prozesse / Anwendungen besser identifizieren?
3. Welche Schritte könnten unternommen werden, um dieses Verhalten zu vermeiden - kurz nach dem Neustart des Computers alle X Tage?

Ich habe 8.04 (Hardy) ungefähr 5 Jahre lang auf meinem alten Computer ausgeführt, ohne etwas Ähnliches erlebt zu haben (immer mehr als 100 Tage Betriebszeit, bevor ich neu gestartet habe, um beispielsweise Kernel-Updates durchzuführen). Dies ist jetzt eine komplett neue Maschine mit einer Neuinstallation vom 12.04 . Falls es darauf ankommt, einige Spezifikationen:

AMD A4-3400 APU mit Radeon (tm) HD-Grafik, unter Verwendung des Open-Source-Treibers ati / radeon (also kein fglrx installiert), 8 GB RAM, WDC WD1002FAEX-0-Festplatte (1 TB), Asus F1A75-V Evo-Mainboard. Ubuntu 12.04 64-Bit mit KDE4 / Plasma. Zu den Apps, die normalerweise mehr oder weniger permanent geöffnet sind, gehören Evolution, Firefox, Konsole (mit Midnight Commander im Inneren, ca. 4 Registerkarten) und LibreOffice - sowie gelegentlich Calibre, Gimp und Moneyplex (Bankensoftware, die ich bereits seit fast 20 Jahren verwende). in einer Version, die auf Hardy gut lief).

Edit: Heute habe ich einen der "Bösen" gefunden: KDE4s Plasma-Desktop. Der verwendete Speicher war wieder bis zu 5 GB groß, als ich a killall plasma-desktop && plasma-desktop. Dadurch wurden 1,3 GB RAM frei! pssagt:

                             RSS    SIZE   VSZ
plasma usage before restart  120988 526472 1300816
plasma usage after restart   92352  495972 1263632

Wo waren diese 1,3 GB? Der Unterschied zwischen diesen Werten beträgt, wenn er addiert wird, 96 MB - nicht 1,3 GB.

Und dies kann nur ein Teil sein, da immer noch 3,7 GB verwendet werden (sollte weniger als 2 GB betragen). Ich habe dies in den letzten 6 Tagen mit verschiedenen Tools überwacht: Der verwendete Speicher (ohne über Cache und Puffer zu sprechen) nimmt langsam aber stetig zu. Auch wenn ich nicht an meinem Schreibtisch bin, um irgendetwas zu erledigen ...

Für die Überwachung von Prozessen mit geöffneten Dateien verwende ich derzeit den folgenden 1-Liner (ich liebe Shell und insbesondere Bash), um die Top-5 zu erhalten:

echo "$(for pid in $(ls -a /proc|egrep '^([0-9])*$'|sort -n 2>/dev/null); do \
if [ -e /proc/$pid/fd ]; then FHC=$(ls -l /proc/$pid/fd|wc -l); \
if [ $FHC -gt 0 ]; then PNAME="$(cat /proc/$pid/comm)"; \
echo "$FHC files opened by $pid ($PNAME)"; fi; fi; done)"|sort -r -n|head -n5

Befehl hier in 4 Zeilen zur besseren Lesbarkeit. Von dort noch nicht viel - außer dass Skype die Internetverbindung nicht gerne unterbrochen hat. Jede Trennung bewirkt eine leichte Zunahme der geöffneten Dateien, aber nichts Dramatisches. Andererseits scheint auch Plasma dafür verantwortlich zu sein:

Sehen Sie den Drop von Dateihandles am Ende? Das war der Plasma-Neustart.

1. Die große Anzahl geöffneter Dateien ist ein guter Hinweis darauf, dass etwas schief geht. Meine Vermutung wäre ein KDE-Systemdämon.

2. Öffnen Sie eine Konsole und führen Sie "top" aus. Verwenden Sie dann <und>, um die Sortierspalte in VIRT oder RES zu ändern und festzustellen, welche Programme den meisten Speicher belegen. Ein Speicherverlust wird als massiv aufgeblasene virtuelle Speichernutzung angezeigt, da der Zeiger auf den verlorenen Speicher nicht mehr verwendet wird und ausgetauscht wird, sobald er verloren geht. Führen Sie auch "lsof" aus und suchen Sie nach einem Prozess mit vielen geöffneten Dateien, da dies wirklich ein Dateideskriptorleck zu sein scheint.

3. Verfolgen Sie das Programm und melden Sie einen Fehler.

Ich denke, das ist ein normales Systemverhalten. Höchstwahrscheinlich ist alles in Ordnung.

Sie können dieses brillante Papier lesen (Linux hat meinen RAM gegessen), um zu verstehen, wie Linux Ihren RAM verwaltet und warum Sie sich keine Sorgen machen müssen:

http://www.linuxatemyram.com/