LiteSpeed protsessid blokeerivad lehe pärast postituse avaldamist

Olen juba mõnda aega tegelenud probleemiga, millele ma ei ole veel leidnud lõplikku lahendust.

Probleem on selles, et kohe pärast postituse avaldamist kasvab protsessori tarbimine ja protsesside arv hüppeliselt, mistõttu on veebileht pikka aega praktiliselt kättesaamatu.

See on tõsine probleem, sest tellijad saavad teate uue väljaande kohta, mida nad ei saa lugeda, sest leht ei lahene, rääkimata sellest, mida tähendab lehe sagedane allavajumine positsioneerimisele.

Mõne aja pärast tapab süsteem lõpuks protsessid, kuid see võib võtta tunde.

Kui kasutate cPaneli, saate tavaliselt e-kirja sellise sõnumiga:

(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

Võttes DISABLE_WP_CRON lubatud wp-config.php, ikka veel saada "Killed" sõnum cPanel, tähendab, et seal on mingi muu protsess või konfiguratsiooni (et ma ei ole veel avastanud), mis üritab käivitada wp-cron.php, ja süsteem lõpetab selle tõttu liigne tarbimine ressursse (mälu, CPU, jne.).

Täna olen uurinud natuke rohkem ja jälginud protsessori tarbimist. Selleks kasutasin SSH ja WP-CLI juurdepääsu LucusHost'i poolt pakutava cPaneli SSH ja WP-CLI terminali brauseris.

Kui teie hosting võimaldab seda, peate juurdepääsu saamiseks minema cPaneli menüüsse Advanced/Terminal. Kui teie blogi failid asuvad kaustas public_html, peate pääsema sinna juurde järgmiselt:

cd public_html

Seejärel sisestage käimasolevate protsesside vaatamiseks

top

Ja te peaksite nägema midagi sellist:

Minu puhul leian ma lsphp protsesside laviini, mis sööb täielikult protsessori ära.

Sul piisab, kui avad WordPressi haldusala, et näha nelja või viit LiteSpeed-protsessi(lsphp), mis suletakse mõne sekundi pärast. See on normaalne, LiteSpeed'i lsphp protsessid on osa tema arhitektuurist, et PHP-ühendusi tõhusalt käsitleda.

Kuid midagi on valesti, kui pärast uue postituse avaldamist (mõnikord piisab ka lihtsalt ühe juba avaldatud postituse muutmisest) käivituvad need protsessid nii arvuliselt kui ka protsessori kasutuse poolest ja neid ei vabastata, jättes saidi surnuks.

Esimene erakorraline meede lehe blokeeringu kõrvaldamiseks on nende "kinni jäänud" protsesside tapmine, mis ei lahenda blokeeringu põhjustavat probleemi, kuid saite juurdepääsu taastatakse.

pkill -u TuNombreDeUsuario lsphp

Kui soovite, võite konkreetse protsessi tappa selle PID-i abil, kuigi sellest ei ole tõenäoliselt palju kasu, sest paljud protsessid suletakse ja avatakse lühikeste ajavahemike järel.

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

Tavaliselt käivitab LiteSpeed vaikimisi need neli ülesannet iga minut, sõltuvalt teie pluginate konfiguratsioonist ja kasutatavatest valikutest.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

Kaks esimest, imgoptm_pull ja ccss, on rasked ülesanded, mis mõnikord põhjustavad ajakatkestusi (eriti jagatud hostingu puhul), samas kui ucss ja lqip on kergemad ülesanded.

Nii et esimene asi, mida ma proovisin, on blokeerida LiteSpeed automaatne taastamine, keelates automaatse Croni juhtimise LiteSpeedis, selleks lisasin selle wp-config.php-sse

// Deshabilita la gestión automática de Cron en LiteSpeed
define('LITESPEED_DISABLE_CACHE_PURGE_CRON', true);
define('LITESPEED_DISABLE_AUTOUPDATE_CRON', true);

Seejärel, järgmise funktsiooniga, mis on lisatud functions.php-sse, sunnite eemaldama 1-minutilise intervalli ja muudate selle 1 kord päevas, jaotades need ülesanded erinevatel aegadel, et vältida ülemäärast protsessori tarbimist. Sõltuvalt teie blogi liiklusest võite määrata need tunnid näiteks hommikuti erinevatele kellaaegadele.

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

Kui need muudatused on rakendatud, kontrollige, et need toimiksid, vastavalt Advanced Database Cleaner Pro pluginale rakendatakse neid muudatusi. Võite kontrollida ka Wp Crontroliga.

Eeldades, et te ei kasuta WordPressi virtuaalset CRONi, on protsessori tarbimise edasiseks vähendamiseks lisatud uus CRON, mis suurendab sagedust 30 minutini, väldib flokiga dubleerimist ja vähendab serveri koormust.

*/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üüd, kui me käivitame wp croni ajakava nimekirja, leiame, et litespeed_filter , või mõni muu filter, ei tööta iga 60 sekundi järel.

See on vaid esimene lähenemisviis. Nüüd pean ma jätkama testimist ja jälgima ressursikasutust erinevate stsenaariumide korral. Vähemalt praegu ei ole ma näinud, et leht uue postituse avaldamisel uuesti kokku kukuks.

Kui kellelgi on sama probleem ja on leidnud lõpliku lahenduse, oleks vihje teretulnud.