"LiteSpeed" procesai užblokuoja puslapį po to, kai paskelbiamas pranešimas

Jau kurį laiką susiduriu su problema, kurios galutinio sprendimo dar neradau.

Problema ta, kad iškart po pranešimo paskelbimo išauga procesoriaus sąnaudos ir procesų skaičius, todėl svetainė ilgą laiką tampa praktiškai nepasiekiama.

Tai rimta problema, nes prenumeratoriai gaus pranešimą apie naują leidinį, kurio negalės perskaityti, nes puslapis nebus išspręstas, jau nekalbant apie tai, ką reiškia, kad puslapis dažnai neveikia.

Po tam tikro laiko sistema galiausiai išjungs procesus, tačiau tai gali užtrukti kelias valandas.

Jei naudojate "cPanel", paprastai gausite el. laišką su tokiu pranešimu:

(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

Turint DISABLE_WP_CRON įjungtas wp-config.php, vis dar gaunate "Nužudytas" pranešimą iš cPanel, reiškia, kad yra kažkoks kitas procesas ar konfigūracija (kad aš dar neatrado), kad bando paleisti wp-cron.php, ir sistema yra nutraukti jį dėl pernelyg didelio išteklių (atminties, CPU, ir tt).

Šiandien aš ištyriau šiek tiek daugiau ir stebėjau procesoriaus suvartojimą. Tam naudojau naršyklėje esantį terminalą SSH ir WP-CLI prieigai, kurią " LucusHost" siūlo "cPanel".

Jei jūsų priegloba tai leidžia, norėdami prisijungti, turite eiti į " Advanced/Terminal" cPanel. Jei tinklaraščio failai yra aplanke public_html, turite jį pasiekti taip:

cd public_html

Tada, norėdami peržiūrėti vykdomus procesus, įveskite

top

Turėtumėte pamatyti kažką panašaus į tai:

Mano atveju aš randu laviną lsphp procesų, kurie visiškai suvalgo procesorių.

Užtenka atidaryti "WordPress" administravimo sritį, kad pamatytumėte keturis ar penkis "LiteSpeed" procesus(lsphp), kurie užsidaro po kelių sekundžių. Tai normalu, nes "LiteSpeed" lsphp procesai yra jos architektūros dalis, skirta efektyviai tvarkyti PHP ryšius.

Tačiau kažkas negerai, kai paskelbus naują įrašą (kartais užtenka tik redaguoti jau paskelbtą) šie procesai suaktyvėja tiek skaičiumi, tiek procesoriaus panaudojimu ir nėra paleidžiami, todėl svetainė tampa negyva.

Pirmoji neatidėliotina priemonė puslapiui atblokuoti - nužudyti tuos "užstrigusius" procesus, tačiau tai neišsprendžia problemos, dėl kurios puslapis užblokuotas, tačiau atgaunama prieiga prie svetainės.

pkill -u TuNombreDeUsuario lsphp

Jei norite, galite nužudyti konkretų procesą naudodami jo PID, nors tai tikriausiai nebus labai naudinga, nes daugelis procesų uždaromi ir atidaromi trumpais intervalais.

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

Paprastai pagal numatytuosius nustatymus "LiteSpeed" šias keturias užduotis atlieka kas minutę, priklausomai nuo jūsų įskiepio konfigūracijos ir naudojamų parinkčių.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

Pirmosios dvi užduotys, imgoptm_pull ir ccss, yra sunkios ir kartais sukelia laiko trukdžius (ypač bendroje priegloboje), o ucss ir lqip yra lengvesnės užduotys.

Taigi pirmas dalykas, kurį bandžiau yra blokuoti automatinį regeneraciją LiteSpeed išjungti automatinį Cron valdymas LiteSpeed, kad aš pridėjau tai 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);

Tada, naudodami šią funkciją, pridėtą į functions.php, pašalinkite 1 minutės intervalą ir pakeiskite jį į 1 kartą per dieną, paskirstydami šias užduotis skirtingu laiku, kad išvengtumėte pernelyg didelio procesoriaus suvartojimo. Priklausomai nuo tinklaraščio lankomumo, šias valandas galite nustatyti skirtingu laiku, pavyzdžiui, ryte.

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

Kai šie pakeitimai bus pritaikyti, patikrinkite, ar jie veikia, nes pagal " Advanced Database Cleaner Pro" įskiepį šie pakeitimai yra taikomi. Taip pat galite patikrinti naudodami Wp Crontrol.

Darant prielaidą, kad nenaudojate "WordPress" virtualiojo CRON, siekiant dar labiau sumažinti procesoriaus suvartojimą, pridedamas naujas CRON, kuris padidina dažnumą iki 30 minučių, leidžia išvengti pasikartojimų su flok ir sumažina serverio apkrovą.

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

Dabar, kai paleidžiame wp cron tvarkaraščio sąrašą, pamatysime, kad litespeed_filter arba bet kuris kitas filtras neveikia kas 60 sekundžių.

Tai tik pirmas būdas. Dabar turiu toliau bandyti ir stebėti išteklių naudojimą pagal įvairius scenarijus. Bent jau kol kas nepastebėjau, kad puslapis vėl sugestų, kai skelbiamas naujas pranešimas.

Jei kas nors susidūrė su ta pačia problema ir rado galutinį sprendimą, būtų dėkingi už patarimą.