ここしばらくの間、決定的な解決策が見つかっていない問題を抱えている。
問題は、投稿を公開した直後からCPUの消費量が急増し、プロセスの数も増えて、実質的にサイトにアクセスできない時間が長くなることだ。
これは深刻な問題で、購読者は新刊の通知を受け取るが、ページが解決しないために読むことができない。
しばらくすると、システムは最終的にプロセスを終了させるが、それには数時間かかることもある。
cPanelを使用している場合、通常このようなメッセージのメールが届きます:
(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
wp-config.phpで
DISABLE_WP_CRONを
有効にしているにもかかわらず、cPanelから"Killed "メッセージを受け取るということは、wp-cron.phpを
実行しようとしている他のプロセスや設定(まだ発見していない)があり、システムがリソース(メモリ、CPUなど)の過剰消費のためにそれを終了させているということです。
今日はもう少し調べて、CPUの消費量をモニターしてみた。このために、私はcPanelでLucusHostによって提供されたSSHとWP-CLIアクセスのためにブラウザのターミナルを使用しました。
あなたのホスティングがそれを許可している場合は、アクセスするには、cPanelの詳細/ターミナルに移動する必要があります。ブログのファイルがpublic_htmlフォルダにある場合は、次のようにアクセスする必要があります:
cd public_html
次に、実行中のプロセスを見るには、次のようにタイプする。
top
そして、このように表示されるはずだ:

私の場合、lsphpプロセスが雪崩を打ってCPUを完全に食いつぶしている。
WordPressの管理エリアを開くだけで、4つか5つのLiteSpeedプロセス(lsphp)が数秒後にクローズするのが見えます。これは正常で、LiteSpeedのlsphpプロセスは、PHP接続を効率的に処理するためのアーキテクチャの一部です。
しかし、新しい投稿を公開した後(時にはすでに公開された投稿を編集するだけで十分な場合もある)、これらのプロセスが数とCPU使用量の両方でトリガーされ、解放されず、サイトが死んだままになると、何かがおかしい。
ページのブロックを解除するための最初の緊急措置は、「スタック」したプロセスを強制終了することである。
pkill -u TuNombreDeUsuario lsphp
しかし、多くのプロセスは短い間隔で閉じたり開いたりするため、この方法はあまり役に立たないだろう。
# Detiene procesos con alto %CPU (ejemplo para detener el PID 7026)
kill -9 7026
通常、デフォルトでは、LiteSpeedは、プラグインの設定と使用しているオプションに応じて、これらの4つのタスクを1分ごとに実行します。
litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip
最初の2つ、imgoptm_pullと
ccssは
時々タイムアウトを引き起こす重いタスクで(特に共有ホスティング)、ucssと lqipは軽いタスクだ。
そこでまず試したのは、LiteSpeedの自動Cron管理を無効にして、LiteSpeedの自動再生をブロックすること。
// Deshabilita la gestión automática de Cron en LiteSpeed
define('LITESPEED_DISABLE_CACHE_PURGE_CRON', true);
define('LITESPEED_DISABLE_AUTOUPDATE_CRON', true);
そして、functions.phpに以下の関数を追加することで、1分間隔を強制的に削除し、1日1回に変更します。このタスクを異なる時間に分散させることで、CPUの過剰消費を防ぎます。ブログのトラフィックに応じて、例えば朝の異なる時間にこれらの時間を設定することができます。
/**
* 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);
これらの変更が適用されたら、Advanced Database Cleaner Proプラグインによると、これらの変更が適用されていることを確認してください。Wp Crontrolで確認することもできます。

WordPressネイティブの仮想CRONを使用していないと仮定すると、CPU消費をさらに軽くするために、頻度を30分に増やし、flokとの重複を避け、サーバーの負荷を軽減する新しいCRONが追加されます。
*/30 * * * * /usr/bin/flock -xn /tmp/wp-cron.lock /usr/local/bin/php /home/TuNombreDeUsuario/public_html/wp-cron.php > /dev/null 2>&1
さて、wp cron schedule listを実行すると、litespeed_filterや 他のフィルターが60秒ごとに実行されていないことがわかります。

これは最初のアプローチに過ぎない。今は、さまざまなシナリオでリソースの使用状況をテストし、モニターし続けなければならない。少なくとも今のところ、新しい投稿を公開するときにページがクラッシュすることはない。
同じ問題を抱えている方で、決定的な解決策を見つけた方がいらっしゃいましたら、ヒントをいただけると助かります。