MySQL potrebbe non registrare ancora nulla, perché ciò che sta probabilmente accadendo è che viene ucciso senza tante cerimonie dal sistema a causa della pressione della memoria di sistema da parte dei bambini di Apache. Dovrebbe esserci una traccia di questo in / var / log / syslog.
MySQL dovrebbe tentare di riavviarsi in caso di arresto anomalo o terminazione forzata, ma se non è disponibile memoria sufficiente, non può farlo ... e questo secondo errore non è visto da mysqld_safe come un "arresto", ma piuttosto come un "rifiuto di inizio ", quindi non continuerà a provare. Il tentativo di riavvio non riuscito viene spesso interpretato erroneamente dagli amministratori come "arresto anomalo", poiché la natura dell'errore originale è nascosta dietro un messaggio facilmente trascurabile nel registro errori di MySQL:
mysqld_safe Number of processes running now: 0
Vedi InnoDB Crash Post Mortem per una circostanza che sospetto sia simile alla tua.
La risposta apparentemente semplice al "perché" è che tra Apache e MySQL, il carico che hai e le tue attuali configurazioni, non hai abbastanza memoria sulla macchina e c'è un punto di non ritorno relativo al carico del traffico che fa emergere questa condizione .
Apache serve ogni richiesta del browser simultanea da un processo figlio, quindi del numero di connessioni simultanee aumenta, il numero di figli aumenterà. Dovrai prima limitare questo valore nella configurazione di Apache in modo da poter capire cosa sta effettivamente causando l'aumento delle connessioni simultanee ... è semplicemente un picco di traffico pesante ma legittimo? Qualche tipo di negazione del servizio? Query DB che ritardano le richieste perché durano troppo a lungo? Qualcosa che necessita di ottimizzazione?
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclients
Limitare i processi simultanei di Apache dovrebbe aiutare a prevenire questo, ma per essere chiari, è ingenuo pensare che questa sia la soluzione completa, quindi non voglio implicarlo. Una volta che i processi sono limitati a un livello ragionevole o almeno più sicuro, è possibile procedere con l'identificazione di ciò che sta realmente accadendo. (Esistono altri controlli di limitazione su Apache, ma questa non è la mia area di competenza.)
La "best practice" è ovviamente quella di eseguire il database su hardware diverso in modo che l'applicazione non possa ucciderlo. Mentre sembra più efficiente, in superficie, "massimizzare l'utilizzo" di una macchina condividendola, questa è una falsa economia. La maggior parte della memoria utilizzata da MySQL, in un tipico carico di lavoro, viene allocata al momento dell'avvio e mantenuta per tutto il tempo in cui MySQL Server è in esecuzione. È probabile che le esigenze della CPU condividano le ore di punta per MySQL e Apache, poiché alla fine servono lo stesso carico. In realtà potresti stare meglio con due m1.large invece del singolo m1.xlarge, e il costo sarebbe lo stesso dal momento che quello più piccolo è esattamente la metà del prezzo di quello più grande ... anche se hai già pagato in anticipo per lo sconto aggiuntivo, questa modifica può essere effettuata .
dmesgaiuto?