RAM libre desaparece - ¿Pérdida de memoria?

En un sistema recién iniciado, freeinforma acerca de 1.5G de RAM utilizada (8G de RAM en total, Ubuntu 12.04 con lightdm y escritorio de plasma, se inició una ventana de konsole). Tener las aplicaciones en ejecución que uso, todavía consume no más de 2G. Sin embargo, al tener el sistema funcionando durante un par de días, desaparece cada vez más de mi RAM libre, sin aparecer en la lista de aplicaciones usadas: mientras que los smem --pie=nameinformes usan menos del 20% (y el 80% está disponible), todo lo demás dice diferentemente. free -mpor ejemplo informes sobre el día 7:

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

(para que pueda ver, no son los búferes o el caché). Hoy, esto finalmente terminó con el sistema bloqueado por completo: el administrador de Windows desapareció, las aplicaciones "colgando en el aire" (sin marco) - y una ventana emergente que me notifica sobre "demasiados archivos abiertos". Syslog informa:

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

Así que cerré esas aplicaciones que pude cerrar, y maté a X usando Ctrl-Alt-retroceso. X intentó volver a aparecer después de eso con failsafeX, pero no pudo hacerlo ya que ya no podía detectar su configuración. Así que cambié a una consola usando Ctrl-Alt-F2, capturé toda la información que pude pensar (vmstat, free, smem,, proc/meminfolsof, ps aux), y finalmente reinicié. A X se le ocurrió nuevamente failsafeX; esta vez le dije que "se recuperara de mi configuración respaldada", luego cambié a una consola y usé startxcon éxito para abrir el entorno gráfico.

No tengo ni idea de qué está causando este problema, aunque debe tener que ver con X en sí o con algunos procesos de usuario que se ejecutan en X, ya que después de matar a X, la free -msalida se veía así:

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

(~ 3.5GB liberados) - para comparar con la salida después de un nuevo comienzo:

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

Dos resultados más útiles son proporcionados por memstat -u. Poco antes del accidente:

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

Después de matar a 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

Y después de reiniciar, de vuelta en 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

Editar: Acabo de agregar dos gráficos de mi sistema de monitoreo. Interesante de ver: cada vez que hay un "salto" en el consumo de memoria, la CPU también tiene picos. Acabo de encontrar esto en este momento, y me recuerda a otro indicador que apunta a la propia X: a menudo, cuando regresaba a mi máquina y desbloqueaba la pantalla, encontraba algo que hacía un trabajo pesado en mi CPU. Comprobando top, siempre resultó ser /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch -background none.

Entonces, después de esta larga explicación, finalmente mis preguntas:

1. ¿Cuáles podrían ser las posibles causas?
2. ¿Cómo puedo identificar mejor los procesos / aplicaciones involucrados?
3. ¿Qué pasos se pueden tomar para evitar este comportamiento, salvo reiniciar la máquina todos los X días?

Estuve ejecutando 8.04 (Hardy) durante aproximadamente 5 años en mi máquina anterior, nunca había experimentado algo así (siempre más de 100 días de tiempo de actividad, antes de reiniciar, por ejemplo, las actualizaciones del kernel). Esta es ahora una máquina completamente nueva con una nueva instalación de 12.04 . En caso de que sea importante, algunas especificaciones:

APU AMD A4-3400 con gráficos HD Radeon (tm), utilizando el controlador ati / radeon de código abierto (por lo que no se instaló fglrx), 8GB RAM, WDC WD1002FAEX-0 hdd (1TB), placa base Asus F1A75-V Evo. Ubuntu 12.04 de 64 bits con KDE4 / Plasma. Las aplicaciones que generalmente se abren de manera más o menos permanente incluyen Evolution, Firefox, konsole (con Midnight Commander ejecutándose en el interior, aproximadamente 4 pestañas) y LibreOffice, además de ocasionalmente Calibre, Gimp y Moneyplex (software bancario que ya uso desde hace casi 20 años, en una versión que funcionó bien en Hardy).

Editar: Hoy encontré uno de los "chicos malvados": el escritorio de plasma KDE4s. La memoria usada fue nuevamente de hasta 5 GB, cuando hice una killall plasma-desktop && plasma-desktop. ¡Esto liberó 1.3GB de RAM! psdice:

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

Entonces, ¿dónde han estado esos 1.3GB? La diferencia entre esos valores, si se suman, asciende a 96 MB, no a 1.3 GB.

Y esto solo puede ser una parte, ya que todavía se usan 3,7 GB (debe ser inferior a 2 GB). Supervisé esto durante los últimos 6 días usando varias herramientas: la memoria usada (sin hablar de caché y búferes) aumenta de manera lenta pero constante. Incluso si no estoy en mi escritorio para ejecutar nada ...

En cuanto a los procesos de monitoreo con archivos abiertos, actualmente uso el siguiente 1-liner (me encanta shell y especialmente bash) para obtener el top 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

Comando aquí en 4 líneas para una mejor legibilidad. No hay mucho aún desde allí, excepto que a Skype no le gusta que se rompa la conexión a Internet. Cada desconexión provoca un ligero aumento de sus archivos abiertos, pero nada dramático. Por otro lado, parece que el plasma también es responsable de eso:

¿Ves la caída de los identificadores de archivo al final? Ese fue el reinicio del plasma.

1. La gran cantidad de archivos abiertos es una buena pista de que algo va mal. Supongo que sería un demonio del sistema KDE.

2. Abra una consola y ejecute "arriba". Luego use <y> para cambiar la columna de clasificación a VIRT o RES y ver qué programas están usando la mayor cantidad de memoria. Una pérdida de memoria se mostrará como un uso de memoria virtual masivamente inflado, ya que una vez que se pierde el puntero a la memoria perdida, no se usará y se cambiará. También ejecute "lsof" y busque un proceso con muchos archivos abiertos, ya que esto parece ser realmente una fuga del descriptor de archivo.

3. Rastree el programa e informe un error.

Creo que ese es el comportamiento normal del sistema. Lo más probable es que todo esté bien.

Puede leer este brillante documento (Linux se comió mi ram) para comprender cómo Linux está administrando su ram y por qué no hay que preocuparse:

http://www.linuxatemyram.com/