投稿が公開された後、LiteSpeedのプロセスによってページがブロックされる。

 

ここしばらくの間、決定的な解決策が見つかっていない問題を抱えている。

問題は、投稿を公開した直後から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

そして、このように表示されるはずだ:

投稿が公開された後、LiteSpeedのプロセスによってページがブロックされる。 0

私の場合、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で確認することもできます。

投稿が公開された後、LiteSpeedのプロセスによってページがブロックされる。 1

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秒ごとに実行されていないことがわかります。

投稿が公開された後、LiteSpeedのプロセスによってページがブロックされる。 2

これは最初のアプローチに過ぎない。今は、さまざまなシナリオでリソースの使用状況をテストし、モニターし続けなければならない。少なくとも今のところ、新しい投稿を公開するときにページがクラッシュすることはない。

同じ問題を抱えている方で、決定的な解決策を見つけた方がいらっしゃいましたら、ヒントをいただけると助かります。

Suscríbete para recibir los post en tu email sin publicidad

関連記事

WordPress 6.8での投機的ロード

WordPress 6.8での投機的ロード

WordPressで過剰なDOMサイズを避ける

WordPressで過剰なDOMサイズを避ける

INPはすでにコアウェブ・バイタルの中核指標となっている。

INPはすでにコアウェブ・バイタルの中核指標となっている。

Este blog se aloja en LucusHost

LucusHost, el mejor hosting