Cómo analizar correctamente el «slowlog» de PHP-FPM: cómo detectar con seguridad los cuellos de botella en el rendimiento

Te voy a enseñar cómo... Registro de operaciones lentas de PHP-FPM analizas de forma específica, interpretas correctamente los backtraces y deduces a partir de ellos pasos claros para reducir la latencia. De este modo, podrás detectar de forma fiable los cuellos de botella en el rendimiento, priorizar las medidas y acelerar de forma perceptible los tiempos de carga para los usuarios.

Puntos centrales

• Backtrace Leer: El marco #0 muestra la pastilla de freno actual.
• Tiempo de espera Opciones: empezar por un nivel alto y luego ir bajándolo poco a poco.
• Correlación Con el registro de acceso: identificar con seguridad las URL lentas.
• Muestra Contar: dar prioridad a las funciones recurrentes.
• Correcciones en el código Derivar: abordar de forma específica las bases de datos, las API, los bucles y los complementos.

¿Qué es el «slowlog» de PHP-FPM?

El Slowlog registra, para las solicitudes largas, un Backtrace en un archivo de registro y, de este modo, registra el punto de ejecución actual sin interrumpir la solicitud. Así puedo identificar de inmediato qué script, qué URL y qué función están bloqueando el proceso. Las entradas incluyen la marca de tiempo, el pool, el nombre del archivo del script, la URI de la solicitud y la cadena de llamadas a funciones. Esto diferencia claramente el slowlog de los registros de errores clásicos, ya que documenta el rendimiento, no los errores. En el caso de páginas con gran carga, como los backends de WordPress, proporciona indicaciones rápidamente aprovechables sobre consultas costosas, renderizados excesivos u operaciones de E/S que provocan bloqueos. Quien comprenda estas instantáneas podrá resolver muy rápidamente los Causa principal delimitar y planificar medidas.

Así funciona el Slowlog en el día a día

Una vez activado, PHP-FPM registra un Instantánea de la pila en el registro, mientras la solicitud sigue en curso. Cada entrada suele comenzar por „#0“, es decir, en el punto en el que se está perdiendo tiempo. Entre los bloques suelo detectar líneas en blanco, lo que facilita la separación de los eventos. Este método proporciona muestras aleatorias en lugar de perfiles completos, pero a cambio ofrece indicaciones precisas sobre los verdaderos cuellos de botella, como rutas de plantillas complejas, hooks huérfanos o llamadas de red lentas. En fases de gran actividad, relaciono estas indicaciones con los picos de carga y, de este modo, clasifico claramente los fragmentos de código. En cuanto detecto patrones recurrentes, ajusto, por ejemplo, pm.max_hijos y utiliza para ello la información de Configurar correctamente el valor de pm.max_children.

Activar y configurar Slowlog

Activo la función en el pool correspondiente y configuro la ruta, el tiempo de espera y la profundidad del rastreo, para que la Evaluación siga siendo manejable. A continuación, reinicio PHP-FPM y compruebo si el archivo de registro es escribible con los permisos del usuario del pool. Como valor inicial suelo establecer 5 segundos, para detectar primero los picos más evidentes sin saturar el sistema con datos de registro. A continuación, reduzco el valor gradualmente, una vez que se han solucionado los problemas más graves. Para que los registros sean manejables, limito la profundidad de rastreo a entre 20 y 30 fotogramas, lo que suele ser suficiente en la práctica. De este modo, mantengo la Tamaño del archivo bajo control y no me pierda ningún detalle relevante.

Configuración	Propósito	valor inicial	Notas
slowlog	Ruta al archivo de registro	/var/log/php-fpm/www-slow.log	Comprueba las rutas según la distribución; derechos de escritura para www-data garantizar
request_slowlog_timeout	Umbral para „lento“	5 s	Empezar fuerte y luego... bajar (p. ej., 2-3 s)
request_slowlog_trace_depth	Profundidad máxima del backtrace	20–30	Mantén las trazas legibles, sin Información esencial perder

Encontrar el archivo de registro y revisarlo rápidamente

Primero compruebo las rutas configuradas y abro el archivo de registro con menos o comprueba las últimas líneas con tail -40. Así puedo ver de inmediato si llegan entradas y qué scripts se repiten con frecuencia. Para orientarme rápidamente, presto atención a los nombres de los archivos, los pools afectados y las URI que llaman la atención. Si no encuentro entradas, activo las opciones del grupo, recargo el servicio y compruebo los propietarios y los derechos. En entornos gestionados, además, consulto el panel o los scripts de inicio para asegurarme de que el slowlog realmente se mueve al mismo tiempo.

Reconocer bloques y contar patrones

