Es posible que MySQL aún no registre nada, porque lo que probablemente esté sucediendo es que el sistema lo está eliminando sin ceremonias debido a la presión de la memoria del sistema por parte de los hijos de Apache. Debería haber un rastro de esto en / var / log / syslog.
MySQL debería intentar reiniciarse en un bloqueo o terminación forzada, pero a menos que haya suficiente memoria disponible, no puede hacer eso ... y mysqld_safe no ve este segundo fallo como un "bloqueo" sino más bien como un "rechazo a empezar ", por lo que no seguirá intentándolo. El intento de reinicio fallido a menudo es malinterpretado por los administradores como el "bloqueo", ya que la naturaleza de la falla original está oculta detrás de un mensaje fácilmente ignorado en el registro de errores de MySQL:
mysqld_safe Number of processes running now: 0
Vea InnoDB Crash Post Mortem para una circunstancia que sospecho que es similar a la suya.
La respuesta aparentemente simple a "por qué" es que entre Apache y MySQL, la carga que tiene y sus configuraciones actuales, no tiene suficiente memoria en la máquina, y hay algún punto de inflexión relacionado con la carga de tráfico que saca esta condición .
Apache atiende cada solicitud simultánea del navegador desde un proceso secundario, por lo que a medida que aumenta el número de conexiones simultáneas, aumentará el número de elementos secundarios. Primero tendrá que limitar este valor en la configuración de apache para que pueda comprender qué está causando realmente el aumento de las conexiones concurrentes ... ¿es simplemente un pico de tráfico pesado pero legítimo? ¿Algún tipo de denegación de servicio? ¿Consultas de bases de datos que retrasan las solicitudes porque se ejecutan demasiado tiempo? ¿Algo que necesita optimización?
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclients
Limitar los procesos concurrentes de Apache debería ayudar a prevenir esto, pero para ser claros, es ingenuo pensar que esta es la solución completa, por lo que no quiero dar a entender eso. Una vez que los procesos se limitan a un nivel razonable o al menos más seguro, puede proceder a identificar lo que realmente está sucediendo. (Hay otros controles de restricción en Apache, pero esa no es mi área de especialización).
La "mejor práctica" es, por supuesto, ejecutar su base de datos en un hardware diferente para que la aplicación no pueda eliminarla. Si bien parece más eficiente, en la superficie, "maximizar la utilización" de una máquina compartiéndola, esta es una economía falsa. La mayoría de la memoria utilizada por MySQL, en una carga de trabajo típica, se asigna en el momento del inicio y se mantiene durante el tiempo que MySQL Server se está ejecutando. Es probable que las demandas en la CPU compartan los tiempos pico para MySQL y Apache, ya que en última instancia están sirviendo la misma carga. En realidad, podría estar mejor con dos máquinas m1.large en lugar de la única m1.xlarge, y el costo sería el mismo ya que la más pequeña es exactamente la mitad del precio de la más grande ... incluso si ya pagó por adelantado para el descuento adicional, este cambio se puede lograr .
dmesgayudaría?