O Apache ficou fora de controle nos últimos dias e fez o MySQL travar duas vezes. Tudo começou quando migrei um site WordPress que também contém um fórum phpBB.
Não tenho muita experiência em administração de servidores, por isso tem sido muito difícil identificar o que está causando o problema. Quando percebi que o MySQL estava fora do ar, executei o TOP e vi a carga do meu sistema aumentar para 98,00. O servidor executa 10 V-HOSTS, todos recebendo uma boa quantidade de tráfego, então obviamente eu estava vendo muitos processos do Apache-2 em execução.
A alta carga do servidor continuou por 10 minutos e depois voltou ao estado normal. Não vi um aumento no tráfego de rede neste momento.
Infelizmente, o log de erros do MySQL foi desabilitado (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 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 trava?
Agora instalei htop. Isso poderia ser mais útil do 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
Responder1
O MySQL ainda pode não registrar nada, porque o que provavelmente está acontecendo é que ele está sendo eliminado sem cerimônia pelo sistema devido à pressão de memória do sistema dos filhos do Apache. Deve haver uma trilha disso em/var/log/syslog.
O MySQL deveria tentar reiniciar-se em caso de travamento ou encerramento forçado, mas a menos que haja memória suficiente disponível, ele não pode fazer isso... e esta segunda falha não é vista pelo mysqld_safe como um "travamento", mas sim como uma "recusa de começar", então ele não continuará tentando. A tentativa de reinicialização malsucedida é muitas vezes mal interpretada pelos administradores como "travamento", uma vez que a natureza da falha original está escondida atrás de uma mensagem facilmente esquecida no log de erros do MySQL:
mysqld_safe Number of processes running now: 0
VerCrash do InnoDB pós-mortepor uma circunstância que suspeito ser semelhante à sua.
A resposta aparentemente simples para o "porquê" é 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 essa condição à tona .
O Apache atende cada solicitação simultânea do navegador de um processo filho, portanto, à medida que o número de conexões simultâneas aumenta, o número de filhos também aumenta. Primeiro, você precisará limitar esse valor na configuração do Apache para poder entender o que realmente está causando o aumento nas conexões simultâneas... é 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 demoram muito? Algo precisando de otimização?
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclients
Limitar processos Apache simultâneos deve ajudar a evitar isso, mas para ser claro, é ingênuo pensar que esta é a solução completa, então não quero sugerir isso. Uma vez que os processos estejam limitados a um nível razoável ou pelo menos mais seguro, você poderá prosseguir com a identificação do que realmente está 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, à primeira vista, “maximizar a utilização” de uma máquina partilhando-a, esta é uma falsa economia. A maior parte da memória usada pelo MySQL, em uma carga de trabalho típica, é alocada no momento da inicialização e mantida enquanto o MySQL Server estiver em execução. As demandas da CPU provavelmente compartilharão os horários de pico do MySQL e do Apache, uma vez que, em última análise, eles atendem à mesma carga. Na verdade, você pode ficar melhor com duas máquinas m1.large em vez de uma única m1.xlarge, e o custo seria o mesmo, já que a menor custa exatamente metade do preço da maior... mesmo que você já tenha pago antecipadamente para o desconto adicional,essa mudança pode ser realizada.
Responder2
Você tem alguns pontos para verificar:
-Verifique /var/log/messages: oomkiller pode encerrar o processo mysql se não houver mais memória para usar. Verifique a memória RAM com free -lm (sem cache)
-Se você usa apache com 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 poderão aumentar rapidamente.
-Verifique o número de threads lançados pelo mysql com ummostrar status global: threads_cached, threads_created e threads_running são importantes para verificar (threads_created deve estar próximo de 0).
-Verifique a memória RAM usada pelo Mysql.
Responder3
Você também pode considerar a implementaçãocpusetse reservando recursos para mysql. Isso é o mais próximo de executar esses serviços em hardware diferente, mas ainda oferece os benefícios de manter um único servidor.