Os processos LiteSpeed bloqueiam a página após a publicação de um post

Há já algum tempo que estou a lidar com um problema para o qual ainda não encontrei uma solução definitiva.

O problema é que, logo após a publicação de um post, o consumo de CPU dispara, assim como o número de processos, deixando o site praticamente inacessível por longos períodos de tempo.

Trata-se de um problema grave, uma vez que os subscritores receberão um aviso de uma nova publicação, que não poderão ler porque a página não é resolvida, para não falar do que significa para o posicionamento ter a página frequentemente em baixo.

Após algum tempo, o sistema acabará por eliminar os processos, mas pode demorar horas até que isso aconteça.

Se utilizar o cPanel, receberá normalmente um e-mail com uma mensagem como esta:

(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

Ter DISABLE_WP_CRON ativado no wp-config.php, continuando a receber a mensagem "Killed" do cPanel, significa que existe algum outro processo ou configuração (que ainda não descobri) que está a tentar executar o wp-cron.php, e o sistema está a terminá-lo devido ao consumo excessivo de recursos (memória, CPU, etc.).

Hoje investiguei um pouco mais e estive a monitorizar o consumo de CPU. Para isso, usei o terminal no navegador para acesso SSH e WP-CLI oferecido pela LucusHost no cPanel.

Se o seu alojamento o permitir, para aceder deve ir a Advanced/Terminal no cPanel. Se os ficheiros do seu blogue estiverem na pasta public_html, deve aceder-lhe da seguinte forma

cd public_html

Em seguida, para ver os processos em execução, digite

top

E deverá ver algo como isto:

No meu caso, encontro uma avalanche de processos lsphp que consomem completamente a CPU.

Basta abrir a área de administração do WordPress para ver quatro ou cinco processos LiteSpeed(lsphp) que fecham após alguns segundos. Isto é normal, os processos lsphp do LiteSpeed fazem parte da sua arquitetura para lidar com ligações PHP de forma eficiente.

No entanto, algo não está bem quando, depois de publicar um novo post (por vezes basta editar um já publicado), estes processos são acionados tanto em número como em utilização de CPU e não são libertados, deixando o site morto.

A primeira medida de emergência para desbloquear a página é matar os processos "presos", o que não resolve o problema que causa o bloqueio, mas recupera o acesso ao sítio.

pkill -u TuNombreDeUsuario lsphp

Se preferir, pode eliminar um determinado processo utilizando o seu PID, embora isso provavelmente não lhe sirva de muito, uma vez que muitos processos são fechados e abertos em intervalos curtos.

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

Normalmente, por defeito, o LiteSpeed executa estas quatro tarefas a cada minuto, dependendo da configuração do seu plugin e das opções que está a utilizar.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

As duas primeiras, imgoptm_pull e ccss, são tarefas pesadas que por vezes causam timeouts (especialmente em alojamento partilhado), enquanto ucss e lqip são tarefas mais leves.

Assim, a primeira coisa que tentei foi bloquear a regeneração automática do LiteSpeed, desactivando a gestão automática de Cron no LiteSpeed, para isso adicionei isto no 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);

Depois, com a seguinte função adicionada ao functions.php, força-se a remoção do intervalo de 1 minuto e altera-se para 1 vez por dia, distribuindo essas tarefas em horários diferentes para evitar o consumo excessivo de CPU. Dependendo do tráfego do seu blogue, pode definir estas horas a diferentes horas da manhã, por exemplo.

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

Uma vez aplicadas estas alterações, verifique se estão a funcionar, de acordo com o plugin Advanced Database Cleaner Pro, estas alterações estão a ser aplicadas. Também pode verificar com o Wp Crontrol.

Assumindo que não está a utilizar o CRON virtual nativo do WordPress, para aliviar ainda mais o consumo de CPU é adicionado um novo CRON que aumenta a frequência para 30 minutos, evita duplicados com flok e reduz a carga do 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

Agora, quando corremos a lista de horários do wp cron, verificamos que o filtro litespeed_filter , ou qualquer outro filtro, não está a ser executado a cada 60 segundos.

Esta é apenas uma primeira abordagem. Agora tenho de continuar a testar e a monitorizar a utilização de recursos em diferentes cenários. Pelo menos, por enquanto, ainda não vi a página falhar novamente ao publicar um novo post.

Se alguém tiver o mesmo problema e tiver encontrado uma solução definitiva, agradecia que me desse uma dica.