Crescente uso de memória

1

Deixe-me começar com a foto:

EsteéousodememóriadonossoservidorTomcatdebackup.Eleestáapenaspenduradolá,processandoumsimplespedidodeverificaçãodesaúdeacadacasaleaguardandoafalhadoservidorprincipalparasuportaracarga.Eaindatemesseusocrescentedememória.Oservidorprincipaltemamesmamemóriacrescente.Emaiscedooumaistarde,oNagiosiniciaoenviodeSMSsee-mailssobreamemóriaeousodetroca.

AmbososservidoresestãoexecutandooCentOS7,okernel3.10,oJava1.7eoTomcat7.

MesmoquandoeuparooservidorTomcatusandosystemctlstoptomcat,amemóriacontinuasendousada.

Aúnicamaneiraqueencontreiparaliberaramemóriaésync&&echo3>/proc/sys/vm/drop_caches.Portanto,asoluçãoalternativaécolocarissoemcronjob.Maseugostariadeencontrarumasoluçãoadequada.

Euencontreieste tópico sobre um problema semelhante, e ele menciona a configuração de MALLOC_ARENA_MAX para 4 (e alguns outros tópicos aconselham apenas 1) e também encontrei um encadeamento dizendo que ele deveria funcionar com a variável de ambiente MALLOC_CHECK_ . Mas isso não acontece. Isso é o que você pode ver na parte direita do gráfico.

Se eu olhar o anúncio Memória usada , ele permanecerá em torno de 600 MB e Memória não-heap usada está em 70 MB.

Você tem alguma ideia do que pode estar causando isso e como corrigir isso? E repito, a memória não é liberada depois que o Tomcat é interrompido, então não acredito que seja vazamento em nosso aplicativo.

# free -m
             total       used       free     shared    buffers     cached
Mem:         64268       4960      59307         64          0        135
-/+ buffers/cache:       4824      59443
Swap:         2047          0       2047

# ps -eo rss | awk '{sum += $1}; END {print sum/1024/1024}'
2.54199

Atualize a partir desta manhã, 9 horas após o cronjob liberar a memória:

# free -h
             total       used       free     shared    buffers     cached
Mem:           62G        13G        48G        80M         0B        77M
-/+ buffers/cache:        13G        48G
Swap:         2,0G         4K       2,0G

# ps -eo vsize | awk '{sum += $1}; END {print sum/1024/1024}'
25.8389

# ps -eo rss | awk '{sum += $1}; END {print sum/1024/1024}'
1.24232

# ps -eo pmem,rss,vsize,args | grep tomcat
 1.7  1158608 22684408 java -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start

Isso está ficando muito estranho. Está em execução keepalived , que continua enviando a solicitação HTTP para a função de verificação de integridade do nosso aplicativo via curl a cada alguns segundos. Se eu parar o keepalived , a memória pára de crescer. Se eu enviar a mesma solicitação curl em loop infinito do bash na mesma máquina, a memória começará a crescer novamente. Mesmo se eu enviar a solicitação para URL retornando 404. Se eu iniciar o mesmo loop em uma máquina diferente (portanto, não de localhost), a memória está ok.

# slabtop -o
 Active / Total Objects (% used)    : 244359165 / 244369016 (100,0%)
 Active / Total Slabs (% used)      : 5810996 / 5810996 (100,0%)
 Active / Total Caches (% used)     : 70 / 99 (70,7%)
 Active / Total Size (% used)       : 45770306,72K / 45772288,52K (100,0%)
 Minimum / Average / Maximum Object : 0,01K / 0,19K / 8,00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
