LiteSpeed-processer blokerer siden, når et indlæg er publiceret

Jeg har i nogen tid tumlet med et problem, som jeg endnu ikke har fundet en endelig løsning på.

Problemet er, at lige efter udgivelsen af et indlæg skyder CPU-forbruget i vejret, og det samme gør antallet af processer, hvilket gør sitet praktisk talt utilgængeligt i lange perioder.

Det er et alvorligt problem, da abonnenterne vil modtage en meddelelse om en ny publikation, som de ikke kan læse, fordi siden ikke løses, for slet ikke at tale om, hvad det betyder for positioneringen, at siden ofte er nede.

Efter et stykke tid vil systemet til sidst dræbe processerne, men det kan tage timer, før det sker.

Hvis du bruger cPanel, vil du normalt modtage en e-mail med en besked som denne:

(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

Når DISABLE_WP_CRON er aktiveret i wp-config.php, og du stadig modtager meddelelsen "Killed " fra cPanel, betyder det, at der er en anden proces eller konfiguration (som jeg ikke har opdaget endnu), der forsøger at køre wp-cron.php, og systemet afslutter den på grund af overforbrug af ressourcer (hukommelse, CPU osv.).

I dag har jeg undersøgt lidt mere, og jeg har overvåget CPU-forbruget. Til dette brugte jeg terminalen i browseren til SSH og WP-CLI-adgang, der tilbydes af LucusHost i cPanel.

Hvis din hosting tillader det, skal du gå til Advanced/Terminal i cPanel for at få adgang. Hvis dine blogfiler ligger i mappen public_html, skal du få adgang til den på denne måde:

cd public_html

For at se de igangværende processer skal du derefter skrive

top

Og du bør se noget i retning af dette:

I mit tilfælde finder jeg en lavine af lsphp-processer, der æder hele CPU'en op.

Du behøver kun at åbne WordPress' administrationsområde for at se fire eller fem LiteSpeed-processer(lsphp), der lukker efter et par sekunder. Det er normalt, LiteSpeeds lsphp-processer er en del af arkitekturen til at håndtere PHP-forbindelser effektivt.

Men der er noget galt, når disse processer efter udgivelse af et nyt indlæg (nogle gange er det nok bare at redigere et, der allerede er udgivet) udløses både i antal og CPU-forbrug og ikke frigives, hvilket efterlader webstedet dødt.

Den første nødforanstaltning for at fjerne blokeringen af siden er at dræbe de "fastlåste" processer, hvilket ikke løser det problem, der forårsager blokeringen, men du får adgang til siden igen.

pkill -u TuNombreDeUsuario lsphp

Hvis du foretrækker det, kan du dræbe en bestemt proces ved hjælp af dens PID, selv om det sandsynligvis ikke vil hjælpe dig ret meget, da mange processer lukkes og åbnes med korte intervaller.

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

Normalt kører LiteSpeed som standard disse fire opgaver hvert minut, afhængigt af konfigurationen af dit plugin og de indstillinger, du bruger.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

De to første, imgoptm_pull og ccss, er tunge opgaver, som nogle gange forårsager timeouts (især på delt hosting), mens ucss og lqip er lettere opgaver.

Så det første, jeg prøvede, var at blokere den automatiske regenerering af LiteSpeed ved at deaktivere den automatiske Cron-styring i LiteSpeed, og til det formål tilføjede jeg dette 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);

Med følgende funktion, der er tilføjet i functions.php, tvinger du fjernelsen af intervallet på 1 minut og ændrer det til 1 gang om dagen og fordeler disse opgaver på forskellige tidspunkter for at undgå for stort CPU-forbrug. Afhængigt af trafikken på din blog kan du f.eks. indstille disse timer til forskellige tidspunkter om morgenen.

/**
 * 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 disse ændringer er anvendt, skal du kontrollere, at de fungerer, ifølge Advanced Database Cleaner Pro-plugin 'et bliver disse ændringer anvendt. Du kan også tjekke med Wp Crontrol.

Hvis du ikke bruger WordPress' oprindelige virtuelle CRON, er der tilføjet en ny CRON, som øger frekvensen til 30 minutter, undgår duplikater med flok og reducerer serverbelastningen for yderligere at lette CPU-forbruget.

*/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ører wp cron schedule list, finder vi ud af, at litespeed_filteret eller et andet filter ikke kører hvert 60. sekund.

Dette er blot en første tilgang. Nu skal jeg fortsætte med at teste og overvåge ressourceforbruget i forskellige scenarier. Indtil videre har jeg i hvert fald ikke set siden gå ned igen, når jeg udgiver et nyt indlæg.

Hvis nogen har samme problem og har fundet en endelig løsning, vil et tip være velkomment.