Procesos lsphp de LiteSpeed bloquean la página después de publicar un post (Solucionado)

Spoiler, era un DDoS

Llevo un tiempo lidiando con un problema para el cual aún no he encontrado una solución definitiva.

El asunto es que noté que justo después de publicar un post, el consumo de CPU se disparaba así como el número de procesos dejando el sitio prácticamente inaccesible durante largos periodos de tiempo. Sin embargo, esto sucede también en cualquier otro momento cuando no se está trabajando en la página.

Esto es una putada, ya que los suscriptores recibirán con el aviso de una nueva publicación que no no podrán leer porque la página no resuelve durante un tiempo. Sin hablar de lo que supone para el posicionamiento tener la página caída con frecuencia.

Pasado cierto tiempo, el sistema terminará matando los procesos y la página volverá a estar accesible, pero pueden pasar desde minutos a horas hasta que eso suceda, despendiendo del tráfico y de lo que sea que desencadene la acumulación de esos procesos

Si usas cPanel, se suele recibir un correo con un mensaje como este:

(Cron Daemon)
/bin/sh: line 1: 30255 Killed                  /usr/local/bin/php /home/usuario/public_html/wp-cron.php >> /home/usuario/public_html/wp-cron.log 2>&1

Teniendo DISABLE_WP_CRON activado en el wp-config.php, seguir recibiendo el mensaje de "Killed" desde cPanel, significa que hay algún otro proceso o configuración (que aún no he descubierto) que está intentando ejecutar wp-cron.php, y el sistema lo está terminando por exceso de consumo de recursos (memoria, CPU, etc.).

Hoy he vuelto a investigar un poco más y he estado monitorizando el consumo de CPU. Para ello, he recurrido al terminal en el navegador para acceso SSH y WP-CLI que ofrece LucusHost en cPanel.

Si tu hosting lo permite, para acceder debes acudir en cPanel a Avanzado/Terminal. Si los archivos de tu blog están en la carpeta public_html debes acceder así:

cd public_html

Después, para ver los procesos en ejecución escribe:

top

Y debes ver algo como esto:

En mi caso encuentro una avalancha de procesos lsphp que se comen por completo la CPU.

Basta abrir el área de administración de WordPress para que aparezcan cuatro cinco procesos de LiteSpeed (lsphp) que se van cerrando a los pocos segundos. Esto es algo normal, los procesos lsphp de LiteSpeed son parte de su arquitectura para gestionar conexiones PHP de forma eficiente.

Sin embargo, algo no está bien cuando, tras publicar un post nuevo (a veces basta con solo editar uno ya publicado), esos procesos se disparan tanto en número como en uso de CPU y se amontonan dejando el sitio muerto.

Procesos que no se pueden matar

La primera medida de urgencia para desbloquear la página sería matar esos procesos "atascados", lo que no soluciona el problema que provoca el atasco porque los procesos se regeneran. Además, como descubrí más tarde, no se pueden matar.

pkill -u TuNombreDeUsuario lsphp

Se puede intentar matar un proceso concreto usando su PID, aunque es más que probable que no te sirva de mucho ya que se cierran y abren muchos a intervalos cortos.

# Detiene procesos con alto %CPU (ejemplo para detener el PID 7026)
kill -9 7026

Esto tampoco no sirve de nada, ya que del top se supone que se desprende que la clave es el estado D: los procesos tienen el estado D (Disk sleep / Uninterruptible sleep). Este es, de momento, el síntoma más claro del problema. Un proceso en estado D no puede ser detenido ni por una señal kill -9. Significa que el proceso está esperando una operación de entrada/salida (I/O) que no se completa, como leer o escribir en el disco.

¿Cuello de botella?

Podría ser una señal de cuello de botella de E/S (entrada/salida). El servidor está atascado porque múltiples procesos lsphp están intentando acceder a un recurso (probablemente la base de datos o el disco) al mismo tiempo, y el sistema no puede procesar esas peticiones lo suficientemente rápido.