Cada entrada aparece como un bloque, a menudo separada por una Línea en blanco, lo que facilita el recuento. Me guío por las líneas „#0“, ya que marcan el punto de ejecución actual en el que se pierde tiempo. Mediante sencillas tuberías de shell, filtro las funciones principales y veo qué puntos ralentizan el proceso con mayor frecuencia. De este modo, priorizo de forma específica las funciones que, en conjunto, consumen más tiempo. A continuación, compruebo si estos puntos críticos solo se producen en picos de carga o si causan problemas de forma constante. Esta clasificación determina la Secuencia mis medidas.

Leer entradas: desde el fotograma #0 hasta el inicio

Al leer las entradas, empiezo por la primera, que está arriba, en #0 y voy bajando paso a paso para entender el recorrido desde el punto de entrada hasta la posición actual. Las cadenas largas de plantillas indican un renderizado complejo, muchos hooks apuntan a un exceso de plugins y una alta proporción de SQL sugiere la falta de índices. Anoto los números de línea, los nombres de las funciones y las rutas de los archivos para poder encontrar el código rápidamente. Si la pila parece contener bucles de espera u operaciones repetidas, compruebo la memoria intermedia y el almacenamiento en caché. Así no pierdo tiempo en la Localización del problema en el código.

Correlacionar el slowlog con los registros de acceso

Vinculo el Slowlog con los registros del servidor web para poder identificar las peticiones lentas de una URL puedo asignar. Mediante las marcas de tiempo y, opcionalmente, los PID, encuentro las entradas correspondientes en los registros de Nginx o Apache. De este modo, identifico parámetros, agentes de usuario y tiempos de respuesta fuera de PHP. Si aparecen visitantes recurrentes o cadenas de consulta idénticas, inicio una prueba con precisamente esos escenarios. De este modo, encuentro rápidamente casos reproducibles y mantengo la Tiempo de análisis En resumen.

Reducir el valor umbral de forma iterativa

Empiezo con un umbral generoso y, en primer lugar, soluciono los problemas más graves Valores atípicos y luego lo reduzco por etapas. Este proceso reduce el volumen de registros y canaliza mi energía hacia las correcciones que realmente merecen la pena. Tras cada ronda de optimización, elijo un umbral más bajo y vuelvo a recopilar registros. De este modo, voy avanzando desde un ajuste general hasta un ajuste fino, sin perderme en el ruido. El resultado son ajustes específicos y una borrar Visión general de los cuellos de botella restantes.

Del «slowlog» a la solución: soluciones típicas

Si el marco superior muestra funciones de la base de datos, compruebo las sentencias SQL con EXPLICAR, añado los índices que faltan y limito los conjuntos de resultados. En el caso de los servicios remotos, reduzco los tiempos de espera, proceso las respuestas de forma asíncrona o almaceno los resultados en caché. Si encuentro bucles que consumen muchos recursos, simplifico la lógica, reduzco el número de pasadas y utilizo estructuras más eficientes. En WordPress, identifico los hooks recurrentes, sustituyo las extensiones pesadas y opto por un tema más ligero. Si el número de procesos PHP bloquea la ejecución, vigilo los tiempos de espera y, como complemento a Trazas de retroceso también las colas, por ejemplo, a través de Cola de solicitudes de PHP.

Funcionamiento continuo: gestión eficaz de los registros

No mantengo el registro al máximo de forma permanente, para que el Carga de E/S se mantenga bajo control. En su lugar, trabajo por fases: evalúo activamente, optimizo y luego vuelvo a un nivel moderado. Con Logrotate mantengo los archivos ligeros y archivo los datos antiguos comprimidos. Una vez finalizado un análisis, elevo el umbral o desactivo temporalmente el slowlogging. Además, documento las conclusiones y las correcciones para que las auditorías posteriores tengan una visión clara huella encontrar.

Diagnóstico de alojamiento: diferenciar entre el servidor y la aplicación

La presencia de muchos fotogramas Slowlog idénticos con una elevada carga de la CPU apunta a Código de aplicación, mientras que la ausencia de entradas en el lado del servidor suele indicar problemas de E/S, de red o del servidor de la base de datos. En esos casos, comparo el TTFB, los tiempos de PHP y la latencia de upstream para localizar el cuello de botella. Si observo colas y tiempos de espera elevados antes de la ejecución, compruebo los límites y el número de procesos. Para ello, complemento mi diagnóstico con información sobre la tramitación de las solicitudes y tengo en cuenta los posibles límites que ralentizan el procesamiento. Para obtener una valoración fundamentada, además de los registros, consulto también las indicaciones sobre Configurar correctamente el valor de pm.max_children o artículos relacionados con los tiempos de espera, para que pueda... Capacidad lo coordine de forma adecuada.

