Estou rodando o Debian GNU / Linux 5.0 e estou tendo erros out_of_memory intermitentes vindos do kernel. O servidor pára de responder a todos, exceto pings, e eu tenho que reiniciar 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
Este parece ser o bit 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
Snippet completo aqui: link
Eu pensei que talvez o servidor estivesse realmente ficando sem memória (ele tem 1GB de memória física), mas meu gráfico de memória do Cacti parece OK para mim ...
Um amigo me corrigiu aqui; ele notou que o gráfico está realmente invertido, já que o roxo indica memória livre (não a memória usada como o título sugere).
Mas,estranhamente,ográficodecargapassapelotelhadopoucoantesdeokerneltravar:
Quais logs eu posso consultar para mais informações?
Talvez seja digno de nota - a porcentagem de CPU e os gráficos de tráfego de rede eram normais no momento da falha. A única anormalidade foi o gráfico de carga média.
Acho que isso começou a acontecer quando implantei o Passenger / Ruby e, usando top , vejo que o 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
Verifique nas mensagens de log as indicações do killer de memória insuficiente do kernel ou OOM killed na saída de dmesg . Isso pode dar alguma indicação de quais processos foram o alvo do assassino da OOM. Veja também o seguinte:
e
O que esse sistema faz? Você está esgotando swap ao mesmo tempo? Parece que o rsyslogd é o problema, baseado em seu link externo detalhando o travamento. Esta poderia ser uma situação em que um reinício periódico do aplicativo seria útil.
2.6.18 é um kernel muito antigo. Eu tive problemas onde certas condições podem disparar loops infinitos no kernel, resultando em qualquer coisa, desde esgotamento de memória até largura de banda de E / S sendo totalmente usada liberando os mesmos dados para o disco em um loop infinito (que causa picos de carga, mas CPU normal usar.)
Esses bugs tendem a ser corrigidos logo após serem reportados, então uma atualização do kernel é uma correção fácil para isso - além de atualizar o kernel significa que você tem algumas correções de segurança lançadas de graça: -)
Em outra nota, não esqueça que o Cacti e o gráfico em uma certa resolução (collectd é 5s por padrão, cactos eu acredito 30s por padrão) então você tem um período de 30-60 segundos que não necessariamente mostram em seus gráficos ... se o sistema estiver totalmente atolado, isso também afetará o daemon de coleta de dados.
Você pode encontrar informações úteis adicionais nos seus arquivos de registro, sejam eles / var / log / messages ou /var/log/apache2/error.log específicos do serviço.
Se não puder, recomendo que você consulte seus serviços (observei o apache2 dentro de sua 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 devem ser capazes de fazer com que o seu sistema pare).
Tags kernel memory-usage linux