También he desactivado la purga desde la configuración del plugin para determinadas páginas no necesarias, pero esto tampoco solucionó nada.

Normalmente, por defecto, LiteSpeed ejecuta cada minuto estas cuatro tareas dependiendo de la configuración de su plugin y las opciones que estés usando.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

Las dos primeras, imgoptm_pull y ccss, son tareas pesadas que a veces provocan timeout (especialmente en hosting compartido), mientras que ucss y lqip son tareas más ligeras.

Así que lo primero que he probado es a bloquear la regeneración automática de LiteSpeed deshabilitando la gestión automática de Cron en LiteSpeed, para ello añadí esto en el wp-config.php

// Deshabilita la gestión automática de Cron en LiteSpeed
define('LITESPEED_DISABLE_CACHE_PURGE_CRON', true);
define('LITESPEED_DISABLE_AUTOUPDATE_CRON', true);

Ajustando tareas

Después, con la siguiente función añadida en el functions.php se fuerza la eliminación del intervalo de 1 minuto y se cambia a 1 vez al día distribuyendo estas tareas a distintas horas para evitar el consumo excesivo de CPU. Dependiendo del tráfico de tu blog, puedes fijar estas horas en distintas franjas de la madrugada, por ejemplo.

/**
 * Cambia la frecuencia de las tareas de LiteSpeed Cache de "cada minuto" a "una vez al día" a distintas horas".
 */
add_action('init', function() {
    // Eliminar el intervalo "litespeed_filter"
    add_filter('cron_schedules', function($schedules) {
        if (isset($schedules['litespeed_filter'])) {
            unset($schedules['litespeed_filter']);
        }
        return $schedules;
    }, 9999);

    // Reprogramar tareas con timestamps únicos
    $tasks = array(
        'litespeed_task_imgoptm_pull' => strtotime('tomorrow 00:30'),
        'litespeed_task_ccss'         => strtotime('today 20:00'),
        'litespeed_task_ucss'         => strtotime('tomorrow 00:00'),
        'litespeed_task_lqip'         => strtotime('tomorrow 04:00')
    );

    foreach ($tasks as $hook => $time) {
        if (wp_next_scheduled($hook)) {
            wp_unschedule_event(wp_next_scheduled($hook), $hook);
        }
        wp_schedule_event($time, 'daily', $hook);
    }
}, 9999);

Una vez aplicados estos cambios se comprueba que estén funcionando, según el plugin Advanced Database Cleaner Pro, se están aplicando estos cambios.

También puedes comprobarlo con Wp Crontrol.

Incluso con Wp Crontrol puedes hacer esto mismo, y mucho más fácil, editando la hora de programación de los eventos, pero tendrás que volver a instalar el plugin o volver a configurar las horas de ejecución cada vez que se pierdan.

Ya por probar, asumiendo que no estés usando el CRON nativo virtual de WordPress, para aligerar aún más el consumo de CPU se añade un nuevo CRON que aumenta la frecuencia a 30 minutos, evita duplicados con flock y reduce la carga del servidor.

*/30    *       *       *       * /usr/bin/flock -xn /tmp/wp-cron.lock /usr/local/bin/php /home/TuNombreDeUsuario/public_html/wp-cron.php > /dev/null 2>&1

Ahora, cuando ejecutamos wp cron schedule list ya encontramos que no aparece el filtro litespeed_filter , ni ningún otro para elegir que se ejecute cada 60 segundos.

Hay que tener en cuenta que estas tareas volverán a su estado original de 1 minuto si se desactiva y vuelve a activar LiteSpeed y aún sigo investigando la forma de impedirlo.

Esto es sólo un primer acercamiento. Ahora tengo que seguir probando y monitorizando el uso de recursos en distintos escenarios. Por si descubro algún patrón más, además del amontonamiento de procesos lsphp que provoca editar o publicar un nuevo post.

