Varias veces recibí notificaciones de mi sistema de monitoreo sobre el 98% de la memoria. Ejecuté topy conté sólo alrededor del 60% de la memoria utilizada si sumomemoriacolumna. Después de varias horas, el uso de la memoria volvió a la normalidad (~70%). Sospeché de fs cache, pero free -mno lo pruebo.
¿Algunas ideas? Servidor: x86-64, ubuntu 12.04, 8Gb de RAM
# free -m
total used free shared buffers cached
Mem: 7958 7835 123 0 8 39
-/+ buffers/cache: 7787 171
Swap: 975 975 0
#top
top - 10:11:48 up 179 days, 14:25, 1 user, load average: 1.99, 1.81, 1.59
Tasks: 143 total, 1 running, 142 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.8%us, 0.6%sy, 0.0%ni, 82.8%id, 13.6%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 8149424k total, 8017556k used, 131868k free, 6708k buffers
Swap: 999420k total, 999372k used, 48k free, 37952k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30562 mysql 20 0 6033m 2.6g 3160 S 14 32.9 74:37.56 mysqld
10898 www-data 20 0 25.3g 2.0g 1560 S 16 25.6 19:44.10 java
9570 rabbitmq 20 0 2611m 166m 1540 S 6 2.1 628:08.96 beam.smp
13166 redis 20 0 94276 72m 584 S 0 0.9 23:24.47 redis-server
3798 root 20 0 348m 29m 988 S 0 0.4 167:36.37 cimprovagt
7614 root 20 0 51468 28m 1256 S 0 0.4 0:02.59 bash
3677 root 20 0 4706m 26m 0 S 0 0.3 110:47.59 java
3458 bind 20 0 668m 5328 1488 S 0 0.1 0:23.38 named
7595 root 20 0 85380 2956 880 S 0 0.0 0:00.25 sshd
2061 root 10 -10 4996 2948 2104 S 0 0.0 13:39.72 iscsid
632 syslog 20 0 244m 2404 360 S 0 0.0 7:12.39 rsyslogd
5855 newrelic 20 0 107m 1852 1248 S 0 0.0 128:23.28 nrsysmond
1 root 20 0 24340 1516 736 S 0 0.0 0:29.96 init
2741 root 20 0 17340 1308 944 R 0 0.0 0:00.04 top
4214 root 20 0 45336 1264 1020 S 0 0.0 6:12.72 cdm
4235 root 20 0 12428 1108 908 S 0 0.0 10:55.38 processes
4178 root 20 0 19124 1064 856 S 0 0.0 7:20.07 controller
5853 ntp 20 0 37772 1036 872 S 0 0.0 7:40.35 ntpd
4179 root 20 0 86044 1024 848 S 0 0.0 9:55.54 spooler
4008 root 20 0 4090m 980 756 S 0 0.0 0:08.70 console-kit-dae
3790 root 20 0 422m 952 668 S 0 0.0 89:21.80 cimprovagt
3629 root 20 0 50032 868 752 S 0 0.0 1:17.44 sshd
4075 root 20 0 182m 844 408 S 0 0.0 0:02.90 polkitd
27661 root 20 0 101m 776 772 S 0 0.0 0:00.02 mysql
18465 root 20 0 101m 732 732 S 0 0.0 0:00.04 mysql
3436 root 20 0 19112 716 636 S 0 0.0 0:11.25 cron
3783 root 20 0 1009m 716 432 S 0 0.0 0:04.83 cimserver
26239 root 20 0 22092 700 696 S 0 0.0 0:00.03 bash
4181 root 20 0 13196 696 596 S 0 0.0 4:18.57 hdb
3406 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3410 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3428 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3429 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3432 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
3972 root 20 0 14744 664 660 S 0 0.0 0:00.00 getty
18452 root 20 0 22076 620 620 S 0 0.0 0:00.00 bash
361 root 20 0 22104 568 568 S 0 0.0 0:00.04 udevd
3441 root 20 0 15980 560 464 S 0 0.0 26:28.16 irqbalance
654 messageb 20 0 23948 516 324 S 0 0.0 0:01.98 dbus-daemon
676 root 20 0 21188 504 504 S 0 0.0 0:00.00 bluetoothd
3665 root 20 0 4400 492 488 S 0 0.0 0:00.00 sh
5546 rabbitmq 20 0 7672 488 308 S 0 0.0 1:04.49 epmd
26238 root 20 0 26092 476 476 S 0 0.0 0:00.24 screen
2060 root 20 0 4504 440 400 S 0 0.0 3:18.60 iscsid
Respuesta1
amortiguadoresesla caché de FS.
Los buffers están asociados con un dispositivo de bloque específico y cubren el almacenamiento en caché de metadatos del sistema de archivos, así como el seguimiento de páginas en tránsito. La caché solo contiene datos de archivos estacionados. Es decir, los buffers recuerdan lo que hay en los directorios, cuáles son los permisos de los archivos y realizan un seguimiento de en qué memoria se escribe o se lee para un dispositivo de bloque en particular. El caché solo contiene el contenido de los archivos.
https://stackoverflow.com/a/12547130/636573
Arriba también muestra el 13% de IOWAIT en la instantánea que nos diste. Para mí, esto parece una base de datos OLTP que no obtiene suficientes IOPS de disco que necesita. Actualice su subsistema de almacenamiento.
Respuesta2
Bien, primero regrese y asegúrese de que su salida principal esté ordenada por uso de memoria ( REStamaño de identificación), y si no es así, continúe y actualice su pregunta conesoproducción. Entonces podrás ver qué está consumiendo tu RAM.
En segundo lugar, olvídate de la %MEMcolumna. Ese pastel en particular es mentira (debido al redondeo). En su lugar
, concéntrese en el REStamaño de identificación de los programas (y si le preocupa cambiar a, el VIRTtamaño real): sumaaquellosLas columnas y los números coincidirán con lo que estás viendo en free& topsalida.
Al observar su resultado principal, tiene un proceso MySQL gigante (2.6G) y un proceso Java gigante (2.0G). Sospecho que estos dos son sus co-conspiradores para consumir toda su RAM (cualquiera que sea ese proceso Java en particular). pedirle a MySQL que haga es generar enormes conjuntos de resultados o datos intermedios).
El proceso Java también tiene un tamaño virtual de 25G (!!): claramente está perdiendo memoria internamente que el recolector de basura no está liberando (o tal vez está lidiando con un enorme conjunto de resultados, de manera ineficiente).
Apostaría a que su sistema probablemente funcione usando 4-5G de RAM en un "día normal", y cuando estos dos procesos se juntan, devoran el resto (y algo más) y termina en un mal lugar.
Descubra lo que están haciendo, solucionelo y su problema desaparecerá.