LiteSpeed-processen blokkeren de pagina nadat een bericht is gepubliceerd

Ik zit al een tijdje met een probleem waarvoor ik nog geen definitieve oplossing heb gevonden.

Het probleem is dat, direct na het publiceren van een bericht, het CPU-verbruik omhoog schiet, evenals het aantal processen, waardoor de site gedurende lange perioden praktisch ontoegankelijk is.

Dit is een ernstig probleem, omdat abonnees een bericht ontvangen over een nieuwe publicatie die ze niet kunnen lezen omdat de pagina niet wordt opgelost, om nog maar te zwijgen over wat het betekent voor de positionering om de pagina vaak down te hebben.

Na enige tijd zal het systeem de processen uiteindelijk stoppen, maar het kan uren duren voordat dat gebeurt.

Als je cPanel gebruikt, ontvang je meestal een e-mail met een bericht als dit:

(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

Als je DISABLE_WP_CRON hebt ingeschakeld in wp-config.php en je krijgt nog steeds het bericht "Killed" van cPanel, dan betekent dit dat er een ander proces of een andere configuratie is (die ik nog niet heb ontdekt) die wp-cron.php probeert uit te voeren en het systeem beëindigt dit proces vanwege overconsumptie van bronnen (geheugen, CPU, enz.).

Vandaag heb ik wat meer onderzoek gedaan en het CPU-verbruik in de gaten gehouden. Hiervoor heb ik de terminal in de browser gebruikt voor SSH en WP-CLI toegang aangeboden door LucusHost in cPanel.

Als je hosting het toestaat, moet je naar Geavanceerd/Terminal in cPanel gaan om toegang te krijgen. Als je blogbestanden in de public_html map staan, moet je deze als volgt openen:

cd public_html

Typ vervolgens

top

En je zou zoiets als dit moeten zien:

In mijn geval vind ik een lawine van lsphp-processen die de CPU volledig opslokken.

Je hoeft alleen maar het WordPress administratiegebied te openen om vier of vijf LiteSpeed processen(lsphp) te zien die na een paar seconden sluiten. Dit is normaal, LiteSpeed's lsphp processen zijn onderdeel van de architectuur om PHP verbindingen efficiënt af te handelen.

Er klopt echter iets niet wanneer, na het publiceren van een nieuw bericht (soms is het voldoende om een reeds gepubliceerd bericht te bewerken), deze processen zowel in aantal als in CPU-gebruik worden geactiveerd en niet worden vrijgegeven, waardoor de site doodloopt.

De eerste noodmaatregel om de pagina te deblokkeren is om die "vastzittende" processen te doden, wat het probleem dat de blokkade veroorzaakt niet oplost, maar je krijgt wel weer toegang tot de site.

pkill -u TuNombreDeUsuario lsphp

Als je dat liever hebt, kun je een bepaald proces doden met behulp van zijn PID, hoewel dit waarschijnlijk niet veel uithaalt omdat veel processen met korte tussenpozen worden gesloten en geopend.

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

Normaal gesproken voert LiteSpeed deze vier taken standaard elke minuut uit, afhankelijk van de configuratie van je plugin en de opties die je gebruikt.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

De eerste twee, imgoptm_pull en ccss, zijn zware taken die soms timeouts veroorzaken (vooral op shared hosting), terwijl ucss en lqip lichtere taken zijn.

Dus het eerste wat ik heb geprobeerd is om de automatische regeneratie van LiteSpeed te blokkeren door het automatische Cron management in LiteSpeed uit te schakelen, daarvoor heb ik dit toegevoegd in de 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);

Vervolgens forceer je met de volgende functie in functions.php het verwijderen van de 1 minuut interval en verander je het naar 1 keer per dag waarbij je deze taken op verschillende tijdstippen verdeelt om overmatig CPU verbruik te voorkomen. Afhankelijk van het verkeer van je blog kun je deze uren bijvoorbeeld op verschillende tijden in de ochtend instellen.

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

Zodra deze wijzigingen zijn toegepast, controleer dan of ze werken, volgens de Advanced Database Cleaner Pro plugin worden deze wijzigingen toegepast. Je kunt ook controleren met Wp Crontrol.

Ervan uitgaande dat je de native WordPress virtuele CRON niet gebruikt, is er om het CPU-verbruik verder te verlichten een nieuwe CRON toegevoegd die de frequentie verhoogt naar 30 minuten, duplicaten met flok vermijdt en de serverbelasting vermindert.

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

Nu, als we wp cron schema lijst draaien vinden we dat de litespeed_filter , of een andere filter, niet elke 60 seconden wordt uitgevoerd.

Dit is slechts een eerste benadering. Nu moet ik blijven testen en het brongebruik in verschillende scenario's in de gaten houden. Voorlopig heb ik de pagina tenminste nog niet zien crashen bij het publiceren van een nieuw bericht.

Als iemand hetzelfde probleem heeft en een definitieve oplossing heeft gevonden, zou een tip zeer op prijs worden gesteld.