En mi caso, nada de lo que he probado ha conseguido solucionar el problema. Si alguien tiene el mismo problema y ha encontrado una solución definitiva se agradecerá el aviso o cualquier pista.

Actualización 22 de agosto 2025, recuperando caché perdido

Aunque no estoy seguro de si se ha solucionado por completo porque aún tengo que forzar más escenarios para poder verificarlo, creo que al menos estoy más cerca de solucionado. O al menos en el camino.

Di con una pista de pura casualidad, como suele suceder en muchas ocasiones. Una tarde tonta de verano, mientras optimizaba un par de post antiguos que estaban hechos unos zorros, descubrí que algunos (muchos) no se estaban cacheando. Al pie del código fuente aparecía el mensaje de "uncached".

Empecé a buscar un patrón en el código fuente entre las páginas que se cacheaban y las que no para intentar aislar la causa.

Tras comparar post con distintos bloques de Gutengerg y GenerateBlocks y mensajes de X y/o Bluesky incrustados y otros elementos, por descarte, ese ai_js al final de un tocho en el código fuente podía ser una pista válida de la que tirar.

AI apunta a que pertenece al código que genera el plugin Ad Inserter Pro en sus bloques insertados en el contenido. Así que revisé uno a uno todos los bloques y encontré que en uno que tenía el script de un anuncio de Adsense estaba marcada esta opción de "Desactivar caché", seguramente por error.

La cuestión es que con esa opción marcada se desactivaba el cacheo y las optimizaciones de LiteSpeed de cualquier página donde estuviera presente ese bloque. Bastó desmarcarla, purgar caché y todas esas páginas sin cachear se reconstruyeron con su correspondiente y necesario cacheo y sus optimizaciones de LiteSpeed.

Entiendo, o más bien especulo, que el plugin estaba solicitando el cacheo, pero ese bloque de Ad Inserter Pro lo impedía creando un bucle que hacía que se acumularan los procesos siempre que no se tratara de algo externo, claro. La cuestión es que el problema, de momento, parece que ya no es tan extremo.

Si bien aún algunos picos de procesos de vez en cuando (aunque muchos menos) y puede que el servidor ande corto para gestionarlos en según qué casos, ahora no impiden la carga de la página y finalizan mucho antes.

Mi gozo en un pozo, apenas un par de horas después. Volvió a petar a procesos lsphp. Sin que mediara acción alguna por mi parte. Hay que seguir buscando.

Ya que estaba en pleno furor optimizador, con la euforia de un posible triunfo, reorganicé los CRON de Matomo para segmentar las tareas pesadas y evitar peticiones gordas del archivo de informes (que ni quiero ni necesito). También rebajé el tiempo para eliminar los informes agregados antiguos de 12 meses a 2 meses (el mínimo que permite Matomo) en la configuración de su instalación "on premise".

Con esto no solo se reducen otras peticiones pesadas, también he rebajado el peso de la base de datos de Matomo de de 362.9 MB A 120.8 MB y me aseguro de que no vuelva a engordar por encima de esos 120 MB.

Así las cosas, y con el sitio en observación, las mejoras inmediatas son bastante evidentes cuando el sitio no está colapsado.

La velocidad de carga general, que se mantenía de media bastante por encima de 3 segundos, ya está muy por debajo. El primer día después de los cambios ya marcaba 1,63 segundos.

Recapitulando:

Número de tareas: Ha bajado de casi 38 o más a solo 4 o 5 cuando no se está editando o actualizando nada. Esto significa que el servidor ya no está lanzando y acumulando procesos lsphp sin control o que no hay peticiones masivas de algún atacante.

Estado de los procesos: Los procesos lsphp ya no están en estado D (Disk Sleep). Esto es lo más importante: se supone que se ha mitigado el cuello de botella de E/S que estaba atascando el servidor.

