Estou correndoDebian GNU/Linux 5.0e estou enfrentando erros out_of_memory intermitentes vindos do kernel. O servidor para de responder a todos, exceto aos pings, e preciso reinicializar o servidor.
# uname -a
Linux xxx 2.6.18-164.9.1.el5xen #1 SMP Tue Dec 15 21:31:37 EST 2009 x86_64
GNU/Linux
Esta parece ser a parte importante de /var/log/messages
Dec 28 20:16:25 slarti kernel: Call Trace:
Dec 28 20:16:25 slarti kernel: [<ffffffff802bedff>] out_of_memory+0x8b/0x203
Dec 28 20:16:25 slarti kernel: [<ffffffff8020f825>] __alloc_pages+0x245/0x2ce
Dec 28 20:16:25 slarti kernel: [<ffffffff8021377f>] __do_page_cache_readahead+0xc6/0x1ab
Dec 28 20:16:25 slarti kernel: [<ffffffff80214015>] filemap_nopage+0x14c/0x360
Dec 28 20:16:25 slarti kernel: [<ffffffff80208ebc>] __handle_mm_fault+0x443/0x1337
Dec 28 20:16:25 slarti kernel: [<ffffffff8026766a>] do_page_fault+0xf7b/0x12e0
Dec 28 20:16:25 slarti kernel: [<ffffffff8026ef17>] monotonic_clock+0x35/0x7b
Dec 28 20:16:25 slarti kernel: [<ffffffff80262da3>] thread_return+0x6c/0x113
Dec 28 20:16:25 slarti kernel: [<ffffffff8021afef>] remove_vma+0x4c/0x53
Dec 28 20:16:25 slarti kernel: [<ffffffff80264901>] _spin_lock_irqsave+0x9/0x14
Dec 28 20:16:25 slarti kernel: [<ffffffff8026082b>] error_exit+0x0/0x6e
Trecho completo aqui:http://pastebin.com/a7eWf7VZ
Achei que talvez o servidor estivesse realmente ficando sem memória (ele tem 1 GB de memória física), mas meu gráfico de memória do Cacti parece bom para mim...
Um amigo me corrigiu aqui; ele notou que o gráfico está realmente invertido, já que o roxo indicamemória livre(não memória usada como o título sugere).
Mas, estranhamente, o gráfico de carga dispara pouco antes do kernel travar:
Quais registros posso consultar para obter mais informações?
Atualizar:
Talvez digno de nota - a porcentagem de CPU e os gráficos de tráfego de rede estavam normais no momento da falha. A única anormalidade foi o gráfico de carga média.
Atualização 2:
Acho que isso começou a acontecer quando implantei o Passenger/Ruby, e usando topvejo que Ruby está usando a maior parte da memória e uma boa quantidade de CPU:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5189 www-data 18 0 255m 124m 3388 S 0 12.1 12:46.59 ruby1.8
14087 www-data 16 0 241m 117m 2328 S 21 11.4 3:41.04 ruby1.8
15883 www-data 16 0 239m 115m 2328 S 0 11.3 1:35.61 ruby1.8
Responder1
Verifique as mensagens de log para obter indicações do eliminador de falta de memória do kernel ou OOM killedna saída do arquivo dmesg. Isso pode dar alguma indicação de quais processos foram alvo do assassino OOM. Dê uma olhada também no seguinte:
http://lwn.net/Articles/317814/
e
http://linux-mm.org/OOM_Killer
O que esse sistema faz? Você está cansando a troca ao mesmo tempo? Parece que o problema é o rsyslogd, com base no seu link externo detalhando a falha. Esta pode ser uma situação em que uma reinicialização periódica do aplicativo seria útil.
Responder2
2.6.18 é um kernel muito antigo. Eu me deparei com problemas onde certas condições podem desencadear loops infinitos no kernel, resultando em qualquer coisa, desde exaustão de memória até largura de banda de E/S sendo totalmente usada para liberar os mesmos dados para o disco em um loop infinito (o que causa picos de carga, mas a CPU normal usar.)
Esses bugs tendem a ser corrigidos logo após serem relatados, então uma atualização do kernel é uma solução fácil para isso - além disso, atualizar o kernel significa que você receberá algumas correções de segurança gratuitamente :-)
Responder3
Por outro lado, não se esqueça de que Cacti e similares são gráficos em uma determinada resolução (collectd é 5s por padrão, cacti acredito que 30s por padrão), então você tem um período de 30 a 60 segundos que não necessariamente aparece no seu gráficos ... se o sistema estiver totalmente paralisado, isso também afetará o daemon de coleta de dados.
Você pode encontrar informações úteis adicionais em seus arquivos de log, sejam eles /var/log/messages gerais ou /var/log/apache2/error.log específicos do serviço.
Se não puder, recomendo que você revise seus serviços (observei o apache2 na extração de log acima) e verifique se eles são capazes de causar uma situação de esgotamento de memória em seu servidor. (ex.: configuração padrão do apache, com mod_prefork e php deve ser capaz de parar seu sistema).