Je suis confronté depuis un certain temps à un problème pour lequel je n'ai pas encore trouvé de solution définitive.
Le problème est que, juste après la publication d'un article, la consommation de l'unité centrale monte en flèche, de même que le nombre de processus, ce qui rend le site pratiquement inaccessible pendant de longues périodes.
Il s'agit d'un problème grave, car les abonnés recevront un avis de nouvelle publication qu'ils ne pourront pas lire parce que la page ne se résout pas, sans parler de ce que cela signifie pour le positionnement d'avoir la page fréquemment en panne.
Au bout d'un certain temps, le système finira par tuer les processus, mais cela peut prendre des heures.
Si vous utilisez cPanel, vous recevrez généralement un courriel contenant un message de ce type :
(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>&1Le fait d'avoir activé DISABLE_WP_CRON dans le fichier wp-config.php et de continuer à recevoir le message "Killed" de cPanel signifie qu'il y a un autre processus ou une autre configuration (que je n'ai pas encore découvert) qui essaie d'exécuter wp-cron.php, et que le système y met fin en raison d'une surconsommation de ressources (mémoire, CPU, etc.).
Aujourd'hui, j'ai investigué un peu plus et j'ai surveillé la consommation de CPU. Pour cela, j'ai utilisé le terminal dans le navigateur pour l'accès SSH et WP-CLI offert par LucusHost dans cPanel.
Si votre hébergement le permet, pour y accéder vous devez aller dans Avancé/Terminal dans cPanel. Si les fichiers de votre blog se trouvent dans le dossier public_html, vous devez y accéder comme suit :
cd public_htmlEnsuite, pour voir les processus en cours, tapez
topVous devriez voir quelque chose comme ceci :
Dans mon cas, je constate une avalanche de processus lsphp qui consomment complètement l'unité centrale.
Il suffit d'ouvrir la zone d'administration de WordPress pour voir quatre ou cinq processus LiteSpeed(lsphp) qui se ferment après quelques secondes. C'est normal, les processus lsphp de LiteSpeed font partie de son architecture pour gérer efficacement les connexions PHP.
Cependant, quelque chose ne va pas lorsque, après la publication d'un nouvel article (il suffit parfois de modifier un article déjà publié), ces processus sont déclenchés à la fois en nombre et en utilisation de l'unité centrale et ne sont pas libérés, ce qui laisse le site inactif.
La première mesure d'urgence pour débloquer la page consiste à tuer les processus "bloqués", ce qui ne résout pas le problème à l'origine du blocage, mais vous permet d'accéder à nouveau au site.
pkill -u TuNombreDeUsuario lsphpSi vous préférez, vous pouvez tuer un processus particulier en utilisant son PID, bien que cela ne soit pas très utile car de nombreux processus sont fermés et ouverts à intervalles rapprochés.
# Detiene procesos con alto %CPU (ejemplo para detener el PID 7026)
kill -9 7026Normalement, par défaut, LiteSpeed exécute ces quatre tâches toutes les minutes en fonction de la configuration de votre plugin et des options que vous utilisez.
litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip
Les deux premières, imgoptm_pull et ccss, sont des tâches lourdes qui entraînent parfois des dépassements de délais (en particulier sur un hébergement partagé), tandis que ucss et lqip sont des tâches plus légères.
Donc la première chose que j'ai essayé est de bloquer la régénération automatique de LiteSpeed en désactivant la gestion automatique des Crons dans LiteSpeed, pour cela j'ai ajouté ceci dans le 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);Ensuite, avec la fonction suivante ajoutée dans le fichier functions.php, vous forcez la suppression de l'intervalle d'une minute et le remplacez par une fois par jour en répartissant ces tâches à différents moments pour éviter une consommation excessive de l'unité centrale. En fonction du trafic de votre blog, vous pouvez fixer ces heures à différents moments de la matinée, par exemple.
/**
* 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);Une fois ces changements appliqués, vérifiez qu'ils fonctionnent, selon le plugin Advanced Database Cleaner Pro, ces changements sont appliqués. Vous pouvez également vérifier avec Wp Crontrol.
En supposant que vous n'utilisiez pas le CRON virtuel natif de WordPress, un nouveau CRON a été ajouté afin d'alléger la consommation du processeur. Il augmente la fréquence à 30 minutes, évite les doublons avec flok et réduit la charge du serveur.
*/30 * * * * /usr/bin/flock -xn /tmp/wp-cron.lock /usr/local/bin/php /home/TuNombreDeUsuario/public_html/wp-cron.php > /dev/null 2>&1
Maintenant, lorsque nous lançons wp cron schedule list, nous constatons que le filtre litespeed_filter , ou tout autre filtre, ne s'exécute pas toutes les 60 secondes.
Ce n'est qu'une première approche. Je dois maintenant continuer à tester et à surveiller l'utilisation des ressources dans différents scénarios. En tout cas, pour l'instant, je n'ai pas vu la page se bloquer à nouveau lors de la publication d'un nouvel article.
Si quelqu'un a le même problème et a trouvé une solution définitive, un conseil serait apprécié.