CPU inactiva (id): Ha subido a un 80%, lo que significa que el servidor tiene muchos recursos de CPU disponibles y no está sobrecargado. Sin embargo esto es solo la "foto" de un momento concreto.

El último misterio: la carga promedio (load average).
La única incongruencia es que el load average sigue siendo alto (alrededor de 5.8). Esto es extraño, ya que la carga promedio mide la cantidad de procesos que están esperando para ser ejecutados (incluyendo los que están en estado D).

Dado que ahora por lo general hay muy pocos procesos y no hay procesos en estado D, el alto load average probablemente está relacionado con otros procesos o usuarios en el mismo servidor compartido o con un problema del servidor que no está directamente relacionado con el blog.

Podría ser un problema de hardware, de I/O a nivel de disco, o de algún otro servicio del servidor, aunque también es bastante probable que sea debido a algo de mi parte o incluso de otra cosa externa y ajena a todos.

Quizá un día, gracias a otra carambola de casualidades, lo descubra. Sea como sea, lo positivo es que estoy aprendiendo un montón de cosas por el camino.

De momento, ya he pedido asistencia a los que saben de verdad de estas cosas y he abierto un tiquecillo de súplica en Lucushost para atacar el problema en cuanto vuelva a producirse.

Solucionado parcialmente, pelea con un DDos

Ya podía seguir buscando el error debajo de las piedras. Los de Lucushost localizaron y atacaron el problema enseguida, demostrando que es tan importante saber, como tener el teléfono del que sabe.

Se trataba de visitas maliciosas desde ciertas IP, ya bloqueadas por los colegas de Lucushost (expertos lectores de logs). Se realizaban muchas peticiones a distintas páginas de la web que eran invisibles para las estadísticas al no tener "referer" (una de los síntomas evidentes de que se trata de bots o visitantes maliciosos) y todas se estaban haciendo al mismo segundo.

El problema es que estas páginas de destino no estaban cacheadas en ese momento por lo que se generaba mucha carga en el servidor y un uso elevado de recursos hasta colapsar.

A eso hay que sumarle el tráfico mierder de los los bots guarros de scrapeo, los de las IA´s y no sé cuántas porquerías más.

Sí, ya se puede considerar un ataque. No fueron simples picos de tráfico natural puntuales o intermitentes, sino un patrón de comportamiento (múltiples peticiones sin referer en muy cortos períodos de tiempo) de alguien que buscaba agotar los recursos del servidor. El hecho de que el hosting haya bloqueado esas IP demuestra que ellos también lo consideraron una actividad maliciosa al momento.

Digo que se ha solucionado parcialmente porque, aunque con algunos procesos menos, se sigue observando una actividad inusual, lo que indica que los intentos de ataque no han cesado, pero ahora van ya a tope con las peticiones para tumbar el sitio.

De los logs se desprende que apuntan a contenido temático, en distintos idiomas pero repitiendo mismas URLs. Las peticiones se centran mayoritariamente en temas y etiquetas como Gaza, caricaturas, humoristas gráficos, Israel y Palestina.

Al poco, desde Lucushost confirma el DDoS, ellos bloquean alguna IP más y activo las distintas defensas y escudos en el CDN de Quic.Cloud y otros mecanismos hasta que los atacantes se aburran.

Y llegó la calma

Por fin, el día 24 remitió el ataque DDoS y todo empezó a volver la normalidad.

Lo bueno, y me repito, es que algunas acciones aplicadas a la búsqueda de una solución donde no hacían falta, dejan el sitio más y mejor optimizado.

Una vez estabilizado completamente, el día 25 de agosto el sitio volvía a un tiempo de carga impecable marcando 1,03 segundos (y bajando). Recupero y supero así mis mejores tiempos porque en casa del herrero no vale cuchara de palo. Y lo que es mejor, superando también sin problemas una avalancha de peticiones de un temible "efecto Menéame".