Procesy LiteSpeed blokují stránku po zveřejnění příspěvku

Již nějakou dobu se potýkám s problémem, pro který jsem dosud nenašel definitivní řešení.

Problémem je, že ihned po zveřejnění příspěvku prudce vzroste spotřeba procesoru i počet procesů, takže web je po dlouhou dobu prakticky nedostupný.

Jedná se o závažný problém, protože předplatitelé obdrží oznámení o nové publikaci, kterou si nebudou moci přečíst, protože stránka se nevyřeší, nemluvě o tom, co to znamená pro umístění, že stránka je často vypnutá.

Po určité době systém procesy nakonec ukončí, ale může to trvat i několik hodin.

Pokud používáte cPanel, obvykle obdržíte e-mail s touto zprávou:

(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

Mít DISABLE_WP_CRON povoleno v wp-config.php, stále dostává zprávu "Zabito" z cPanel, znamená, že existuje nějaký jiný proces nebo konfigurace (že jsem ještě neobjevil), který se snaží spustit wp-cron.php, a systém je ukončit z důvodu nadměrné spotřeby zdrojů (paměť, CPU, atd.).

Dnes jsem to zkoumal trochu víc a sledoval jsem spotřebu procesoru. K tomu jsem použil terminál v prohlížeči pro přístup k SSH a WP-CLI, které nabízí LucusHost v cPanelu.

Pokud to váš hosting umožňuje, musíte v cPanelu přejít do části Rozšířené/Terminál. Pokud jsou soubory vašeho blogu ve složce public_html, musíte k nim přistupovat takto:

cd public_html

Chcete-li zobrazit spuštěné procesy, zadejte

top

A měli byste vidět něco takového:

V mém případě se objevuje lavina procesů lsphp, které zcela vyčerpávají procesor.

Stačí otevřít administrační oblast WordPressu a uvidíte čtyři nebo pět procesů LiteSpeed(lsphp), které se po několika sekundách zavřou. To je normální, procesy LiteSpeed lsphp jsou součástí jeho architektury pro efektivní zpracování připojení PHP.

Něco však není v pořádku, když se po zveřejnění nového příspěvku (někdy stačí jen upravit již zveřejněný) tyto procesy spustí jak počtem, tak využitím procesoru a nejsou uvolněny, takže web je mrtvý.

Prvním nouzovým opatřením k odblokování stránky je zabití těchto "zaseknutých" procesů, čímž se sice nevyřeší problém, který zablokování způsobuje, ale obnoví se přístup k webu.

pkill -u TuNombreDeUsuario lsphp

Pokud chcete, můžete určitý proces zabít pomocí jeho PID, i když to pravděpodobně nebude příliš užitečné, protože mnoho procesů se zavírá a otevírá v krátkých intervalech.

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

Ve výchozím nastavení LiteSpeed provádí tyto čtyři úlohy každou minutu v závislosti na konfiguraci vašeho zásuvného modulu a používaných možnostech.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

První dvě, imgoptm_pull a ccss, jsou těžké úlohy, které někdy způsobují timeouty (zejména na sdíleném hostingu), zatímco ucss a lqip jsou lehčí úlohy.

Takže první věc, kterou jsem se snažil je blokovat automatickou regeneraci LiteSpeed zakázáním automatické správy Cron v LiteSpeed, za to jsem přidal to v 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);

Pak pomocí následující funkce přidané do souboru functions.php vynutíte odstranění 1minutového intervalu a změníte jej na 1krát denně, přičemž tyto úlohy rozdělíte v různých časech, abyste zabránili nadměrné spotřebě procesoru. V závislosti na návštěvnosti vašeho blogu můžete tyto hodiny nastavit například na různou dobu ráno.

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

Po provedení těchto změn zkontrolujte, zda jsou funkční, a podle pluginu Advanced Database Cleaner Pro se tyto změny aplikují. Můžete také zkontrolovat pomocí Wp Crontrol.

Za předpokladu, že nepoužíváte nativní virtuální CRON WordPressu, je pro další snížení spotřeby procesoru přidán nový CRON, který zvyšuje frekvenci na 30 minut, zabraňuje duplicitám s flokem a snižuje zatížení serveru.

*/30    *       *       *       * /usr/bin/flock -xn /tmp/wp-cron.lock /usr/local/bin/php /home/TuNombreDeUsuario/public_html/wp-cron.php > /dev/null 2>&1

Když nyní spustíme seznam plánů wp cron, zjistíme, že filtr litespeed_filter , ani žádný jiný filtr, se nespouští každých 60 sekund.

Jedná se pouze o první přístup. Nyní musím pokračovat v testování a sledování využití prostředků v různých scénářích. Alespoň jsem zatím nezaznamenal, že by stránka při publikování nového příspěvku opět spadla.

Pokud má někdo stejný problém a našel definitivní řešení, uvítáme tip.