(Como) posso usar o syslog para diagnosticar falhas misteriosas?

Question

Eu corro uma pilha LAMP no servidor Ubuntu. Por duas vezes, a parada foi interrompida e exigiu uma reinicialização difícil. Antes disso, permaneceu estável por muitos meses. Já faz quinze dias desde a última mudança na configuração e até isso foi menor.

Revisando, achei isso no syslog alguns minutos antes de um e-mail cron com falha me alertar sobre a interrupção:

Sep 22 18:14:33 rfb CRON[4912]: (tom) CMD (/usr/share/rfb-scripts/rrdtool-updater.sh)
Sep 22 18:15:40 rfb CRON[4923]: (tom) CMD (/usr/share/rfb-scripts/rrdtool-updater.sh)
Sep 22 18:16:36 rfb CRON[4952]: (tom) CMD (/usr/share/rfb-scripts/rrdtool-updater.sh)
Sep 22 18:16:48 rfb kernel: [16220.076166] apache2 invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Sep 22 18:16:48 rfb kernel: [16220.076173] Pid: 4908, comm: apache2 Not tainted 2.6.32.9-rscloud #6
Sep 22 18:16:48 rfb kernel: [16220.076175] Call Trace:
Sep 22 18:16:48 rfb kernel: [16220.076186]  [<ffffffff8105ca35>] ? T.383+0x78/0x239
Sep 22 18:16:48 rfb kernel: [16220.076191]  [<ffffffff8103dea6>] ? timekeeping_get_ns+0xe/0x2e
Sep 22 18:16:48 rfb kernel: [16220.076195]  [<ffffffff8105cd2a>] ? __out_of_memory+0x134/0x14b
Sep 22 18:16:48 rfb kernel: [16220.076198]  [<ffffffff8105cdab>] ? out_of_memory+0x6a/0x94
Sep 22 18:16:48 rfb kernel: [16220.076202]  [<ffffffff8105f96f>] ? __alloc_pages_nodemask+0x47f/0x56b
Sep 22 18:16:48 rfb kernel: [16220.076206]  [<ffffffff81061112>] ? __do_page_cache_readahead+0x9e/0x1a1
Sep 22 18:16:48 rfb kernel: [16220.076212]  [<ffffffff810384bd>] ? wake_bit_function+0x0/0x2e
Sep 22 18:16:48 rfb kernel: [16220.076214]  [<ffffffff81061231>] ? ra_submit+0x1c/0x20
Sep 22 18:16:48 rfb kernel: [16220.076217]  [<ffffffff8105af33>] ? filemap_fault+0x17e/0x2ff
Sep 22 18:16:48 rfb kernel: [16220.076221]  [<ffffffff8106ea79>] ? __do_fault+0x54/0x335
Sep 22 18:16:48 rfb kernel: [16220.076224]  [<ffffffff8106f008>] ? handle_mm_fault+0x2ae/0x636
Sep 22 18:16:48 rfb kernel: [16220.076228]  [<ffffffff81014211>] ? do_page_fault+0x299/0x2ae
Sep 22 18:16:48 rfb kernel: [16220.076232]  [<ffffffff81226e18>] ? page_fault+0x28/0x30
Sep 22 18:16:48 rfb kernel: [16220.076235] Mem-Info:
Sep 22 18:16:48 rfb kernel: [16220.076237] DMA per-cpu:
Sep 22 18:16:48 rfb kernel: [16220.076238] CPU    0: hi:    0, btch:   1 usd:   0
Sep 22 18:16:48 rfb kernel: [16220.076240] CPU    1: hi:    0, btch:   1 usd:   0
Sep 22 18:16:48 rfb kernel: [16220.076242] CPU    2: hi:    0, btch:   1 usd:   0
Sep 22 18:16:48 rfb kernel: [16220.076244] CPU    3: hi:    0, btch:   1 usd:   0
Sep 22 18:16:48 rfb kernel: [16220.076245] DMA32 per-cpu:
Sep 22 18:16:48 rfb kernel: [16220.076247] CPU    0: hi:  155, btch:  38 usd:  49
Sep 22 18:16:48 rfb kernel: [16220.076249] CPU    1: hi:  155, btch:  38 usd:  37
Sep 22 18:16:48 rfb kernel: [16220.076251] CPU    2: hi:  155, btch:  38 usd:  22
Sep 22 18:16:48 rfb kernel: [16220.076252] CPU    3: hi:  155, btch:  38 usd:  45

As primeiras 3 linhas são incluídas para demonstrar a operação normal. O diário continua, mas vou poupar você dessa empolgação. (Se você realmente quiser vê-lo, tente este pastebin .)

Minha pergunta então é: posso usar este log para diagnosticar meu problema? Se sim, como? E um ponto de bônus para qualquer um que possa me dizer o que eu preciso fazer para evitar que isso aconteça novamente.

    

Answer 1

De acordo, foi o apache2, que foi o processo infeliz, mas foi o culpado por mim antes. Normalmente, especialmente com perl, php, ou mod_python irá continuar alocando memória ram para alguma aplicação web. À medida que clientes diferentes atingem diferentes processos do apache, eles continuarão aumentando a utilização da memória.

Se o seu tráfego for alto o suficiente para manter os processos do apache ativos, você pode acabar com 256 processos do apache em execução. Mas, não tem que estar nem perto desse limite, eu já tive um dia ruim com 30 processos apache usando 250-300MB ou ram cada.

Aumentar o swap vai te dar um pouco de tempo, para pegar a caixa e ver o que está acontecendo, mas você precisa ser avisado para que você possa ver qual processo está consumindo memória RAM, verifique se realmente é o apache.

Use gratuitamente em um cron job ou cacti e snmp com limites. Com livre, você precisará assistir buffers e ram livre, totalizá-los e alertar em algum limite inferior.

Outra coisa, se for o apache, pode ser trazer seus MaxClients, pode ter um alto número padrão. Ou, traga o MaxRequestsPerChild para um número baixo o suficiente para matar processos de vez em quando. Este é apenas um band-aid, mas pode ajudar a deixar você mancar o suficiente para resolver o problema.

Apenas minha facada no ar Scott M

    

Answer 2

algo tenta alocar mais memória do que você tem. obviamente você poderia adicionar mais swap, mas isso mataria o desempenho da sua caixa. talvez adicione um pequeno script que será executado periodicamente [ainda mais do que uma vez por minuto]

date >> /some/file
ps faux >> /some/file

e registra a saída - você pode identificar o processo alocando mais e mais memória.

    

Answer 3

O conselho de @ user36376 é bom. Parece que você tem um vazamento de memória. Até você rastreá-lo ajustando o apache para matar processos após o servidor, algumas solicitações provavelmente lhe darão tempo para identificar o vazamento. Como esta é uma nova ocorrência, uma mudança recente deve ser suspeitada. Você também pode querer considerar o uso de ulimit para minimizar o tamanho das crianças do apache. A memória vazada pode ser trocada com pouco impacto, portanto, aumentar o swap pode ajudar.

Considere usar a parte superior para monitorar o tamanho da imagem virtual. Você pode alterar a ordem para que o tamanho virtual seja o primeiro campo de classificação. Os maiores programas irão flutuar para o topo.