Процессы 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

Если в файле wp-config.php включена опция DISABLE_WP_CRON, то сообщение "Killed" из cPanel все равно появляется, значит, есть какой-то другой процесс или конфигурация (которую я еще не обнаружил), который пытается запустить wp-cron.php, и система завершает его из-за перерасхода ресурсов (памяти, процессора и т.д.).

Сегодня я исследовал немного больше и следил за потреблением процессора. Для этого я использовал терминал в браузере для SSH и WP-CLI доступ, предлагаемый LucusHost в cPanel.

Если ваш хостинг позволяет это сделать, для доступа необходимо перейти в Advanced/Terminal в cPanel. Если файлы вашего блога находятся в папке public_html, вы должны получить доступ к ней следующим образом:

cd public_html

Затем, чтобы увидеть запущенные процессы, введите

top

И вы должны увидеть что-то вроде этого:

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

Достаточно открыть область администрирования WordPress, чтобы увидеть четыре или пять процессов LiteSpeed(lsphp), которые закрываются через несколько секунд. Это нормально, процессы LiteSpeed lsphp являются частью архитектуры для эффективной обработки 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 секунд.

Это только первый подход. Теперь мне нужно продолжать тестировать и следить за использованием ресурсов в различных сценариях. По крайней мере, на данный момент я не видел, чтобы страница снова падала при публикации нового сообщения.

Если у кого-то возникла такая же проблема и он нашел окончательное решение, подскажите, пожалуйста.