Constantemente tiene que recargar PHP-FPM

Tenemos un servidor bastante cargado que ejecuta nginx y PHP-FPM. Tenemos 6 sitios web en este servidor, ejecutando PHP-FPM y nginx. El software es todo vBulletin 3.8 y WordPress. Las bases de datos están en un servidor separado.

Ahora, debido a que estos son sitios web muy populares, normalmente tenemos de 7 a 8,000 visitantes en línea al mismo tiempo, y cada página llega a la base de datos en su mayor parte. Creo que esta es la causa de nuestros problemas.

Debido a que tenemos muchas bases de datos grandes en el servidor MySQL, y debido a que las consultas podrían, honestamente, ser mucho mejores en el software, creo que MySQL ocasionalmente no devolverá los resultados a PHP de manera oportuna, creando un efecto en cascada que eventualmente hace que todo se detenga hasta que volvamos a cargar PHP-FPM. Después de hacer eso, las cosas comienzan a funcionar bien nuevamente.

La razón por la que tengo problemas para solucionar esto es porque realmente no puedo discernir nada de los registros. En el registro de consultas lentas de MySQL, no veo nada de interés cuando se produce el tiempo de inactividad. En los registros de nginx, veo miles de entradas que dicen que la solicitud de lectura agotó el tiempo de espera o que la conexión agotó el tiempo de espera (a PHP-FPM). Y en los registros de PHP-FPM, veo muchas líneas que dicen "tiempo de ejecución agotado (31 segundos), terminando

Entonces, en este punto, no sé por completo dónde buscar el problema. Obviamente, lo que está sucediendo está sucediendo porque estos scripts no se ejecutan lo suficientemente rápido a veces (normalmente se cargan en menos de un segundo, pero sucede algo que hace que el tiempo de carga se dispare). Esto sucede muchas veces al día y se ha convertido en un problema para nosotros.

Por ahora, simplemente tengo un crontab para dar servicio a la recarga de php5-fpm cada 10 minutos, lo que soluciona el problema de bloqueo. Por supuesto, cuando PHP se recarga, nginx arroja un error de puerta de enlace 502, por lo que no es una gran solución.

PHP está ejecutando caché APC, si eso importa. He leído en algunos puntos que APC puede causar colgar bajo ciertas circunstancias.

Cualquier indicador será de ayuda. Realmente me gustaría no tener que preocuparme por esta máquina todo el tiempo.

Se puede proporcionar más información, por supuesto. Solo hazme saber que necesitas.

Actualización: acabo de copiar sobre apc.php a una raíz web y accedí a él para ver nuestras estadísticas. Las cosas se veían bien. Luego hice clic en el enlace para ir a Estadísticas de usuario y BOOM, el servidor se colgó instantáneamente. Recargué php-fpm y luego volví a cargar la página de estadísticas del usuario y funcionó bien. Esperé un minuto, volví a cargar, el servidor volvió a colgar.

Así que esto definitivamente parece estar relacionado con APC. La pregunta es: ¿cómo lo solucionamos?

Configuración APC:

[apc]
apc.enabled="1"
apc.stat = "1"
apc.max_file_size = "2M"
apc.localcache = "1"
apc.localcache.size = "256"
apc.shm_segments = "1"
apc.ttl = "3600"
apc.user_ttl = "7200"
apc.gc_ttl = "3600"
apc.cache_by_default = "1"
apc.filters = ""
apc.write_lock = "1"
apc.num_files_hint= "10000"
apc.user_entries_hint="10000"
apc.shm_size = "1G"
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.include_once_override = "0"
apc.file_update_protection="2"
apc.canonicalize = "1"
apc.report_autofilter="0"
apc.stat_ctime="0"

Actualización 2: Hemos progresado un poco en esto aquí. Resulta que el complemento de almacenamiento en caché de WordPress (W3 Total Cache) es lo que estaba causando los bloqueos. Todavía no sabemos por qué, pero con él deshabilitado, hemos estado ejecutando PHP durante casi 4 horas sin recargas, sin ralentizaciones, sin fallas. Todavía estamos usando APC en los foros de vBulletin y no hay problemas en absoluto. ¿Hay alguna forma de determinar POR QUÉ APC falla? Me encantaría usarlo en nuestras instalaciones de WordPress, pero no a costa de un sistema frágil.

Estás usando php-fpm, así que sugiero ser más agresivo con el tiempo que los niños de php-fpm pueden vivir. Debe encontrar el punto óptimo entre hilos / hijos de corta duración y estabilidad. Los valores predeterminados de php-fpm son generosos para cualquier sistema de producción, en mi humilde opinión.

Reduciría el número de pm.max_requests para sus grupos de producción. Creo que el valor predeterminado es 200. Comenzaría desde 50 y vería a dónde lo lleva.

Si falla o es complementario a eso, también puede probar estas opciones globales (AFAIK, todas están deshabilitadas de forma predeterminada):

emergency_restart_threshold=3
emergency_restart_interval=1m
process_control_timeout=5s

¿Qué significa esto? Si 3 procesos secundarios PHP-FPM salen con SIGSEGV o SIGBUS (es decir, se bloquean) en 1 minuto, se supone que PHP-FPM se reiniciará automáticamente. El niño procesa esperar 5 segundos para una reacción a las señales del maestro.

Esto debería mantener su grupo de hilos de trabajo PHP agradables, frescos y limpios. Cuanto más tiempo se le permita a un trabajador presentar solicitudes, más inestable se volverá. También hay un mayor riesgo de pérdidas de memoria.

Aquí hay una buena descripción de todas las opciones de configuración que mencioné aquí, así como otras: http://myjeeva.com/php-fpm-configuration-101.html

Espero que estos consejos te ayuden! Recuerde ajustar y observar, desafortunadamente no parece haber una regla general para todo esto, hay demasiadas variables que afectan el comportamiento y la estabilidad de PHP.