Ir al contenido 
La carga desigual de la CPU en WordPress suele deberse a una mala configuración. Tareas programadas de WordPress, que se inician como procesos en segundo plano cada vez que se carga una página y provocan picos. Te mostraré cómo estos disparadores prolongan el TTFB, ocupan los trabajadores PHP y generan latencias, y cómo puedes volver a más uniforme Último.
Puntos centrales
El siguiente resumen resume los aspectos más importantes antes de profundizar y explicar los pasos concretos. Mantengo la lista breve para centrarme en lo siguiente: Acción y efecto.
- WP-Cron Se activa al abrir páginas y genera una carga impredecible.
- Procesos PHP se acumulan en el tráfico y ralentizan el TTFB.
- Cron del sistema Desvincula las tareas del flujo de visitantes.
- Intervalos y las prioridades suavizan los picos de CPU.
- Monitoreo Detecta cuellos de botella y eventos defectuosos.
Qué hacen realmente las tareas programadas de WordPress y de dónde proviene la carga
WordPress utiliza un sistema pseudo-cron: cuando se ejecuta, wp-cron.php se activa mediante POST, comprueba los eventos pendientes e inicia tareas como publicaciones, comprobaciones de actualizaciones, guardado de borradores a través de Heartbeat y limpieza de la base de datos; cada evento cuesta tiempo de CPU. Este enfoque parece cómodo, pero provoca desencadenantes incontrolables, ya que son las visitas las que determinan la ejecución y no un temporizador planificable. Cuando se producen varias llamadas al mismo tiempo, se inician procesos PHP paralelos que compiten por los trabajadores. Las configuraciones multisitio refuerzan el efecto, ya que cada subsitio mantiene su propia pila de eventos, lo que aumenta el número de comprobaciones [1]. Si desea profundizar en las relaciones, encontrará información básica fundamentada en Entender WP-Cron, pero el mensaje principal sigue siendo el mismo: la gestión de visitantes no es una herramienta fiable. generador de impulsos.
El verdadero freno: procesos PHP paralelos a través de wp-cron.php
Cada activador cron inicia un proceso PHP independiente que vincula un trabajador y, por lo tanto, la disponibilidad tiempo de cálculo para renderizaciones de páginas reales. Si se acumulan los disparadores, aumenta el tiempo de espera hasta que se libera un trabajador, se prolonga el TTFB y el primer byte llega más tarde al navegador [2]. Las mediciones mostraron un retraso de hasta 800 milisegundos, lo que afecta a Core Web Vitals y reduce la visibilidad orgánica [3]. El alojamiento compartido o los ajustes PHP-FPM ajustados agravan el efecto, ya que se alcanza rápidamente el max_children y los procesos terminan en colas. Especialmente durante los picos de tráfico de la tienda o las campañas, esto puede convertirse en un círculo vicioso: más tráfico genera más comprobaciones cron, que a su vez bloquean la representación y, por lo tanto, Tiempos de carga estirar [1][2].
Tratar correctamente el almacenamiento en caché, la CDN y las trampas de bucle invertido
WP-Cron utiliza por defecto un Solicitud de bucle invertido en el propio dominio. Si hay una caché de página agresiva, una CDN o un bloqueo de autenticación básica, la llamada puede fallar o esperar: las ejecuciones de cron se atascan, se repiten y, por lo tanto, prolongan la vinculación de la CPU. Por lo tanto, me aseguro de que /wp-cron.php no está almacenado en caché, no tiene límite de velocidad y es accesible internamente. El cron del sistema mitiga esta vulnerabilidad porque sin HTTP-Loopback ejecuta PHP directamente. Si hay un proxy conectado, compruebo además si las solicitudes a 127.0.0.1 se transfieran correctamente y ninguna regla WAF bloquee el punto final. En las fases de mantenimiento es importante: o bien pausar deliberadamente Cron, o bien dejar pasar explícitamente el punto final para que las tareas pendientes no se „acumulen“ como paquete.
Detectar y clasificar cargas irregulares de la CPU
Lo habitual son picos de carga en horas punta, que no se explican solo por el número de visitantes, sino por oleadas de eventos atrasados que se acumulan y se activan al mismo tiempo. Las instalaciones multisitio multiplican la carga, ya que cada subsitio gestiona listas cron y se comprueba al visitarlo, lo que da lugar a picos breves pero intensos que se muestran en los archivos de registro como cascadas de wp-cron.php-POSTs [1]. A menudo, los plugins registran sus propios eventos con intervalos demasiado cortos, a veces cada cinco minutos o incluso más a menudo, lo que con diez plugins se suma rápidamente a docenas de comprobaciones por cada llamada. Presta además atención a tu Límite de trabajadores PHP, ya que los trabajadores llenos provocan tiempos de espera que los usuarios notan directamente. Quien lee estos patrones entiende la curva irregular como consecuencia de los desencadenantes, no como algo inevitable. humor del tráfico.
Por qué System Cron aligera la carga
Un cron del sistema auténtico desacopla las tareas del flujo de visitantes y establece un ritmo claro, por ejemplo, cada cinco minutos, cada hora o cada día, lo que permite planificar la ejecución y distribuir la carga de forma uniforme [1][6]. Los visitantes ya no activan tareas cron, lo que alivia la TTFB y da prioridad al renderizado. Incluso con poco tráfico, las tareas se ejecutan de forma fiable porque el servidor las lleva a cabo aunque nadie visite la página. Esto ayuda a que las actualizaciones, los correos electrónicos o los pings de índice se ejecuten a tiempo y evita que los eventos „se queden pendientes“ y se disparen más tarde como un paquete. Así es como creo una carga del sistema, que no varía según el estado de ánimo del tráfico.
Paso a paso: desactivar WP-Cron y configurar System-Cron
Empiezo por desactivar el disparador interno en wp-config.php, para que ninguna visita a la página active tareas cron. Para ello, añado la siguiente línea y guardo el archivo, para que WordPress no active ninguna comprobación cron durante el renderizado. A continuación, configuro una regla crontab limpia que activa wp-cron.php cíclicamente sin generar salida innecesaria. De este modo, la tarea se ejecuta de forma programada y alivia constantemente las visitas a la página. El resultado: el renderizado tiene prioridad, las tareas cron tienen su propia sincronización.
// wp-config.php define('DISABLE_WP_CRON', true);
# Ejemplo de crontab (cada 5 minutos) */5 * * * * php -q /var/www/html/wp-cron.php > /dev/null 2>&1
WP-CLI en lugar de llamada directa a PHP
Para un mejor control, me gusta configurar la ejecución de cron mediante WP-CLI . De este modo, puedo ejecutar „solo“ los eventos vencidos, registrar con más detalle y procesar multisitios de forma específica. Además, un bloqueo evita que se inicien varias ejecuciones en paralelo.
# WP-CLI: solo procesar eventos vencidos */5 * * * * /usr/local/bin/wp cron event run --due-now --path=/var/www/html --quiet
# Con bloqueo simple mediante flock (recomendado) */5 * * * * flock -n /tmp/wp-cron.lock /usr/local/bin/wp cron event run --due-now --path=/var/www/html --quiet
En entornos multisitio, puedo hacerlo mediante --url= Revisar sitio por sitio o hacer rotar los sitios mediante un pequeño bucle de shell. Esto evita que 100 subsitios alcancen el mismo ritmo al mismo tiempo y generen picos de carga.
Intervalos y prioridades: qué tareas deben ejecutarse y cuándo
No todas las tareas requieren una sincronización minuciosa; las clasifico según su relevancia y coste, de modo que las tareas críticas para el SEO tengan prioridad y las tareas costosas se trasladen a horas secundarias [1]. Me centro en la creación de mapas del sitio, los pings de indexación y el calentamiento de la caché, seguidos del mantenimiento de la base de datos y la eliminación de transitorios. Planifico las copias de seguridad en franjas horarias nocturnas y elijo procedimientos incrementales para evitar picos de E/S. Agrupo las colas de boletines informativos o importadores y los ejecuto en franjas horarias fijas, en lugar de comprobarlos cada vez que se visita la página. Este orden garantiza unas prioridades claras y evita que los intervalos de sondeo cortos CPU obstruir.
| Tarea | Intervalo recomendado | Impacto en la CPU | Nota |
|---|---|---|---|
| Mapa del sitio/Indexación de pings | cada hora hasta 1 vez al día | bajo | Relevante para el SEO; antes del calentamiento de la caché dar prioridad |
| Calentamiento de caché | 1-2 veces al día | medio | Escalonar las URL, no realizar análisis completos en horas punta. |
| Copias de seguridad | por la noche | alta | Incremental; destino remoto con límite de ancho de banda |
| Limpieza de la base de datos | diariamente o semanalmente | medio | Revisiones/transitorios en bloques borrar |
| Notificaciones por correo electrónico | cada hora/1 vez al día | bajo | Crear lotes, utilizar la cola |
Mecanismos de ejecución única y bloqueos limpios
Para evitar que las ejecuciones de Cron se solapen, además de flock también las restricciones propias de WordPress. WP_CRON_LOCK_TIMEOUT define cuánto tiempo permanece exclusiva una ejecución. Si la página es lenta o hay trabajos largos, aumento el valor moderadamente para que no se inicie un segundo proceso antes de tiempo. Por el contrario, lo reduzco si los trabajos son cortos y no quiero que un bloqueo provoque una cascada.
// wp-config.php – Tiempo de bloqueo en segundos (por defecto 60) define('WP_CRON_LOCK_TIMEOUT', 120);
Además, limito deliberadamente la paralelidad en los plugins (tamaños de lotes, longitudes de paso, pausas entre solicitudes). De este modo, evito que una ejecución cron genere a su vez docenas de procesos PHP y aumente la curva de carga.
Monitorización y análisis: hacer visibles los cuellos de botella
Empiezo por los registros de acceso y filtro las solicitudes POST en wp-cron.php para detectar la frecuencia y los intervalos de tiempo; muchos intervalos cortos indican intervalos estrechos o eventos bloqueantes. Al mismo tiempo, compruebo los registros de errores en busca de tiempos de espera, bloqueos y tiempos de espera de la base de datos que afectan a las tareas cron. En el backend, WP Crontrol proporciona información sobre los eventos registrados, sus ganchos y los tiempos de ejecución previstos; allí elimino las entradas obsoletas o pendientes. Para obtener una visión más detallada de las transacciones, los tiempos de consulta y las colas PHP-FPM, utilizo Herramientas APM para WordPress para aislar los puntos críticos. De este modo, encuentro las causas, en lugar de limitarme a mitigar los síntomas, y puedo actuar de forma específica. Medidas dar prioridad.
Objetivos medibles y prueba rápida en 10 minutos
Defino valores objetivo claros: TTFB p95 para páginas almacenadas en caché por debajo de 200-300 ms, para páginas no almacenadas en caché por debajo de 800 ms; cola PHP-FPM permanentemente cercana a 0; CPU sin picos que alcancen la saturación. La prueba rápida: desactivar WP-Cron, configurar System-Cron, procesar los eventos pendientes una sola vez mediante WP-CLI y, a continuación, comprobar los registros. En 10 minutos verás si el TTFB disminuye, si la cola PHP se reduce y si los hooks llamativos (por ejemplo, comprobaciones de actualizaciones, importadores) son los principales responsables. A continuación, ajusta los intervalos, los tamaños de los lotes y la frecuencia hasta que las curvas se estabilicen.
Domesticar la API Heartbeat y los eventos de complementos
El mecanismo Heartbeat actualiza sesiones y borradores, pero a menudo genera solicitudes innecesarias en el frontend; lo limito a las áreas de administración o establezco intervalos adecuados. Muchos plugins registran tareas cron con valores predeterminados que tienen una frecuencia demasiado alta; en este caso, cambio a intervalos más largos y traslado las tareas a horas de menor actividad. En las configuraciones de la tienda, limito las fuentes de inventario y las sincronizaciones de precios a franjas horarias fijas, en lugar de realizar sondeos cada minuto. Para las fuentes y el calentamiento de la caché, utilizo listas por lotes para que no se ejecuten todas las URL de una sola vez. Estas intervenciones reducen la frecuencia de las solicitudes y suavizan el curva claramente.
Escalabilidad: de tareas programadas a colas y trabajadores
Cuando hay mucho tráfico, mantengo WP-Cron lo más pequeño posible y traslado las tareas que requieren mucho cálculo a colas con trabajadores dedicados. Las colas de trabajo distribuyen la carga entre varios procesos, se pueden ampliar horizontalmente y evitan que el frontend tenga que esperar. En configuraciones de contenedores u orquestación, escalo los trabajadores independientemente de PHP-FPM, lo que proporciona recursos separados para el renderizado y el trabajo en segundo plano. Las colas son especialmente útiles para importaciones, procesamiento de imágenes, lotes de boletines informativos y sincronizaciones de API. De este modo, el frontend sigue siendo receptivo, mientras que los trabajos en segundo plano se controlan y planificable correr.
WooCommerce, Action Scheduler y colas grandes
WooCommerce ofrece con el Programador de acciones una cola propia que procesa los correos electrónicos de pedidos, webhooks, suscripciones y sincronizaciones. Es precisamente aquí donde se producen picos de CPU cuando hay miles de acciones „pendientes“. No dejo que el runner se ejecute al abrir la página, sino que lo activo a través de System Cron o WP-CLI en ventanas fijas. Configuré los tamaños de los lotes y la paralelidad de manera que una ejecución no bloquee la base de datos y los trabajadores PHP-FPM permanezcan libres. Distribuyo los importadores, la regeneración de imágenes y los picos de webhooks en varias pequeñas ejecuciones; prefiero 10 veces brevemente que 1 vez durante horas con bloqueos de E/S.
Especificaciones multisitio: equilibrar la sincronización por sitio
En configuraciones multisitio, la carga se acumula porque cada sitio tiene su propia lista de eventos. En lugar de comprobarlo todo cada cinco minutos, roto los sitios: grupos de sitios con ritmos ligeramente desplazados, para que no todas las listas cron se ejecuten al mismo tiempo. Los sitios muy activos reciben una ranura en la cola con más frecuencia, mientras que los sitios tranquilos la reciben con menos frecuencia. El resultado es una curva de CPU más uniforme y menos competencia por los trabajadores, con el mismo trabajo total.
Comprobación práctica: configuración sin obstáculos
Primero compruebo si DISABLE_WP_CRON está correctamente configurado, ya que los disparadores duplicados (internos + externos) agravan los picos de carga. A continuación, compruebo el crontab: ruta correcta, sin salida innecesaria, intervalo razonable y sin solapamientos con ventanas de copia de seguridad. En WP Crontrol, limpio los hooks obsoletos y cambio los intervalos cortos a ciclos realistas. Adapto la configuración de PHP-FPM al perfil de los visitantes para que los trabajadores de PHP no se queden constantemente en el límite superior. Por último, hago un seguimiento del TTFB, los tiempos de respuesta y la CPU para evaluar claramente el efecto de los cambios. Tarifa.
Dimensionar adecuadamente PHP-FPM, OPCache y los límites de tiempo
La mejor estrategia Cron se esfuma si PHP-FPM es demasiado pequeño o está mal sincronizado. Yo elijo pm=dinámico o pm=bajo demanda dependiendo del perfil de tráfico y redirigir pm.max_hijos del presupuesto real de RAM: como regla general, RAM_para_PHP / consumo medio de scripts. Ejemplo: un presupuesto de 2 GB y ~128 MB por proceso dan como resultado ~16 trabajadores. pm.max_requests Lo pongo en un nivel moderado (500-1000) para evitar fugas. request_terminate_timeout limita los trabajos atípicos; un limpio slowlog Detecta bucles de consulta y tiempos de espera externos. Un OPCache saludable (suficiente archivos_acelerados_máximos, consumo_memoria, interned_strings_buffer) evita los arranques en frío y ahorra CPU por solicitud, incluso para las ejecuciones cron.
Caché de objetos y limpieza de opciones
Una caché de objetos persistente (por ejemplo, Redis/Memcached) reduce significativamente la presión sobre la base de datos para las comprobaciones cron. Es importante que la higiene en el wp_opcionesTabla: La opción cron no debe superar varios megabytes, ya que, de lo contrario, cada comprobación resultará costosa. Elimino los eventos obsoletos o pendientes, reduzco la basura de autoload y desactivo las opciones grandes que se utilizan con poca frecuencia. autoload = no. De este modo, se reducen los tiempos de consulta y las listas cron se pueden evaluar más rápidamente.
Ajuste fino: ritmo, secuencia y límites de recursos
Para los sitios web con picos por la mañana, programo el calentamiento de la caché a primera hora de la noche y ejecuto los mapas del sitio justo antes del horario comercial, para que los rastreadores vean datos actualizados. Divido las costosas limpiezas de bases de datos en bloques más pequeños para reducir los tiempos de bloqueo y evitar picos de consultas. Las exportaciones grandes las programo para el fin de semana, cuando hay menos interacción. Cuando es conveniente, limito los trabajos paralelos para que no haya varios procesos cron-php compitiendo por la E/S al mismo tiempo. Este ajuste fino garantiza un rendimiento uniforme y una mejor Tiempos de respuesta.
Seguridad: proteger wp-cron.php contra accesos externos
Como Cron debe activarse internamente, bloqueo el acceso externo directo a /wp-cron.php. Así evitarás abusos, ataques DDoS y llamadas externas accidentales. Permite solo llamadas locales (loopback o CLI) y bloquea todo lo demás. Esto reduce el ruido en los registros y protege a los trabajadores PHP.
# Ejemplo de Nginx location = /wp-cron.php { allow 127.0.0.1; deny all; include fastcgi_params; fastcgi_pass php-fpm; }
# Ejemplo Apache Require ip 127.0.0.1
Causas frecuentes de la carga „fantasma“ por Cron
Los intervalos muy cortos (1-5 minutos) para tareas no críticas son uno de los mayores factores que aumentan la carga, especialmente en combinación con muchos complementos. Los eventos pendientes, que se reprograman una y otra vez debido a ejecuciones fallidas, generan bucles que inundan los registros. Los problemas de bloqueo en la base de datos obligan a las tareas cron a ejecutarse durante más tiempo, lo que aumenta las superposiciones. Además, los bloqueos HTTP (por ejemplo, DNS o API remota) pueden prolongar artificialmente las ejecuciones cron y ocupar trabajadores. Conocer estos patrones ahorra mucho tiempo en la búsqueda de la causa y reduce la Picos rápido.
Brevemente resumido
La carga irregular de la CPU en WordPress suele tener su origen en WP-Cron, que actúa como desencadenante cuando se visitan las páginas y ocupa los trabajadores PHP. Desactivo el desencadenante interno, configuro un cron del sistema, optimizo los intervalos y doy prioridad a las tareas relevantes para el SEO, de modo que el renderizado tenga prioridad. La supervisión con registros, WP Crontrol y análisis APM me muestra eventos defectuosos, ciclos cortos y procesos bloqueantes. Para proyectos grandes, traslado las tareas que requieren un gran esfuerzo de cálculo a colas para separar claramente las tareas frontend y las tareas en segundo plano. De esta forma se consigue una carga más uniforme, un TTFB más corto y una mejora notable. más rápido Entrega: sin picos inesperados.
