2012-03-09 14:13:35 +0000 2012-03-09 14:13:35 +0000
131

Linux: ¿averiguar qué proceso está usando toda la RAM?

Antes de preguntar, para ser claros: sí, sé sobre el caché de disco, y no, no es mi caso :) Lo siento, por este preámbulo :)

Estoy usando CentOS 5. Todas las aplicaciones del sistema están intercambiando mucho, y el sistema es muy lento. Cuando hago free -m, esto es lo que tengo:

total used free shared buffers cached
Mem: 3952 3929 22 0 1 18
-/+ buffers/cache: 3909 42
Swap: 16383 46 16337

Así que, en realidad sólo tengo 42 Mb para usar! Por lo que entiendo, -/+ buffers/cache no cuenta el caché del disco, así que sólo tengo 42 Mb, ¿verdad? Pensé que podría estar equivocado, así que intenté apagar el caché de disco y no tuvo ningún efecto, la imagen permaneció igual.

Así que decidí averiguar quién está usando toda mi RAM, y usé top para eso. Pero, aparentemente, informa que ningún proceso está usando mi RAM. El único proceso en mi top es MySQL, pero está usando el 0.1% de RAM y 400Mb de swap. La misma imagen cuando trato de ejecutar otros servicios o aplicaciones - todos van en swap, top muestra que el MEM no se usa (0.1% máximo para cualquier proceso).

top - 15:09:00 up 2:09, 2 users, load average: 0.02, 0.16, 0.11
Tasks: 112 total, 1 running, 111 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4046868k total, 4001368k used, 45500k free, 748k buffers
Swap: 16777208k total, 68840k used, 16708368k free, 16632k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND
 3214 ntp 15 0 23412 5044 3916 S 0.0 0.1 0:00.00 17m ntpd
 2319 root 5 -10 12648 4460 3184 S 0.0 0.1 0:00.00 8188 iscsid
 2168 root RT 0 22120 3692 2848 S 0.0 0.1 0:00.00 17m multipathd
 5113 mysql 18 0 474m 2356 856 S 0.0 0.1 0:00.11 472m mysqld
 4106 root 34 19 251m 1944 1360 S 0.0 0.0 0:00.11 249m yum-updatesd
 4109 root 15 0 90152 1904 1772 S 0.0 0.0 0:00.18 86m sshd
 5175 root 15 0 90156 1896 1772 S 0.0 0.0 0:00.02 86m sshd

El reinicio no ayuda, y, por cierto es muy lento, lo que normalmente no esperaría en esta máquina (4 núcleos, 4Gb de RAM, RAID1).

Así que, con eso - estoy bastante seguro de que esto no es un caché de disco, que está usando la RAM, porque normalmente debería haberse reducido y dejar que otros procesos usen la RAM, en lugar de ir a swap.

Así que, finalmente, la pregunta es - si alguien tiene alguna idea de cómo averiguar qué proceso está usando realmente la memoria tan intensamente?

Respuestas [9]

115
2012-03-09 14:25:01 +0000

En Linux, en el proceso top puedes pulsar la tecla < para desplazar la pantalla de salida hacia la izquierda. Por defecto se ordena por el %CPU, así que si presionas la tecla 4 veces lo ordenarás por VIRT que es el tamaño de la memoria virtual que te da la respuesta.

Otra forma de hacerlo es:

ps -e -o pid,vsz,comm= | sort -n -k 2

debería darte y la salida ordenada por el tamaño virtual de los procesos.

Aquí está la versión larga:

ps --everyone --format=pid,vsz,comm= | sort --numeric-sort --key=2
115
78
2016-02-09 21:12:26 +0000

Mostrar la memoria de procesos en megabytes y la ruta de proceso.

ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n
78
14
2012-10-15 15:05:01 +0000

