Da qualche tempo sto affrontando un problema per il quale non ho ancora trovato una soluzione definitiva.
Il problema è che, subito dopo aver pubblicato un post, il consumo di CPU sale alle stelle così come il numero di processi, lasciando il sito praticamente inaccessibile per lunghi periodi di tempo.
Si tratta di un problema serio, in quanto gli abbonati ricevono l'avviso di una nuova pubblicazione che non riescono a leggere perché la pagina non si risolve, per non parlare di ciò che significa per il posizionamento avere la pagina giù frequentemente.
Dopo un po' di tempo, il sistema finirà per eliminare i processi, ma possono volerci ore prima che ciò accada.
Se si utilizza cPanel, di solito si riceve un'e-mail con un messaggio simile a questo:
(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
Avendo attivato DISABLE_WP_CRON
nel file wp-config.php
, e continuando a ricevere il messaggio "Ucciso" da cPanel, significa che c'è qualche altro processo o configurazione (che non ho ancora scoperto) che sta cercando di eseguire wp-cron.php
, e il sistema lo sta terminando a causa del consumo eccessivo di risorse (memoria, CPU, ecc.).
Oggi ho indagato un po' di più e ho monitorato il consumo di CPU. A tal fine, ho utilizzato il terminale nel browser per l'accesso SSH e WP-CLI offerto da LucusHost in cPanel.
Se il vostro hosting lo consente, per accedervi dovete andare su Avanzate/Terminale in cPanel. Se i file del vostro blog si trovano nella cartella public_html, dovete accedervi in questo modo:
cd public_html
Quindi, per vedere i processi in esecuzione, digitare
top
E si dovrebbe vedere qualcosa di simile a questo:

Nel mio caso trovo una valanga di processi lsphp che consumano completamente la CPU.
Basta aprire l'area di amministrazione di WordPress per vedere quattro o cinque processi LiteSpeed(lsphp) che si chiudono dopo pochi secondi. Questo è normale, i processi lsphp di LiteSpeed fanno parte della sua architettura per gestire in modo efficiente le connessioni PHP.
Tuttavia, c'è qualcosa che non va quando, dopo aver pubblicato un nuovo post (a volte è sufficiente modificarne uno già pubblicato), questi processi si attivano sia per numero che per utilizzo della CPU e non vengono rilasciati, lasciando il sito morto.
La prima misura di emergenza per sbloccare la pagina è uccidere i processi "bloccati", il che non risolve il problema che causa il blocco, ma consente di accedere nuovamente al sito.
pkill -u TuNombreDeUsuario lsphp
Se si preferisce, si può uccidere un particolare processo usando il suo PID, anche se probabilmente non servirà a molto, dato che molti processi vengono chiusi e aperti a brevi intervalli.
# Detiene procesos con alto %CPU (ejemplo para detener el PID 7026)
kill -9 7026
Normalmente, per impostazione predefinita, LiteSpeed esegue questi quattro compiti ogni minuto, a seconda della configurazione del plugin e delle opzioni utilizzate.
litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip
I primi due, imgoptm_pull
e ccss
, sono compiti pesanti che a volte causano timeout (specialmente su hosting condiviso), mentre ucss e lqip sono compiti più leggeri.
Quindi la prima cosa che ho provato è stata quella di bloccare la rigenerazione automatica di LiteSpeed disabilitando la gestione automatica di Cron in LiteSpeed, per questo ho aggiunto questo nel 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);
Poi, con la seguente funzione aggiunta nel file functions.php, si forza la rimozione dell'intervallo di 1 minuto e lo si cambia in 1 volta al giorno, distribuendo questi compiti in momenti diversi per evitare un consumo eccessivo di CPU. A seconda del traffico del vostro blog, potete impostare queste ore in diversi momenti della mattina, per esempio.
/**
* 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 volta applicate queste modifiche, verificare che funzionino; secondo il plugin Advanced Database Cleaner Pro, queste modifiche vengono applicate. Si può anche controllare con Wp Crontrol.

Supponendo di non utilizzare il CRON virtuale nativo di WordPress, per alleggerire ulteriormente il consumo di CPU è stato aggiunto un nuovo CRON che aumenta la frequenza a 30 minuti, evita i duplicati con flok e riduce il carico del server.
*/30 * * * * /usr/bin/flock -xn /tmp/wp-cron.lock /usr/local/bin/php /home/TuNombreDeUsuario/public_html/wp-cron.php > /dev/null 2>&1
Ora, quando si esegue l'elenco delle pianificazioni di wp cron, si scopre che il filtro litespeed , o qualsiasi altro filtro, non viene eseguito ogni 60 secondi.

Questo è solo un primo approccio. Ora devo continuare a testare e monitorare l'utilizzo delle risorse in diversi scenari. Almeno, per il momento, non ho più visto la pagina bloccarsi quando si pubblica un nuovo post.
Se qualcuno ha riscontrato lo stesso problema e ha trovato una soluzione definitiva, sarebbe gradito un suggerimento.