Algo come toda a memória no meu servidor, mas não é cache fs

Question

Eu recebi várias vezes notificações do meu sistema de monitoramento sobre 98% de memória. Eu corri top e contei apenas cerca de 60% de memória usada se eu somava memória coluna. Após várias horas, o uso de memória voltou ao normal (~ 70%). Eu suspeitei de cache fs, mas free -m não prova isso.

Alguma ideia? 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         

    

Answer 1

buffers é o cache do FS.

Buffers are associated with a specific block device, and cover caching of filesystem metadata as well as tracking in-flight pages. The cache only contains parked file data. That is, the buffers remember what's in directories, what file permissions are, and keep track of what memory is being written from or read to for a particular block device. The cache only contains the contents of the files themselves.

link

Top também mostra 13% do IOWAIT no instantâneo que você nos deu. Para mim, isso parece um banco de dados OLTP que não está recebendo quase o suficiente do IOPS do disco necessário. Atualize seu subsistema de armazenamento.

    

Answer 2

OK, primeiro volte e certifique-se de que sua saída principal seja classificada por uso da memória ( RES ident size) e, se não for, prossiga e atualize sua pergunta com a saída this . Então você realmente será capaz de ver o que está mastigando sua memória RAM.

Em segundo lugar, esqueça a coluna %MEM . Esse bolo particular é uma mentira (devido ao arredondamento).
Concentre-se no tamanho RES ident dos programas (e se você estiver preocupado com a permuta, o tamanho VIRT ual) em vez disso - some aqueles colunas e os números irão corresponder ao que você está vendo em free & top output.

De olhar para a sua saída você tem um processo MySQL gigante (2.6G), e um processo Java gigante (2.0G) - eu suspeito que esses dois são seus co-conspiradores em mastigar toda a sua memória RAM O processo Java está pedindo que o MySQL faça está gerando grandes 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, ineficientemente).

Eu apostaria que seu sistema provavelmente navega usando 4-5G de RAM em um "dia normal", e quando esses dois processos se juntam eles mastigam o resto (e então alguns) e você acaba em um Lugar Ruim

Descubra o que eles estão fazendo, corrija e seu problema desaparecerá.