LiteSpeed processes block the page after a post is published

I have been dealing with a problem for some time now for which I have not yet found a definitive solution.

The issue is that, right after publishing a post, the CPU consumption skyrockets as well as the number of processes leaving the site practically inaccessible for long periods of time.

This is a serious problem, as subscribers will receive a notice of a new publication, which they will not be able to read because the page does not resolve, not to mention what it means for positioning to have the page down frequently.

After some time, the system will eventually kill the processes, but it can take hours for that to happen.

If you use cPanel, you will usually receive an email with a message like this:

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

Having DISABLE_WP_CRON enabled in the wp-config.php, still receiving the "Killed" message from cPanel, means that there is some other process or configuration (that I haven't discovered yet) that is trying to run wp-cron.php, and the system is terminating it due to overconsumption of resources (memory, CPU, etc.).

Today I've investigated a bit more and I've been monitoring the CPU consumption. For this, I used the terminal in the browser for SSH and WP-CLI access offered by LucusHost in cPanel.

If your hosting allows it, to access you must go to Advanced/Terminal in cPanel. If your blog files are in the public_html folder, you must access it like this:

cd public_html

Then, to see the running processes, type

top

And you should see something like this:

In my case I find an avalanche of lsphp processes that completely eat up the CPU.

You only need to open the WordPress administration area to see four or five LiteSpeed processes(lsphp) that close after a few seconds. This is normal, LiteSpeed's lsphp processes are part of its architecture to handle PHP connections efficiently.

However, something is not right when, after publishing a new post (sometimes it is enough just to edit one already published), these processes are triggered both in number and CPU usage and are not released, leaving the site dead.

The first emergency measure to unblock the page is to kill those "stuck" processes, which does not solve the problem that causes the blockage, but you regain access to the site.

pkill -u TuNombreDeUsuario lsphp

If you prefer, you can kill a particular process using its PID, although this will probably not do you much good as many processes are closed and opened at short intervals.

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

Normally, by default, LiteSpeed runs these four tasks every minute depending on the configuration of your plugin and the options you are using.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

The first two, imgoptm_pull and ccss, are heavy tasks that sometimes cause timeouts (especially on shared hosting), while ucss and lqip are lighter tasks.

So the first thing I tried is to block the automatic regeneration of LiteSpeed by disabling the automatic Cron management in LiteSpeed, for that I added this in the 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);

Then, with the following function added in the functions.php you force the removal of the 1 minute interval and change it to 1 time per day distributing these tasks at different times to avoid excessive CPU consumption. Depending on the traffic of your blog, you can set these hours at different times in the morning, for example.

/**
 * 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);

Once these changes are applied, check that they are working, according to the Advanced Database Cleaner Pro plugin, these changes are being applied. You can also check with Wp Crontrol.

Assuming you are not using the native WordPress virtual CRON, to further lighten the CPU consumption a new CRON is added that increases the frequency to 30 minutes, avoids duplicates with flok and reduces the server load.

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

Now, when we run wp cron schedule list we find that the litespeed_filter , or any other filter, is not running every 60 seconds.

This is just a first approach. Now I have to keep testing and monitoring the resource usage in different scenarios. At least, for the time being, I haven't seen the page crash again when publishing a new post.

If anyone has the same problem and has found a definitive solution, a tip would be appreciated.