Sólo una nota al margen en un servidor que muestra los mismos síntomas pero que sigue mostrando el agotamiento de la memoria. Lo que terminó encontrando fue un sysctl.conf de una caja con 32 GB de RAM y la configuración de una DB con enormes páginas configuradas a 12000. Esta caja sólo tiene 2 GB de RAM, así que asignaba toda la RAM libre a las páginas enormes (sólo 960 de ellas). Configurar las páginas enormes a 10, ya que ninguna fue usada de todas formas, liberó toda la memoria.

Una rápida comprobación de /proc/meminfo para buscar la configuración de HugePages_ puede ser un buen comienzo para solucionar al menos un inesperado acaparamiento de memoria.

14
5
2018-03-31 03:38:27 +0000

En mi caso, el problema era que el servidor era un servidor virtual VMware con el módulo vmw_balloon habilitado:

$ lsmod | grep vmw_balloon
vmw_balloon 20480 0
vmw_vmci 65536 2 vmw_vsock_vmci_transport,vmw_balloon

Corriendo:

$ vmware-toolbox-cmd stat balloon
5189 MB

Así que alrededor de 5 GB de memoria fue de hecho reclamada por el host. Así que a pesar de tener 8 GB a mi VM "oficialmente", en la práctica era mucho menos:

$ free
              total used free shared buff/cache available
Mem: 8174716 5609592 53200 27480 2511924 2458432
Swap: 8386556 6740 8379816
5
2
2013-07-08 06:05:54 +0000

También puedes usar el comando ps para obtener más información sobre el proceso.

ps aux | less
2
2
2016-10-21 10:51:37 +0000

Hago referencia a esto y ¿Memoria total usada por el proceso Python? - Stack Overflow , esa es mi respuesta. Obtengo una herramienta específica de conteo de procesos (python), ahora.

# Megabyte.
$ ps aux | grep python | awk '{sum=sum+$6}; END {print sum/1024 " MB"}'
87.9492 MB

# Byte.
$ ps aux | grep python | awk '{sum=sum+$6}; END {print sum " KB"}'
90064 KB

Adjunta mi lista de procesos.

$ ps aux | grep python
root 943 0.0 0.1 53252 9524 ? Ss Aug19 52:01 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
root 950 0.6 0.4 299680 34220 ? Sl Aug19 568:52 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
root 3803 0.2 0.4 315692 36576 ? S 12:43 0:54 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
jonny 23325 0.0 0.1 47460 9076 pts/0 S+ 17:40 0:00 python
jonny 24651 0.0 0.0 13076 924 pts/4 S+ 18:06 0:00 grep python

Reference

2
1
2016-03-14 20:50:46 +0000

Haz un guión llamado show-memory-usage.sh con el contenido:

#!/bin/sh
ps -eo rss,pid,user,command | sort -rn | head -10 | awk '{ hr[1024**2]="GB"; hr[1024]="MB";
 for (x=1024**3; x>=1024; x/=1024) {
 if ($1>=x) { printf ("%-6.2f %s ", $1/x, hr[x]); break }
 } } { printf ("%-6s %-10s ", $2, $3) }
 { for ( x=4 ; x<=NF ; x++ ) { printf ("%s ",$x) } print ("\n") }
 '
1
0
2019-07-12 19:46:37 +0000

Mi servidor ubuntu DISTRIBUCIÓN = 18.04 en Hyper-V tenía la mayor parte de la memoria utilizada, pero todos los procesos estaban bien. (Admito que he eliminado los paquetes snapd y unattended-upgr, pero el 95% de la memoria se siguió usando.)

La respuesta es que Hyper-V tiene memoria dinámica, así que tomó memoria para el uso del sistema principal y ubuntu lo marcó como usado.

Espero que ayude a alguien.

0
0
2019-03-31 17:51:48 +0000

Esto también toma el id del proceso, ordena por el MB usado, y delinea el comando (que creó el proceso):

ps aux | awk '{print $6/1024 " MB\t\t" $2 "\t" $11}' | sort -n

0