Por que o Apache está sendo executado e matando o MySQL?

8

O Apache ficou fora de controle nos últimos dias e causou uma falha no MySQL duas vezes. Tudo começou quando eu migrei um site WordPress sobre o qual também contém um fórum phpBB.

Não sou muito experiente em administração de servidores, por isso tem sido muito difícil identificar o que está causando o problema. Quando notei que o MySQL estava inoperante, rodei o TOP e vi meu pico de carga do sistema para 98.00. O servidor executa 10 V-HOSTS, os quais recebem uma boa quantidade de tráfego, então eu obviamente estava vendo muitos processos do apache-2 em execução.

A alta carga do servidor continuou por 10 minutos e depois retornou ao estado normal. Eu não vi um pico de tráfego de rede neste momento.

Infelizmente, o log de erros do MySQL foi desativado (agora está reativado), então não há pistas. Mas tenho certeza que é porque o Apache estava consumindo todos os recursos, então o ID do processo do MySQL foi eliminado.

Minhas perguntas são:

Da próxima vez que isso ocorrer - como posso identificar o que está causando o pico de carga do sistema? Poderia ser um script php que enlouqueceu? Poderia ser um ataque DDOS?

Existe uma maneira de reiniciar automaticamente o MySQL quando ele falha?

Eu instalei agora htop . Isso poderia ser mais útil que top ?

Aqui estão as estatísticas do meu servidor:

m1.xlarge (8 ECUs, 4 vCPUs, 15 GiB memory, 4 x 420 GiB Storage Capacity)
Ubuntu Server 12.04.3 LTS 
    
por Bob Flemming 19.12.2013 / 12:54

3 respostas

9

O MySQL ainda pode não registrar nada, porque o que provavelmente está acontecendo é que ele está sendo morto sem cerimônia pelo sistema devido à pressão da memória do sistema dos filhos do apache. Deve haver uma trilha disso em / var / log / syslog.

O MySQL deve tentar se reinicializar em um travamento ou terminação forçada, mas a menos que haja memória suficiente disponível, ele não pode fazer isso ... e essa segunda falha não é vista pelo mysqld_safe como um "travamento", mas como um "recusa em começar", por isso não vai continuar tentando. A tentativa de reinicialização com falha é muitas vezes mal interpretada pelos administradores como "falha", já que a natureza da falha original fica oculta atrás de uma mensagem facilmente ignorada no log de erros do MySQL:

mysqld_safe Number of processes running now: 0

Veja InnoDB Crash Post Mortem por uma circunstância que eu suspeito que seja semelhante à sua.

A resposta aparentemente simples para "por que" é que entre o Apache e o MySQL, a carga que você tem e suas configurações atuais, você não tem memória suficiente na máquina e há algum ponto de inflexão relacionado à carga de tráfego que traz esta condição para fora.

O Apache atende a cada solicitação de navegador simultânea de um processo filho, de modo que o número de conexões simultâneas aumenta, o número de filhos aumentará. Primeiro você precisa limitar esse valor na configuração do apache para que você possa entender o que realmente está causando o aumento nas conexões simultâneas ... será simplesmente um pico de tráfego pesado, mas legítimo? Algum tipo de negação de serviço? Consultas de banco de dados que atrasam solicitações porque elas são executadas por muito tempo? Algo precisando otimizar?

link

Limitar processos do Apache simultâneos deve ajudar a evitar isso, mas, para ser claro, é ingênuo pensar que essa é a solução completa, então não quero implicar isso. Quando os processos são limitados a um nível razoável ou pelo menos mais seguro, você pode identificar o que está realmente acontecendo. (Existem outros controles de restrição no Apache, mas essa não é minha área de especialização.)

A "melhor prática" é, obviamente, executar seu banco de dados em hardware diferente, para que o aplicativo não possa eliminá-lo. Embora pareça mais eficiente, na superfície, "maximizar a utilização" de uma máquina compartilhando-a, isso é uma falsa economia. A maioria da memória usada pelo MySQL, em uma carga de trabalho típica, é alocada no tempo de inicialização e mantida pelo tempo em que o MySQL Server está em execução. As demandas da CPU provavelmente compartilharão horários de pico para o MySQL e o Apache, já que eles estão, em última análise, atendendo a mesma carga. Você pode realmente estar melhor com duas máquinas m1.large em vez da única m1.xlarge, e o custo seria o mesmo, já que a menor é exatamente a metade do preço da maior ... mesmo se você já pagou antecipadamente para o desconto adicional, essa alteração pode ser realizada .

    
por 19.12.2013 / 14:46
1

Você tem alguns pontos para verificar:

- Verifique o / var / log / messages: oomkiller pode matar o processo mysql se não houver mais memória para usar. Verifique o ram com free -lm (sem cache)

-Se você usa o apache com o prefork mpm: verifique o número do processo. Se o apache empilhar um número importante de processos (durante uma carga de trabalho pesada) com um link para o mysql, a latência e a memória usada podem crescer rapidamente.

- Verifique o número de threads lançados pelo mysql com um show global status : threads_cached, threads_created e threads_running são importantes para verificar (threads_created deve estar perto de 0).

Verifique o carneiro usado pelo Mysql.

    
por 19.12.2013 / 15:04
0

Você também pode procurar implementar cpusets e reservando recursos para o mysql. Isso é o mais próximo de executar esses serviços em um hardware diferente, mas ainda oferece os benefícios de manter um único servidor.

    
por 19.12.2013 / 15:54