Recebi diversas vezes notificações do meu sistema de monitoramento sobre 98% de memória. Corri tope contei apenas cerca de 60% da memória usada se somarmemóriacoluna. Após várias horas, o uso da memória voltou ao normal (~70%). Suspeitei do cache do fs, mas free -mnão prova isso.
Alguma ideia? Servidor: x86-64, Ubuntu 12.04, 8 GB 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
Responder1
bufferséo cache do FS.
Os buffers são associados a um dispositivo de bloco específico e cobrem o cache de metadados do sistema de arquivos, bem como o rastreamento de páginas em trânsito. O cache contém apenas dados de arquivos estacionados. Ou seja, os buffers lembram o que está nos diretórios, quais são as permissões de arquivo e controlam de qual memória está sendo gravada ou lida para um determinado dispositivo de bloco. O cache contém apenas o conteúdo dos próprios arquivos.
https://stackoverflow.com/a/12547130/636573
Top também mostra 13% de IOWAIT no instantâneo que você nos forneceu. Para mim, isso parece um banco de dados OLTP que não está obtendo o suficiente do IOPS de disco necessário. Atualize seu subsistema de armazenamento.
Responder2
OK, primeiro volte e certifique-se de que sua saída principal esteja classificada por uso de memória ( REStamanho de identificação) e, se não estiver, vá em frente e atualize sua pergunta comquesaída. Então você poderá ver o que está consumindo sua RAM.
Em segundo lugar, esqueça a %MEMcoluna. Esse bolo em particular é mentira (devido ao arredondamento).
Concentre-se no REStamanho de identificação dos programas (e se você estiver preocupado em trocar para o VIRTtamanho atual) - somaaquelescolunas e os números corresponderão ao que você está vendo na freesaída top.
Olhando para sua saída principal, você tem um processo MySQL gigante (2,6 G) e um processo Java gigante (2,0 G) - suspeito que esses dois sejam seus co-conspiradores em consumir toda a sua RAM (seja qual for esse processo Java específico). pedir ao MySQL é gerar enormes conjuntos de resultados ou dados intermediários).
O processo Java também tem um tamanho virtual de 25G (!!) - claramente está vazando memória internamente que o coletor de lixo não está liberando (ou talvez esteja lidando com um enorme conjunto de resultados, de forma ineficiente).
Eu aposto que seu sistema provavelmente navega usando 4-5G de RAM em um "dia normal" e, quando esses dois processos se juntam, eles destroem o resto (e mais um pouco) e você acaba em um lugar ruim.
Descubra o que eles estão fazendo, corrija e seu problema desaparecerá.