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 pelos filhos do apache. Deve haver uma trilha disso em / var / log / syslog.
O MySQL deve tentar se reiniciar 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 esta segunda falha não é vista pelo mysqld_safe como um "travamento", mas como uma "recusa a iniciar ", para que não continue tentando. A tentativa de reinicialização com falha geralmente é mal interpretada pelos administradores como "falha", pois a natureza da falha original está oculta por trás de uma mensagem facilmente ignorada no log de erros do MySQL:
mysqld_safe Number of processes running now: 0
Consulte Crash Post Mortem do InnoDB para obter uma circunstância que suspeito ser semelhante à sua.
A resposta aparentemente simples para "por que" é que, entre o Apache e o MySQL, a carga que você tem e as configurações atuais, você não tem memória suficiente na máquina e há um ponto de inflexão relacionado à carga de tráfego que traz essa condição à tona .
O Apache atende a cada solicitação simultânea do navegador a partir de um processo filho; portanto, do número de conexões simultâneas aumentar, o número de filhos aumentará. Você primeiro precisará limitar esse valor na configuração do apache para entender o que realmente está causando o aumento de 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 que precisa ser otimizado?
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclients
Limitar os processos concorrentes do Apache deve ajudar a evitar isso, mas, para ficar claro, é ingênuo pensar que essa é a solução completa, então não quero sugerir isso. Depois que os processos estiverem limitados a um nível razoável ou pelo menos mais seguro, você poderá continuar identificando o que realmente está acontecendo. (Existem outros controles de restrição no Apache, mas essa não é minha área de especialização.)
Naturalmente, a "melhor prática" é executar seu banco de dados em hardware diferente, para que o aplicativo não possa matá-lo. Embora pareça mais eficiente, na superfície, "maximizar a utilização" de uma máquina compartilhando-a, essa é uma economia falsa. A maioria 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. É provável que as demandas da CPU compartilhem horários de pico para MySQL e Apache, uma vez que estão servindo 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, pois 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 .
dmesgajudaria?