Процесите на LiteSpeed блокират страницата след публикуване на публикация

От известно време се занимавам с проблем, за който все още не съм намерил окончателно решение.

Проблемът е, че непосредствено след публикуването на публикация потреблението на процесора нараства, както и броят на процесите, което прави сайта практически недостъпен за дълги периоди от време.

Това е сериозен проблем, тъй като абонатите ще получат известие за нова публикация, която няма да могат да прочетат, тъй като страницата не се разрешава, да не говорим какво означава за позиционирането честото сваляне на страницата.

След известно време системата ще прекрати процесите, но това може да отнеме часове.

Ако използвате контролния панел cPanel, обикновено ще получите имейл със следното съобщение:

(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

След като DISABLE_WP_CRON е активиран в wp-config.php, все още получавате съобщението "Убито" от контролния панел, означава, че има някакъв друг процес или конфигурация (която все още не съм открил), който се опитва да стартира wp-cron.php, и системата го прекратява поради прекомерна консумация на ресурси (памет, процесор и т.н.).

Днес проучих малко повече и наблюдавах потреблението на процесора. За тази цел използвах терминала в браузъра за SSH и WP-CLI достъп, предлаган от LucusHost в cPanel.

Ако хостингът ви го позволява, за да получите достъп, трябва да отидете в Advanced/Terminal в контролния панел cPanel. Ако файловете на блога ви се намират в папката public_html, трябва да получите достъп до нея по следния начин:

cd public_html

След това, за да видите изпълняваните процеси, въведете

top

И трябва да видите нещо подобно:

В моя случай откривам лавина от процеси на lsphp, които напълно изяждат процесора.

Достатъчно е да отворите областта за администриране на WordPress, за да видите четири или пет LiteSpeed процеса(lsphp), които се затварят след няколко секунди. Това е нормално, процесите lsphp на LiteSpeed са част от нейната архитектура за ефективна обработка на PHP връзките.

Нещо обаче не е наред, когато след публикуване на нова публикация (понякога е достатъчно само да редактирате вече публикувана) тези процеси се задействат както по брой, така и по използване на процесора и не се освобождават, оставяйки сайта мъртъв.

Първата спешна мярка за деблокиране на страницата е да се убият тези "заседнали" процеси, което не решава проблема, причиняващ блокирането, но възстановява достъпа до сайта.

pkill -u TuNombreDeUsuario lsphp

Ако предпочитате, можете да убиете определен процес, като използвате неговия PID, въпреки че това вероятно няма да ви е от полза, тъй като много процеси се затварят и отварят на кратки интервали.

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

Обикновено по подразбиране LiteSpeed изпълнява тези четири задачи на всяка минута в зависимост от конфигурацията на вашия плъгин и използваните от вас опции.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

Първите две, imgoptm_pull и ccss, са тежки задачи, които понякога причиняват прекъсвания (особено на споделен хостинг), докато ucss и lqip са по-леки задачи.

Така че първото нещо, което опитах, е да блокира автоматичното регенериране на LiteSpeed чрез деактивиране на автоматичното управление на Cron в LiteSpeed, за това добавих това в 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);

След това със следната функция, добавена във functions.php, премахвате интервала от 1 минута и го променяте на 1 път на ден, като разпределяте тези задачи по различно време, за да избегнете прекомерното потребление на процесора. В зависимост от трафика на вашия блог можете да зададете тези часове в различни часове сутрин, например.

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

След като тези промени бъдат приложени, проверете дали те работят, според плъгина Advanced Database Cleaner Pro тези промени се прилагат. Можете също така да проверите с Wp Crontrol.

Ако приемем, че не използвате виртуалния CRON на WordPress, за да намалите още повече консумацията на процесора, е добавен нов CRON, който увеличава честотата до 30 минути, избягва дублирането с flok и намалява натоварването на сървъра.

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

Сега, когато стартираме списъка с графика на wp cron, откриваме, че филтърът litespeed_filter или който и да е друг филтър не се изпълнява на всеки 60 секунди.

Това е само първи подход. Сега трябва да продължа да тествам и да наблюдавам използването на ресурсите при различни сценарии. Поне засега не съм виждал страницата да се срива отново при публикуване на нова публикация.

Ако някой има същия проблем и е намерил окончателно решение, ще бъдем благодарни за съвет.