CentOS, kernel: sem memória

Question

Espero que você possa me ajudar com o seguinte problema.

Estamos executando um serviço CrushFTP em um sistema do CentOS versão 6.6 (Final). Mas quase toda semana o serviço falha.

Então, dou uma olhada nos logs e encontrei essas linhas

cat /var/log/messages

Jun 28 05:06:23 crushftp kernel: Out of memory: Kill process 1491 (java) score 883 or sacrifice child
Jun 28 05:06:23 crushftp kernel: Killed process 1491, UID 0, (java) total-vm:9620220kB, anon-rss:3245824kB, file-rss:128kB

O CrushFTP é o java e o único serviço que estamos executando na máquina. O log parece que o sistema está eliminando o processo.

Mas eu não entendo o porquê. Então eu procurei um pouco encontrei essa configuração

cat /proc/sys/vm/overcommit_memory
0

Quando eu entendi correto, o valor deve estar ok e se o processo precisar de mais RAM, ele deve ser capaz de obtê-lo.

Quando eu faço um "top", o processo java é o processo com o maior uso de RAM.

top - 11:13:58 up 1 day, 4 min,  1 user,  load average: 0.93, 0.94, 0.91
Tasks:  97 total,   1 running,  96 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.2%us, 19.7%sy,  0.0%ni, 68.6%id,  0.0%wa,  0.0%hi,  0.5%si,  0.0%st
Mem:   3924136k total,  2736996k used,  1187140k free,   149380k buffers
Swap:  4128764k total,        0k used,  4128764k free,   814480k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
1486 root      20   0 3633m 1.5g  13m S 20.3 39.8 191:24.36 java

A RAM é de cerca de 4 GB e o arquivo SWAP é do mesmo tamanho.

[root@atcrushftp ~]# cat /proc/meminfo
MemTotal:        3924136 kB
MemFree:         1159964 kB
Buffers:          149400 kB
Cached:           814476 kB
SwapCached:            0 kB
Active:          1956028 kB
Inactive:         619664 kB
Active(anon):    1611452 kB
Inactive(anon):      528 kB
Active(file):     344576 kB
Inactive(file):   619136 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       4128764 kB
SwapFree:        4128764 kB
Dirty:                36 kB
Writeback:             4 kB
AnonPages:       1597696 kB
Mapped:            34108 kB
Shmem:               164 kB
Slab:             136024 kB
SReclaimable:      74432 kB
SUnreclaim:        61592 kB
KernelStack:        1384 kB
PageTables:         5948 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     6090832 kB
Committed_AS:     746432 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      285216 kB
VmallocChunk:   34359441520 kB
HardwareCorrupted:     0 kB
AnonHugePages:   1501184 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       18432 kB
DirectMap2M:     4175872 kB

Perguntei ao suporte, mas eles estão dizendo que não é uma falha do CrushFTP e o sistema está ficando sem memória.

Agora, minha pergunta é: como descobrir qual processo está tirando toda a última memória livre?

    

Answer 1

Já faz um tempo desde que eu tive que ler um log do OOM-killer, mas se bem me lembro, isso

Jun 28 05:06:23 crushftp kernel: Killed process 1491, UID 0, (java) total-vm:9620220kB, anon-rss:3245824kB, file-rss:128kB

significa que java estava usando 9GB de VM quando o OOM-killer disparou na cabeça. Dado que você tem 4GB de núcleo e 4GB de swap, isso parece ser uma coisa razoável de se fazer. Você então escreve

When I understand it correct, the value must be ok and if the process needs more RAM it should be able to get it.

que eu não entendo.

Em primeiro lugar, definir esse valor como 0 não desativa o comprometimento excessivo. Como a Red Hat escreve , configure isso para 0 requer que o

kernel performs heuristic memory overcommit handling by estimating the amount of memory available and failing requests that are blatantly invalid. Unfortunately, since memory is allocated using a heuristic rather than a precise algorithm, this setting can sometimes allow available memory on the system to be overloaded.

Definir como 2 faz o que você parece querer:

The kernel denies requests for memory equal to or larger than the sum of total available swap and the percentage of physical RAM specified in overcommit_ratio. This setting is best if you want a lesser risk of memory overcommitment.

Mas até mesmo desativar o overcommit não garante que um processo sempre consiga mais RAM: somente uma VM infinita garante isso. Enquanto o core + swap é finito, ele pode ser usado - e se você tem um processo que consome toda a VM livre no momento em que o kernel precisa de um pouco mais, então o OOM-killer vai acordar, e, bem, parece o que aconteceu.

Minhas recomendações são:

1. Não execute java como root. O ideal é não executá-lo, mas se for necessário, não como raiz; isso dá uma ponderação nos olhos que matam a OOM, o que pode resultar em algo importante ser morto em vez disso.

2. Encontre o vazamento de memória em qualquer coisa que esteja usando java.

3. Se você realmente acredita que não tem vazamento de memória, não tem núcleo suficiente; Pônei para um servidor maior. Dê mais swap também.

4. Monitore melhor a pegada de VM do seu java; atire na cabeça se ficar todo inchado.