LiteSpeed-prosessit estävät sivun julkaisun jälkeen.

Olen jo jonkin aikaa käsitellyt ongelmaa, johon en ole vielä löytänyt lopullista ratkaisua.

Ongelmana on se, että heti postauksen julkaisemisen jälkeen suorittimen kulutus nousee pilviin ja prosessien määrä kasvaa, jolloin sivusto on käytännössä saavuttamattomissa pitkiä aikoja.

Tämä on vakava ongelma, sillä tilaajat saavat ilmoituksen uudesta julkaisusta, jota he eivät pysty lukemaan, koska sivu ei ratkea, puhumattakaan siitä, mitä se tarkoittaa sivun sijainnin kannalta, kun se on usein alhaalla.

Jonkin ajan kuluttua järjestelmä lopulta lopettaa prosessit, mutta se voi kestää tunteja.

Jos käytät cPanelia, saat yleensä sähköpostiviestin, jossa on tällainen viesti:

(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

Ottaa DISABLE_WP_CRON käytössä wp-config.php, silti vastaanottaa "Killed" viesti cPanel, tarkoittaa, että on olemassa jokin muu prosessi tai kokoonpano (että en ole vielä löytänyt), joka yrittää ajaa wp-cron.php, ja järjestelmä lopettaa sen takia resurssien ylikulutus (muisti, CPU, jne.).).

Tänään olen tutkinut asiaa hieman enemmän ja seurannut suorittimen kulutusta. Tätä varten käytin selaimessa olevaa päätelaitetta SSH:n ja WP-CLI:n käyttämiseen, jonka LucusHost tarjoaa cPanelissa.

Jos hosting sallii sen, sinun on mentävä cPanelissa kohtaan Advanced/Terminal. Jos blogisi tiedostot ovat public_html-kansiossa, sinun on päästävä sinne seuraavasti:

cd public_html

Jos haluat nähdä käynnissä olevat prosessit, kirjoita

top

Ja sinun pitäisi nähdä jotain tällaista:

Omassa tapauksessani löydän vyöryn lsphp-prosesseja, jotka syövät suorittimen kokonaan.

Sinun tarvitsee vain avata WordPressin hallinta-alue nähdäksesi neljä tai viisi LiteSpeed-prosessia(lsphp), jotka sulkeutuvat muutaman sekunnin kuluttua. Tämä on normaalia, LiteSpeedin lsphp-prosessit ovat osa sen arkkitehtuuria PHP-yhteyksien käsittelemiseksi tehokkaasti.

Jotain on kuitenkin vialla, kun uuden viestin julkaisemisen jälkeen (joskus riittää, että muokkaat jo julkaistua viestiä) nämä prosessit käynnistyvät sekä lukumäärän että suorittimen käytön osalta, eikä niitä vapauteta, jolloin sivusto on kuollut.

Ensimmäinen hätätoimenpide sivun eston poistamiseksi on tappaa nämä "jumissa olevat" prosessit, mikä ei ratkaise eston aiheuttavaa ongelmaa, mutta saat takaisin pääsyn sivustolle.

pkill -u TuNombreDeUsuario lsphp

Voit halutessasi tappaa tietyn prosessin sen PID:n avulla, vaikka tästä ei todennäköisesti ole paljon hyötyä, koska monet prosessit suljetaan ja avataan lyhyin väliajoin.

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

Normaalisti LiteSpeed suorittaa oletusarvoisesti nämä neljä tehtävää minuutin välein riippuen lisäosasi konfiguraatiosta ja käyttämistäsi asetuksista.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

Kaksi ensimmäistä, imgoptm_pull ja ccss, ovat raskaita tehtäviä, jotka joskus aiheuttavat aikakatkaisuja (erityisesti jaetussa hostingissa), kun taas ucss ja lqip ovat kevyempiä tehtäviä.

Joten ensimmäinen asia, jota yritin, on estää LiteSpeedin automaattinen regenerointi poistamalla automaattinen Cron-hallinta LiteSpeedissä, jota varten lisäsin tämän wp-config.php:hen .

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

Seuraavalla functions.php:hen lisätyllä funktiolla pakotat poistamaan 1 minuutin aikavälin ja muutat sen 1 kerran päivässä jakamalla nämä tehtävät eri aikoina, jotta vältetään liiallinen suorittimen kulutus. Blogisi liikenteestä riippuen voit asettaa nämä tunnit esimerkiksi eri aikoihin aamulla.

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

Kun nämä muutokset on tehty, tarkista, että ne toimivat, sillä Advanced Database Cleaner Pro -lisäosan mukaan nämä muutokset on tehty. Voit myös tarkistaa Wp Crontrolin avulla.

Olettaen, että et käytä natiivia WordPressin virtuaalista CRONia, CPU-kulutuksen keventämiseksi lisätään uusi CRON, joka lisää taajuutta 30 minuuttiin, välttää päällekkäisyyksiä flokin kanssa ja vähentää palvelimen kuormitusta.

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

Nyt, kun ajamme wp cron -aikataululuettelon, huomaamme, että litespeed_filter tai mikään muukaan suodatin ei ole käynnissä 60 sekunnin välein.

Tämä on vasta ensimmäinen lähestymistapa. Nyt minun on testattava ja seurattava resurssien käyttöä eri skenaarioissa. Ainakaan toistaiseksi en ole nähnyt sivun kaatuvan uudelleen uutta viestiä julkaistessani.

Jos jollain on sama ongelma ja hän on löytänyt lopullisen ratkaisun, vinkki olisi tervetullut.