A LiteSpeed folyamatok blokkolják az oldalt a poszt közzététele után

Már egy ideje foglalkozom egy problémával, amelyre még nem találtam végleges megoldást.

A probléma az, hogy közvetlenül egy poszt közzététele után a CPU-fogyasztás az egekbe szökik, ahogy a folyamatok száma is, így az oldal hosszú időre gyakorlatilag elérhetetlenné válik.

Ez komoly probléma, mivel az előfizetők értesítést kapnak egy új kiadványról, amelyet nem tudnak majd elolvasni, mert az oldal nem oldódik meg, arról nem is beszélve, hogy mit jelent a pozicionálás szempontjából, hogy az oldal gyakran leáll.

Egy idő után a rendszer végül megöli a folyamatokat, de ez akár órákig is eltarthat.

Ha cPanelt használ, általában egy ilyen üzenetet tartalmazó e-mailt kap:

(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

Miután DISABLE_WP_CRON engedélyezve a wp-config.php, még mindig kap a "Megölt" üzenet a cPanel, azt jelenti, hogy van valami más folyamat vagy konfiguráció (hogy még nem fedeztem fel), amely megpróbálja futtatni wp-cron.php, és a rendszer megszünteti azt miatt túlfogyasztása az erőforrások (memória, CPU, stb).).

Ma egy kicsit jobban utánanéztem, és figyeltem a CPU-fogyasztást. Ehhez a böngészőben lévő terminált használtam az SSH és a LucusHost által a cPanelben kínált WP-CLI hozzáféréshez.

Ha a tárhelyed lehetővé teszi, a hozzáféréshez a cPanelben a Speciális/Terminál menüpontra kell menned. Ha a blog fájljai a public_html mappában vannak, akkor így kell hozzáférnie:

cd public_html

Ezután a futó folyamatok megtekintéséhez írja be a következőt

top

És valami ilyesmit kell látnod:

Az én esetemben az lsphp folyamatok lavináját találom, amelyek teljesen felemésztik a CPU-t.

Elég megnyitni a WordPress adminisztrációs területét, hogy négy vagy öt LiteSpeed folyamatot(lsphp) lássunk, amelyek néhány másodperc után bezárulnak. Ez normális, a LiteSpeed lsphp folyamatai az architektúra részét képezik a PHP-kapcsolatok hatékony kezeléséhez.

Azonban valami nincs rendben, amikor egy új bejegyzés közzététele után (néha elég csak egy már közzétettet szerkeszteni) ezek a folyamatok mind számban, mind CPU-használatban elindulnak, és nem szabadulnak fel, így az oldal halott marad.

Az első vészintézkedés az oldal blokkolásának feloldására a "beragadt" folyamatok megölése, ami nem oldja meg a blokkolást okozó problémát, de visszanyeri a hozzáférést az oldalhoz.

pkill -u TuNombreDeUsuario lsphp

Ha szeretné, akkor egy adott folyamatot a PID-je segítségével is megölhet, bár ez valószínűleg nem sokat segít, mivel sok folyamatot rövid időközönként bezárnak és megnyitnak.

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

Normális esetben a LiteSpeed alapértelmezés szerint percenként futtatja ezt a négy feladatot, a plugin konfigurációjától és az Ön által használt opcióktól függően.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

Az első kettő, az imgoptm_pull és a ccss nehéz feladatok, amelyek néha időkiesést okoznak (különösen megosztott tárhelyen), míg az ucss és az lqip könnyebb feladatok.

Tehát az első dolog, amit megpróbáltam, hogy blokkolja a LiteSpeed automatikus regenerálódását a LiteSpeed automatikus Cron-kezelésének letiltásával, ehhez ezt adtam hozzá a wp-config.php fájlhoz .

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

Ezután a következő, a functions.php fájlba beillesztett függvénnyel kikényszerítheti az 1 perces intervallum eltávolítását, és megváltoztathatja azt napi 1 alkalomra, elosztva ezeket a feladatokat különböző időpontokban, hogy elkerülje a túlzott CPU-fogyasztást. A blogod forgalmától függően beállíthatod ezeket az órákat például reggel különböző időpontokra.

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

Miután ezeket a módosításokat alkalmazza, ellenőrizze, hogy működnek-e, az Advanced Database Cleaner Pro plugin szerint ezek a módosítások alkalmazásra kerülnek. A Wp Crontrol segítségével is ellenőrizheti.

Feltételezve, hogy nem a natív WordPress virtuális CRON-t használod, a CPU-fogyasztás további csökkentése érdekében egy új CRON-t adunk hozzá, amely 30 percre növeli a gyakoriságot, elkerüli a flokkal való duplikációkat és csökkenti a szerver terhelést.

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

Most, amikor futtatjuk a wp cron ütemezési listát, azt látjuk, hogy a litespeed_filter , vagy bármely más szűrő nem fut 60 másodpercenként.

Ez csak egy első megközelítés. Mostantól folyamatosan tesztelnem kell, és figyelemmel kell kísérnem az erőforrás-felhasználást különböző forgatókönyvek esetén. Legalábbis egyelőre nem láttam, hogy az oldal újra összeomlott volna egy új bejegyzés közzétételekor.

Ha valakinek ugyanez a problémája, és talált már végleges megoldást, egy tippet szívesen fogadnék.