Ejemplo práctico: backend de WordPress lento

He puesto request_slowlog_timeout En primer lugar, lo configuro en 5 segundos, reinicio PHP-FPM y recopilo datos durante entre 30 y 60 minutos bajo carga real. A continuación, cuento las funciones „#0“ más frecuentes y busco hooks recurrentes o llamadas costosas a WP_Query. Si intervienen servicios externos, mido los tiempos de respuesta y almaceno en caché los resultados de forma selectiva. Si las visitas a las páginas se ven ralentizadas por accesos de sesión, compruebo el comportamiento de bloqueo y, si es posible, elimino del camino crítico las tareas relacionadas con la sesión. Especialmente en el caso de los inicios de sesión y las acciones de administración, pruebo la configuración y desactivo las notificaciones. Bloqueo de sesión PHP para que mi Backend reacciona más rápido.

Diseño de la base de datos y derechos: una base sólida para obtener «slowlogs» aprovechables

Separo las aplicaciones en sus propias piscinas con nombres claros (por ejemplo, www, admin, api), establece escuchar-Zócalos y personalizados slowlog-Rutas. Así me resulta más fácil relacionar las entradas y evito que se mezclen. Es importante que sean coherentes Derechos de archivo: El usuario del pool (a menudo www-data) necesita permisos de escritura en la ruta de los registros y en el directorio. En configuraciones con contenedores o chroot, compruebo si las rutas existen en el espacio de nombres y si son persistentes; de lo contrario, los registros desaparecerán al reiniciar el sistema.

Leer un bloque de Slowlog en detalle y analizarlo automáticamente

Normalmente, las entradas comienzan con la marca de tiempo, el pool, el nombre del archivo de script y el URI de la solicitud, seguidos de los fotogramas. Cuento las líneas „#0“ y las agrupo por nombre de función para identificar los puntos críticos. Con sencillas tuberías extraigo los «frenos»:

grep -E "^#0|request.uri|script_filename" /var/log/php-fpm/www-slow.log | sed 's/  */ /g'

O bien, voy a enumerar los fotogramas más frecuentes:

grep "^#0" /var/log/php-fpm/www-slow.log | awk -F": " '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head

Si quiero incluir la URL y el archivo, preparo los bloques mediante awk y anota las combinaciones más importantes de función, URI y script. Así es como priorizo las correcciones que aportan más beneficios.

Mapa de tiempos de espera: cómo interactúan Slowlog, PHP y el servidor web

Para establecer un diagnóstico preciso, prescribo todos Tiempos de espera: request_slowlog_timeout activa la instantánea, tiempo_de_ejecución_máximo limita el tiempo de ejecución de PHP en el script, request_terminate_timeout puede cerrar el FPM-Worker de forma forzada. En el lado del servidor web, se aplican fastcgi– o bien. proxy-Tiempos de espera (p. ej.,. fastcgi_read_timeout) y los tiempos de espera del cliente. Si configuro el slowlog por encima Si se agota el tiempo de espera del servidor, se pierden datos; si se agota entre ellos, obtengo instantáneas útiles antes de que se interrumpan las solicitudes. Por eso mantengo este orden a propósito: tiempo de espera del servidor web > finalización de PHP > slowlog > latencia del destino.

Incorporar el estado de FPM, la cola y la gestión de procesos

El Slowlog muestra que, donde Se está malgastando tiempo: el estado del FPM revela que, por qué Hay solicitudes en espera. Activo el punto final de estado y observo inactivo, activo y cola de escucha y lo comparo con las marcas de tiempo del slowlog. Si la cola crece mientras muchos trabajadores se quedan atascados en las mismas funciones, el cuello de botella está en el código; si la cola aumenta sin que crezca el slowlog, es que falta capacidad o hay un obstáculo en la fase anterior. Partiendo de ahí, ajusto pm-Configuración (dinámica/bajo demanda), pm.max_hijos y, si procede,. pm.max_requests, para detectar fugas de memoria o fragmentación.

Características especiales en contenedores y entornos gestionados

En Docker/Kubernetes, FPM suele registrar los mensajes en stdout/stderr o en rutas que recogen los agregadores de registros. Me decanto deliberadamente por un a Eliminarlas, para que no haya entradas duplicadas ni que falten. Con error_log = /proc/self/fd/2 y un slowlog-En las rutas que apuntan a un volumen persistente, las instantáneas siguen estando disponibles. En entornos gestionados, compruebo si el proveedor de alojamiento tiene activados o restringidos los registros de actividad (slowlogs) y ajusto los intervalos para no entrar en conflicto con las rotaciones.

Protección de datos y seguridad: registros sin riesgo

