LiteSpeed-processer blockerar sidan efter att ett inlägg har publicerats

Jag har under en längre tid brottats med ett problem som jag ännu inte har hittat någon definitiv lösning på.

Problemet är att direkt efter att ett inlägg har publicerats skjuter CPU-förbrukningen i höjden liksom antalet processer, vilket gör att webbplatsen praktiskt taget är oåtkomlig under långa tidsperioder.

Detta är ett allvarligt problem, eftersom prenumeranterna kommer att få ett meddelande om en ny publikation som de inte kan läsa eftersom sidan inte löses upp, för att inte tala om vad det innebär för positioneringen att ha sidan nere ofta.

Efter en tid kommer systemet så småningom att döda processerna, men det kan ta timmar innan det sker.

Om du använder cPanel får du vanligtvis ett e-postmeddelande med ett meddelande som ser ut så här:

(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

Att ha DISABLE_WP_CRON aktiverat i wp-config.php och ändå få meddelandet "Killed" från cPanel innebär att det finns någon annan process eller konfiguration (som jag inte har upptäckt ännu) som försöker köra wp-cron.php, och systemet avslutar den på grund av överkonsumtion av resurser (minne, CPU, etc.).

Idag har jag undersökt lite mer och jag har övervakat CPU-förbrukningen. För detta använde jag terminalen i webbläsaren för SSH och WP-CLI-åtkomst som erbjuds av LucusHost i cPanel.

Om ditt webbhotell tillåter det måste du gå till Advanced/Terminal i cPanel för att få åtkomst. Om dina bloggfiler finns i mappen public_html måste du komma åt den så här:

cd public_html

För att se de processer som körs skriver du sedan

top

Och du bör se något liknande detta:

I mitt fall hittar jag en lavin av lsphp-processer som helt äter upp CPU.

Du behöver bara öppna WordPress administrationsområde för att se fyra eller fem LiteSpeed-processer(lsphp) som stängs efter några sekunder. Detta är normalt, LiteSpeeds lsphp-processer är en del av dess arkitektur för att hantera PHP-anslutningar effektivt.

Det är dock något som inte stämmer när dessa processer, efter att ha publicerat ett nytt inlägg (ibland räcker det bara att redigera ett redan publicerat), triggas både i antal och CPU-användning och inte släpps, vilket gör att webbplatsen är död.

Den första nödåtgärden för att avblockera sidan är att döda de "fastnade" processerna, vilket inte löser problemet som orsakar blockeringen, men du återfår åtkomst till webbplatsen.

pkill -u TuNombreDeUsuario lsphp

Om du hellre vill kan du döda en viss process med hjälp av dess PID, men det är förmodligen inte så bra eftersom många processer stängs och öppnas med korta intervall.

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

Normalt kör LiteSpeed som standard dessa fyra uppgifter varje minut beroende på konfigurationen av ditt plugin och de alternativ du använder.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

De två första, imgoptm_pull och ccss, är tunga uppgifter som ibland orsakar timeouts (särskilt på delad hosting), medan ucss och lqip är lättare uppgifter.

Så det första jag försökte var att blockera den automatiska regenereringen av LiteSpeed genom att inaktivera den automatiska Cron-hanteringen i LiteSpeed, för det lade jag till detta i 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);

Sedan, med följande funktion som läggs till i functions.php, tvingar du bort 1-minutersintervallet och ändrar det till 1 gång per dag och fördelar dessa uppgifter vid olika tidpunkter för att undvika överdriven CPU-förbrukning. Beroende på trafiken på din blogg kan du ställa in dessa timmar vid olika tidpunkter på morgonen, till exempel.

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

När dessa ändringar har tillämpats, kontrollera att de fungerar, enligt Advanced Database Cleaner Pro plugin, tillämpas dessa ändringar. Du kan också kontrollera med Wp Crontrol.

Förutsatt att du inte använder den inbyggda virtuella CRON:en för WordPress, för att ytterligare minska CPU-förbrukningen, läggs en ny CRON till som ökar frekvensen till 30 minuter, undviker dubbletter med flok och minskar serverbelastningen.

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

När vi nu kör wp cron schedule list upptäcker vi att litespeed_filter , eller något annat filter, inte körs var 60:e sekund.

Detta är bara ett första tillvägagångssätt. Nu måste jag fortsätta att testa och övervaka resursanvändningen i olika scenarier. För tillfället har jag i alla fall inte sett sidan krascha igen när jag publicerar ett nytt inlägg.

Om någon har samma problem och har hittat en definitiv lösning, skulle ett tips uppskattas.