La RAM libera scompare - Perdita di memoria?

Su un nuovo sistema avviato, i freerapporti circa 1,5 G hanno utilizzato la RAM (8 G RAM complessivamente, Ubuntu 12.04 con desktop lightdm e plasma, una finestra di konsole avviata). Avendo le app in esecuzione che uso, consuma ancora non più di 2G. Tuttavia, avendo il sistema in esecuzione per un paio di giorni, sempre più della mia RAM gratuita scompare - senza comparire nell'elenco delle app utilizzate: mentre i smem --pie=namereport utilizzano meno del 20% (e l'80% è disponibile), tutto il resto dice in modo diverso. free -mad esempio, rapporti circa il giorno 7:

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

(così puoi vedere, non sono i buffer o la cache). Oggi questo si è finalmente concluso con il blocco del sistema: Windows Manager è sparito, le app "sospese in aria" (senza cornice) - e un popup che mi avvisa "troppi file aperti". Rapporti Syslog:

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

Così ho chiuso quelle applicazioni che sono stato in grado di chiudere e ho ucciso X usando Ctrl-Alt-backspace. X ha provato a presentarsi di nuovo con fail-safeX, ma non è stato in grado di farlo poiché non ha più potuto rilevare la sua configurazione. Quindi sono passato a una console usando Ctrl-Alt-F2, ho acquisito tutte le informazioni che mi sono venute in mente (vmstat, free, smem,, proc/meminfolsof, ps aux) e infine sono stato riavviato. X ha di nuovo inventato fail-safeX; questa volta gli ho detto di "ripristinare dalla mia configurazione di backup", quindi sono passato a una console e utilizzato con successo startxper richiamare l'ambiente grafico.

Non ho idea di cosa stia causando questo problema - sebbene debba avere a che fare con X stesso o con alcuni processi utente in esecuzione su X - come dopo aver ucciso X, l' free -moutput sembrava così:

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

(~ 3.5GB liberati) - per confrontare con l'output dopo un nuovo avvio:

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

Altri due utili risultati sono forniti da memstat -u. Poco prima dello schianto:

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

Dopo aver ucciso X:

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

E dopo un riavvio, di nuovo 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

Modifica: ho appena aggiunto due grafici dal mio sistema di monitoraggio. Interessante da vedere: ogni volta che c'è un "salto" nel consumo di memoria, anche i picchi della CPU. Ho appena trovato questo in questo momento - e mi ricorda un altro indicatore che punta alla stessa X: Spesso quando sono tornato alla mia macchina e sbloccato lo schermo, ho trovato qualcosa che faceva un lavoro pesante sulla mia CPU. Verificando top, si è sempre rivelato essere /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch -background none.

Quindi, dopo questa lunga spiegazione, finalmente le mie domande:

1. Quali potrebbero essere le possibili cause?
2. Come posso identificare meglio i processi / applicazioni coinvolti?
3. Quali passi potrebbero essere presi per evitare questo comportamento - a parte il riavvio della macchina per tutti i giorni X?

Ho eseguito 8.04 (Hardy) per circa 5 anni sulla mia vecchia macchina, non avendo mai sperimentato simili (sempre più di 100 giorni di tempo di attività, prima di riavviare ad esempio gli aggiornamenti del kernel). Questa ora è una macchina completamente nuova con una nuova installazione di 12.04 . Nel caso in cui sia importante, alcune specifiche:

APU AMD A4-3400 con grafica Radeon (tm) HD, utilizzando il driver ati / radeon open source (quindi non installato fglrx), 8 GB di RAM, WDC WD1002FAEX-0 hdd (1 TB), scheda madre Asus F1A75-V Evo. Ubuntu 12.04 a 64 bit con KDE4 / Plasma. Le app di solito si aprono più o meno permanentemente includono Evolution, Firefox, Konsole (con Midnight Commander in esecuzione all'interno, circa 4 schede) e LibreOffice - oltre a occasionalmente Calibre, Gimp e Moneyplex (software bancario che uso già da quasi 20 anni, in una versione che ha funzionato bene su Hardy).

Modifica: Oggi ho trovato uno dei "cattivi": il desktop al plasma di KDE4s. La memoria usata era di nuovo fino a 5 GB, quando ho fatto un killall plasma-desktop && plasma-desktop. Questo ha liberato 1,3 GB di RAM! psdice:

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

Allora, dove sono stati quei 1.3GB? La differenza tra questi valori, se sommati, ammonta a 96 MB, non a 1,3 GB.

E questa può essere solo una parte, poiché sono ancora in uso 3,7 GB (dovrebbe essere inferiore a 2 GB). L'ho monitorato negli ultimi 6 giorni usando diversi strumenti: la memoria usata (senza parlare di cache e buffer) aumenta lentamente ma costantemente. Anche se non sono alla mia scrivania per eseguire nulla ...

Per quanto riguarda il monitoraggio dei processi con file aperti, attualmente uso il seguente 1-liner (adoro shell e soprattutto bash) per ottenere i primi 5:

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

Comanda qui in 4 righe per una migliore leggibilità. Non c'è ancora molto da lì, tranne per il fatto che a Skype non piace che la connessione Internet sia interrotta. Ogni disconnessione provoca un leggero aumento dei suoi file aperti, ma nulla di drammatico. D'altra parte sembra che anche il plasma sia responsabile di ciò:

Vedi la goccia di handle di file alla fine? Quello fu il riavvio del plasma.

1. L'enorme numero di file aperti è un buon indizio del fatto che qualcosa vada storto. La mia ipotesi sarebbe un demone di sistema di KDE.

2. Apri una console ed esegui "top". Quindi utilizzare <e> per modificare la colonna di ordinamento in VIRT o RES e vedere quali programmi utilizzano più memoria. Una perdita di memoria verrà visualizzata come un utilizzo della memoria virtuale fortemente gonfiato, poiché una volta perso il puntatore alla memoria trapelata non verrà utilizzata e verrà sostituita. Esegui anche "lsof" e cerca un processo con molti file aperti, dato che questo sembra davvero essere una perdita di descrittore di file.

3. Rintraccia il programma e segnala un bug.

Penso che sia il normale comportamento del sistema. Molto probabilmente tutto va bene.

Puoi leggere questo brillante documento (linux ha mangiato il mio ram) per capire come Linux gestisce il tuo ram e perché non c'è motivo di preoccuparsi:

http://www.linuxatemyram.com/