Procesele LiteSpeed blochează pagina după publicarea unei postări

Mă confrunt de ceva timp cu o problemă pentru care nu am găsit încă o soluție definitivă.

Problema este că, imediat după publicarea unei postări, consumul de CPU crește vertiginos, precum și numărul de procese, lăsând site-ul practic inaccesibil pentru perioade lungi de timp.

Aceasta este o problemă gravă, deoarece abonații vor primi o notificare cu privire la o nouă publicație, pe care nu o vor putea citi deoarece pagina nu se rezolvă, ca să nu mai vorbim de ceea ce înseamnă pentru poziționare să aibă pagina căzută frecvent.

După un anumit timp, sistemul va opri procesele, dar acest lucru poate dura ore întregi.

Dacă utilizați cPanel, veți primi de obicei un e-mail cu un mesaj ca acesta:

(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

Având DISABLE_WP_CRON activat în wp-config.php, dar primind mesajul "Killed" din cPanel, înseamnă că există un alt proces sau o altă configurație (pe care nu am descoperit-o încă) care încearcă să ruleze wp-cron.php, iar sistemul îl oprește din cauza consumului excesiv de resurse (memorie, CPU etc.).

Astăzi am investigat un pic mai mult și am monitorizat consumul de CPU. Pentru aceasta, am folosit terminalul din browser pentru SSH și accesul WP-CLI oferit de LucusHost în cPanel.

Dacă găzduirea dvs. permite acest lucru, pentru acces trebuie să mergeți la Advanced/Terminal în cPanel. Dacă fișierele blogului dvs. sunt în folderul public_html, trebuie să îl accesați astfel:

cd public_html

Apoi, pentru a vedea procesele care rulează, tastați

top

Și ar trebui să vedeți ceva de genul acesta:

În cazul meu am găsit o avalanșă de procese lsphp care consumă complet CPU.

Trebuie doar să deschideți zona de administrare WordPress pentru a vedea patru sau cinci procese LiteSpeed(lsphp) care se închid după câteva secunde. Acest lucru este normal, procesele lsphp ale LiteSpeed fac parte din arhitectura sa pentru a gestiona eficient conexiunile PHP.

Cu toate acestea, ceva nu este în regulă atunci când, după publicarea unei noi postări (uneori este suficient doar să editați una deja publicată), aceste procese sunt declanșate atât ca număr, cât și ca utilizare CPU și nu sunt eliberate, lăsând site-ul mort.

Prima măsură de urgență pentru deblocarea paginii este uciderea acelor procese "blocate", ceea ce nu rezolvă problema care cauzează blocajul, dar vă reda accesul la site.

pkill -u TuNombreDeUsuario lsphp

Dacă preferați, puteți opri un anumit proces folosind PID-ul acestuia, deși acest lucru probabil nu vă va ajuta prea mult, deoarece multe procese sunt închise și deschise la intervale scurte.

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

În mod normal, implicit, LiteSpeed execută aceste patru sarcini la fiecare minut, în funcție de configurația pluginului dvs. și de opțiunile pe care le utilizați.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

Primele două, imgoptm_pull și ccss, sunt sarcini grele care uneori cauzează timeout-uri (în special pe hosting partajat), în timp ce ucss și lqip sunt sarcini mai ușoare.

Deci, primul lucru pe care l-am încercat este să blochez regenerarea automată a LiteSpeed prin dezactivarea gestionării automate a Cron în LiteSpeed, pentru care am adăugat acest lucru în 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);

Apoi, cu următoarea funcție adăugată în functions.php, forțați eliminarea intervalului de 1 minut și îl schimbați cu 1 dată pe zi, distribuind aceste sarcini la ore diferite pentru a evita consumul excesiv de CPU. În funcție de traficul blogului dumneavoastră, puteți seta aceste ore la momente diferite ale dimineții, de exemplu.

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

Odată ce aceste modificări sunt aplicate, verificați dacă acestea funcționează, conform pluginului Advanced Database Cleaner Pro, aceste modificări sunt aplicate. De asemenea, puteți verifica cu Wprontrol.

Presupunând că nu utilizați CRON-ul virtual nativ WordPress, pentru a ușura și mai mult consumul de CPU, este adăugat un nou CRON care crește frecvența la 30 de minute, evită duplicările cu flok și reduce încărcarea serverului.

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

Acum, când rulăm lista de programări wp cron, constatăm că filtrul litespeed_filter , sau orice alt filtru, nu rulează la fiecare 60 de secunde.

Aceasta este doar o primă abordare. Acum trebuie să continui să testez și să monitorizez utilizarea resurselor în diferite scenarii. Cel puțin, deocamdată, nu am mai văzut că pagina se blochează din nou la publicarea unei noi postări.

Dacă cineva are aceeași problemă și a găsit o soluție definitivă, un sfat ar fi apreciat.