RAM libre desaparece - ¿Pérdida de memoria?


11

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

Uso del sistema de archivos durante una semana Uso de kernel / CPU por una semana

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:

Uso de VFS (2 días)

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


¿ sudo bash -c 'sync; echo 3 > /proc/sys/vm/drop_caches'Despeja el carnero extra? Puede ver archivos abiertos de programas usandolsof
Savvas Radevic

Además, ¿has intentado cambiar de administrador de escritorio? por ejemplo, lxde (o lubuntu-desktop)? Finalmente, ¿estás seguro de que la salida al disco está bien? ¿Ha verificado los datos SMART del disco y la velocidad de copia de archivos desde / hacia el disco usando un CD en vivo?
Savvas Radevic 01 de

Verifique esto para comprobar si tiene una fuga Cómo detectar una fuga de memoria
Mitch

@medigeek: Como señalé, el problema no son los cachés y las memorias intermedias. Ver la salida de free. Cambiando a un DE diferente, de hecho lo he considerado; si KDE3.5 hubiera estado disponible, no hubiera terminado con Plasma. Esto solo podría ser temporal para ver si Plasma está involucrado.
Izzy

@Mitch: entendí que memprof debía usarse contra un proceso conocido (que aún no he aislado). ¿Seguro que se puede usar en todo el sistema? Además, como sugiere el error "demasiados archivos abiertos", para mí parece que algún proceso está abriendo muchos identificadores de archivos, sin liberarlos nunca. No estoy seguro si eso sería atrapado por memprof. Ahora configuré una secuencia de comandos para capturar los 5 mejores procesos mediante archivos abiertos; espero que esto resulte el malvado.
Izzy

Respuestas:


6
  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.


Ya intenté utilizar top / htop para esto. El problema es que no mostró resultados en cuanto a la memoria RESID (como se describió anteriormente, solo una pequeña parte de la memoria utilizada podría conectarse a las aplicaciones en ejecución). Y en cuanto a la memoria VIRTual, es difícil de interpretar (incluso justo después del inicio, la memoria virtual usó sumas de hasta 3 TB aquí, un tamaño que incluso mi disco duro no podía manejar). Entonces, por ejemplo, Evolution utiliza 1.9GB VIRT, según la parte superior, mientras que la memoria total en uso suma hasta 1.2GB (excluyendo caché y buffers). Y sí, mi primera intención es rastrear el programa, para poder presentar un error ...
Izzy

Acabo de agregar 2 imgs de mi sistema de monitoreo. Parece que los "saltos" siempre ocurrieron a la misma hora del día (sin embargo, 1 excepción). Desafortunadamente, los imgs no dan marca de tiempo para verificar con cron. Por cierto: ¿hay alguna forma de monitorear qué proceso tiene cuántos archivos abiertos?
Izzy

1
Tu suposición fue buena. Aunque no era un demonio, principalmente era un componente de KDE: plasma-escritorio (ver arriba). Algo curioso: acabo de darme cuenta y lo publiqué aquí, y 10 minutos más tarde en mi diario apt-get update && apt-get upgradehabía una actualización para el escritorio de plasma; esos tipos son rápidos X) Ahora lo miro por un momento para ver si el problema está resuelto, antes de declararlo. Hasta ahora, las cosas parecen bastante prometedoras.
Izzy

Aún se ve estable. Aunque lsofni topme señaló el "proceso maligno", su suposición sobre el demonio de KDE me señaló en la dirección del alborotador. Así que gracias de nuevo: el tiempo de actividad de mi máquina ahora es de aproximadamente 14 días, y todo sigue pareciendo estable, aunque incluso ejecuté cosas como VirtualBox, compilando, etc. en paralelo. Así que considero que esto está resuelto, y marco el partido más cercano :)
Izzy

0

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/


44
Oh, nunca escuché que es "comportamiento normal del sistema" si el sistema falla después de 7 días con el error "demasiados archivos abiertos". Estoy ejecutando Linux durante unos 15 años, nunca tuve esto. Y sí, entiendo completamente cómo Linux utiliza la "RAM libre" (usándola para el almacenamiento en caché, etc.) Como se señaló anteriormente: la caché y los buffers no son el problema aquí. No estoy hablando de que la RAM se use por buenas razones: Linux nunca se adherirá a los cachés por el precio del intercambio.
Izzy
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.