243660018 243660018  11%    0,19K 5801429       42  46411432K dentry                 
143872 141868  98%    0,03K   1124      128      4496K kmalloc-32             
118150 118150 100%    0,02K    695      170      2780K fsnotify_event_holder  
 87040  87040 100%    0,01K    170      512       680K kmalloc-8              
 80448  79173  98%    0,06K   1257       64      5028K kmalloc-64             
 56832  56832 100%    0,02K    222      256       888K kmalloc-16             
 31926  31926 100%    0,08K    626       51      2504K selinux_inode_security 
 31140  31140 100%    0,11K    865       36      3460K sysfs_dir_cache        
 15795  14253  90%    0,10K    405       39      1620K buffer_head            
 15008  14878  99%    1,00K    469       32     15008K xfs_inode              
 14616  13365  91%    0,19K    348       42      2784K kmalloc-192            
 11961  11714  97%    0,58K    443       27      7088K inode_cache            
 10048   9108  90%    0,06K    157       64       628K anon_vma               
  9664   9480  98%    0,12K    302       32      1208K kmalloc-128            
  9287   7954  85%    0,21K    251       37      2008K vm_area_struct         
  8624   8624 100%    0,07K    154       56       616K Acpi-ParseExt          
  7264   7063  97%    0,25K    227       32      1816K kmalloc-256            
  5908   5908 100%    0,57K    211       28      3376K radix_tree_node        
  5304   5304 100%    0,04K     52      102       208K Acpi-Namespace         
  4620   4620 100%    0,09K    110       42       440K kmalloc-96             
  3744   3586  95%    1,00K    117       32      3744K kmalloc-1024           
  3458   3458 100%    0,30K    133       26      1064K nf_conntrack_ffffffff819a29c0
  3360   3067  91%    0,50K    105       32      1680K kmalloc-512            
  3108   3108 100%    0,38K     74       42      1184K blkdev_requests        
  2975   2975 100%    0,05K     35       85       140K shared_policy_node     
  2520   2368  93%    0,64K    105       24      1680K proc_inode_cache       
  1560   1560 100%    0,81K     40       39      1280K task_xstate            
  1300   1300 100%    0,15K     50       26       200K xfs_ili                
  1272   1272 100%    0,66K     53       24       848K shmem_inode_cache      
  1176   1176 100%    1,12K     42       28      1344K signal_cache           
  1024   1024 100%    2,00K     64       16      2048K kmalloc-2048           
   975    975 100%    0,62K     39       25       624K sock_inode_cache       
   900    900 100%    0,44K     25       36       400K scsi_cmd_cache         
   864    864 100%    0,25K     27       32       216K tw_sock_TCPv6          
   737    644  87%    2,84K     67       11      2144K task_struct            
   720    672  93%    2,00K     45       16      1440K TCPv6                  
   704    704 100%    0,18K     16       44       128K xfs_log_ticket         
   665    665 100%    0,23K     19       35       152K cfq_queue              
   646    646 100%    0,94K     19       34       608K RAW                    
   640    640 100%    0,39K     16       40       256K xfs_efd_item           
   624    624 100%    0,10K     16       39        64K blkdev_ioc             
   624    624 100%    0,20K     16       39       128K xfs_btree_cur          
   578    578 100%    0,12K     17       34        68K fsnotify_event         
   555    555 100%    2,06K     37       15      1184K sighand_cache          
   528    528 100%    0,48K     16       33       256K xfs_da_state           
   512    512 100%    0,06K      8       64        32K kmem_cache_node        
   512    512 100%    1,00K     16       32       512K UDP                    
   465    465 100%    2,06K     31       15       992K idr_layer_cache        
   450    450 100%    0,62K     18       25       288K files_cache            
    
por Pitel 02.03.2015 / 15:50

1 resposta

2

Com base na saída slabtop , eu diria que algo está adicionando muitos arquivos temporários em algum lugar e, em seguida, excluindo-os. Uma mudança adicional é que algum processo ainda mantém as alças de arquivos em arquivos excluídos, para que os arquivos não sejam liberados do dentry. Como os arquivos estão marcados como excluídos, você não pode encontrá-los com os comandos ls e similares comuns.

Pode ser curl ou o script do qual você está chamando. Veja com lsof -n | grep deleted se houver muitas entradas deletadas e rastreie o culpado a partir daí.

    
por 04.03.2015 / 09:58