LiteSpeed-prosesser blokkerer siden etter at et innlegg er publisert

Jeg har i lengre tid jobbet med et problem som jeg ennå ikke har funnet en endelig løsning på.

Problemet er at rett etter publisering av et innlegg skyter CPU-forbruket i været, i tillegg til at antall prosesser øker, slik at nettstedet blir praktisk talt utilgjengelig i lange perioder.

Dette er et alvorlig problem, ettersom abonnentene vil motta en melding om en ny publikasjon som de ikke kan lese fordi siden ikke løser seg opp, for ikke å snakke om hva det betyr for posisjoneringen å ha siden nede ofte.

Etter en stund vil systemet til slutt drepe prosessene, men det kan ta timer før det skjer.

Hvis du bruker cPanel, vil du vanligvis motta en e-post med en melding 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

Å ha DISABLE_WP_CRON aktivert i wp-config.php, og fortsatt motta "Killed" -meldingen fra cPanel, betyr at det er en annen prosess eller konfigurasjon (som jeg ikke har oppdaget ennå) som prøver å kjøre wp-cron. php, og systemet avslutter det på grunn av overforbruk av ressurser (minne, CPU, etc.).

I dag har jeg undersøkt litt mer og jeg har overvåket CPU-forbruket. For dette brukte jeg terminalen i nettleseren for SSH og WP-CLI-tilgang som tilbys av LucusHost i cPanel.

Hvis webhotellet ditt tillater det, må du gå til Avansert/Terminal i cPanel for å få tilgang. Hvis bloggfilene dine ligger i public_html-mappen, må du få tilgang til den slik:

cd public_html

For å se prosessene som kjører, skriver du inn

top

Og du bør se noe sånt som dette:

I mitt tilfelle finner jeg et skred av lsphp-prosesser som spiser opp CPU-en fullstendig.

Du trenger bare å åpne WordPress-administrasjonsområdet for å se fire eller fem LiteSpeed-prosesser(lsphp) som lukkes etter noen sekunder. Dette er normalt, LiteSpeeds lsphp-prosesser er en del av arkitekturen for å håndtere PHP-tilkoblinger effektivt.

Det er imidlertid noe som ikke stemmer når disse prosessene utløses både i antall og CPU-bruk etter publisering av et nytt innlegg (noen ganger er det nok bare å redigere et som allerede er publisert), og ikke frigjøres, slik at nettstedet blir liggende dødt.

Det første nødtiltaket for å oppheve blokkeringen av siden er å drepe de "fastlåste" prosessene, noe som ikke løser problemet som forårsaker blokkeringen, men du får tilgang til nettstedet igjen.

pkill -u TuNombreDeUsuario lsphp

Hvis du foretrekker det, kan du drepe en bestemt prosess ved hjelp av dens PID, selv om dette sannsynligvis ikke vil være til særlig nytte ettersom mange prosesser lukkes og åpnes med korte intervaller.

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

Som standard kjører LiteSpeed disse fire oppgavene hvert minutt, avhengig av konfigurasjonen av plugin-modulen og alternativene du bruker.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

De to første, imgoptm_pull og ccss, er tunge oppgaver som noen ganger forårsaker tidsavbrudd (spesielt på delt hosting), mens ucss og lqip er lettere oppgaver.

Så det første jeg prøvde er å blokkere den automatiske regenereringen av LiteSpeed ved å deaktivere den automatiske Cron-administrasjonen i LiteSpeed, for det la jeg til 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);

Deretter, med følgende funksjon lagt til i functions.php, tvinger du fjerningen av 1 minutters intervall og endrer det til 1 gang per dag og distribuerer disse oppgavene på forskjellige tidspunkter for å unngå overdreven CPU-forbruk. Avhengig av trafikken på bloggen din, kan du for eksempel angi disse timene på forskjellige 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 endringene er brukt, må du kontrollere at de fungerer, i henhold til Advanced Database Cleaner Pro-plugin, blir disse endringene brukt. Du kan også sjekke med Wp Crontrol.

Forutsatt at du ikke bruker den virtuelle CRON-funksjonen i WordPress, er det lagt til en ny CRON-funksjon som øker frekvensen til 30 minutter, unngår dupliseringer med flok og reduserer serverbelastningen for å redusere CPU-forbruket ytterligere.

*/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å, når vi kjører wp cron schedule list, finner vi ut at litespeed_filter , eller noe annet filter, ikke kjører hvert 60. sekund.

Dette er bare en første tilnærming. Nå må jeg fortsette å teste og overvåke ressursbruken i forskjellige scenarier. Foreløpig har jeg i hvert fall ikke sett siden krasje igjen når jeg publiserer et nytt innlegg.

Hvis noen har samme problem og har funnet en endelig løsning, vil et tips bli satt pris på.