Už nejaký čas sa zaoberám problémom, na ktorý som zatiaľ nenašiel definitívne riešenie.
Problémom je, že hneď po uverejnení príspevku prudko stúpne spotreba procesora a počet procesov, takže stránka je prakticky dlhý čas nedostupná.
Ide o vážny problém, pretože predplatitelia dostanú oznámenie o novej publikácii, ktorú si nebudú môcť prečítať, pretože stránka sa nevyrieši, nehovoriac o tom, čo to znamená pre umiestnenie, keď sa stránka často vypína.
Po určitom čase systém procesy nakoniec ukončí, ale môže to trvať aj niekoľko hodín.
Ak používate cPanel, zvyčajne dostanete e-mail s touto správou:
(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
Po DISABLE_WP_CRON
povolený v wp-config.php
, stále dostáva správu "Zabitý" z cPanel, znamená, že existuje nejaký iný proces alebo konfigurácia (že som ešte neobjavili), ktorý sa snaží spustiť wp-cron.php
, a systém je ukončenie z dôvodu nadmernej spotreby zdrojov (pamäť, CPU, atď.).
Dnes som skúmal trochu viac a sledoval som spotrebu procesora. Použil som na to terminál v prehliadači pre SSH a WP-CLI prístup, ktorý ponúka LucusHost v cPanel.
Ak to váš hosting umožňuje, pre prístup k nemu musíte prejsť do časti Rozšírené/Terminál v paneli cPanel. Ak sa súbory vášho blogu nachádzajú v priečinku public_html, musíte k nemu pristupovať takto:
cd public_html
Ak chcete zobraziť spustené procesy, zadajte
top
A mali by ste vidieť niečo podobné:

V mojom prípade som našiel lavínu procesov lsphp, ktoré úplne vyčerpali procesor.
Stačí otvoriť oblasť administrácie WordPress a uvidíte štyri alebo päť procesov LiteSpeed(lsphp), ktoré sa po niekoľkých sekundách zatvoria. Je to normálne, procesy LiteSpeed lsphp sú súčasťou jeho architektúry na efektívne spracovanie pripojení PHP.
Niečo však nie je v poriadku, keď sa po publikovaní nového príspevku (niekedy stačí len upraviť už publikovaný príspevok) spustí množstvo týchto procesov aj ich využitie procesora a neuvoľnia sa, čím sa stránka stane mŕtvou.
Prvým núdzovým opatrením na odblokovanie stránky je zabitie týchto "zaseknutých" procesov, čím sa síce nevyrieši problém, ktorý zablokovanie spôsobuje, ale obnoví sa prístup na stránku.
pkill -u TuNombreDeUsuario lsphp
Ak chcete, môžete konkrétny proces zabiť pomocou jeho PID, aj keď to pravdepodobne nebude veľmi užitočné, pretože mnohé procesy sa zatvárajú a otvárajú v krátkych intervaloch.
# Detiene procesos con alto %CPU (ejemplo para detener el PID 7026)
kill -9 7026
V predvolenom nastavení spúšťa LiteSpeed tieto štyri úlohy každú minútu v závislosti od konfigurácie vášho doplnku a možností, ktoré používate.
litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip
Prvé dve, imgoptm_pull
a ccss
, sú náročné úlohy, ktoré niekedy spôsobujú timeouty (najmä na zdieľanom hostingu), zatiaľ čo ucss a lqip sú ľahšie úlohy.
Takže prvá vec, ktorú som sa snažil je zablokovať automatickú regeneráciu LiteSpeed zakázaním automatickej správy Cron v LiteSpeed, za to som pridal to v 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);
Potom pomocou nasledujúcej funkcie pridanej do súboru functions.php vynútite odstránenie 1 minútového intervalu a zmeníte ho na 1 krát za deň, pričom tieto úlohy rozdelíte v rôznych časoch, aby ste zabránili nadmernej spotrebe CPU. V závislosti od návštevnosti vášho blogu môžete tieto hodiny nastaviť napríklad v rôznych ranných hodinách.
/**
* 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);
Po aplikácii týchto zmien skontrolujte, či sú funkčné, podľa pluginu Advanced Database Cleaner Pro sa tieto zmeny aplikujú. Kontrolu môžete vykonať aj pomocou nástroja Wp Crontrol.

Za predpokladu, že nepoužívate natívny virtuálny CRON WordPress, je na ďalšie zníženie spotreby CPU pridaný nový CRON, ktorý zvyšuje frekvenciu na 30 minút, zabraňuje duplikátom s flokom a znižuje zaťaženie servera.
*/30 * * * * /usr/bin/flock -xn /tmp/wp-cron.lock /usr/local/bin/php /home/TuNombreDeUsuario/public_html/wp-cron.php > /dev/null 2>&1
Teraz, keď spustíme zoznam plánov wp cron, zistíme, že filter litespeed_filter , alebo akýkoľvek iný filter, sa nespúšťa každých 60 sekúnd.

Toto je len prvý prístup. Teraz musím pokračovať v testovaní a monitorovaní využitia zdrojov v rôznych scenároch. Aspoň som zatiaľ nezaznamenal, že by stránka pri publikovaní nového príspevku opäť spadla.
Ak má niekto rovnaký problém a našiel definitívne riešenie, oceníme tip.