Los backtraces pueden contener información confidencial Parámetros, que contengan rutas de archivos o identificadores de sesión. Minimizo los riesgos guardando las cadenas de consulta en los registros de acceso, desactivando las salidas de depuración en el código y limitando al mínimo el número de personas con permiso de lectura. Para el intercambio con terceros, anonimizo las rutas y elimino los tokens. En entornos de producción, establezco plazos de conservación breves y aplico la rotación y la compresión de registros en todo el sistema.

WordPress: cómo detectar rápidamente patrones recurrentes

• WP_Query/WP_Meta_Query: Faltan índices en postmeta O bien, si se filtra por campos no indexados, el tiempo de ejecución se dispara. Reduzco las metaconsultas, utilizo taxonomías o creo índices específicos.
• Transitorios y caché de objetos: Muchos cálculos similares apuntan a la falta de una caché persistente. Activo la caché de objetos y optimizo las claves de caché y los TTL.
• Hooks/Filtros: Las cadenas largas en la pila indican que hay plugins innecesarios. Analizo los hooks más pesados y elimino o sustituyo extensiones.
• Peticiones HTTP: Las llamadas internas a la API (wp_remote_get) deben utilizar tiempos de espera, keep-alive y almacenamiento en caché; si es posible, las respuestas no deben bloquear el hilo de la solicitud.
• Representación de plantillas: Profundidad get_template_part- Las cascadas con accesos a archivos se benefician del almacenamiento en caché y de una menor fragmentación.

Evitar malinterpretaciones: lo que el Slowlog no muestra

La instantánea es una Instantánea. No describe toda la duración de la solicitud, sino su estado en el momento en que se activa. Errores habituales:

• Sesgo de muestreo: Las rutas poco frecuentes, pero extremadamente caras, pueden perderse si el tiempo de espera es demasiado corto o si la fase ha sido breve.
• Llamadas al sistema que bloquean: fopen, stat o las consultas DNS aparecen como funciones de PHP, pero el tiempo de espera real se produce en el núcleo o en la red.
• Carga automática: Muchos archivos «include» pequeños sin Opcache provocan pérdidas dispersas que parecen inofensivas en la pila. Echar un vistazo a la tasa de aciertos de Opcache ayuda a valorarlo.

No perder de vista CLI, Cron y los webhooks

No todos los problemas de rendimiento se gestionan a través de FPM. Los más pesados Cronjobs (por ejemplo, wp-cron), los procesadores de colas o los webhooks bloquean la CPU, las E/S o la base de datos y, por lo tanto, empeoran indirectamente los tiempos de respuesta. Aíslo esa carga en procesos independientes, la programo fuera de las horas punta y compruebo si se ejecuta a través de HTTP activado por FPM en lugar de la CLI; de lo contrario, se distorsiona la visión del slowlog.

Cómo aplicar la rotación de registros en la práctica

Para evitar que los slowlogs se acumulen, los renuevo con frecuencia y comprimo los registros antiguos. Una rotación típica conserva unas pocas generaciones, indica a FPM que vuelva a abrirse y evita que se produzcan lagunas. Importante: tras la rotación, hay que hacer que FPM se vuelva a abrir (HUP), para que las nuevas entradas no se pierdan en el limbo. Ajusto la configuración concreta en función del tráfico, el tiempo de espera y la profundidad de rastreo.

Lista de comprobación para obtener resultados rápidos

• Activar Slowlog por grupo, comprobar rutas y permisos.
• Empezar con 5 s, recopilar entradas y contar los fotogramas más importantes.
• Correlacionar con los registros de acceso: marca de tiempo, URI, agente de usuario.
• Comprueba los tiempos de espera del servidor de origen y del servidor web.
• Supervisar el estado de FPM y la cola, pm-Ajustar los límites.
• Solucionar primero los puntos críticos: índices SQL, almacenamiento en caché, hooks costosos, E/S.
• Reducir el tiempo de espera gradualmente y volver a medir.
• Rotar los registros, documentar los hallazgos y realizar un seguimiento de los cambios.

En resumen: tu camino hacia un mejor rendimiento

Activo el Slowlog, leo el Marcos destacados, lo correlaciono con los registros de acceso y soluciono primero los valores atípicos más importantes. A continuación, reduzco el umbral, compruebo los patrones recurrentes y aplico correcciones específicas en el código, la configuración y el almacenamiento en caché. Con la rotación de registros y tiempos de espera moderados, mantengo baja la carga operativa. En el caso de WordPress, me centro en las consultas costosas, los plugins, los hooks y los posibles bloqueos de sesión. Así es como identifico de forma fiable los verdaderos Cuellos de botella y ofrece respuestas notablemente más rápidas.