Процеси 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 і отримання повідомлення "Killed" від cPanel означає, що існує якийсь інший процес або конфігурація (яку я ще не виявив), який намагається запустити wp-cron.php, і система завершує його через надмірне споживання ресурсів (пам'яті, процесора і т.д.).

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

Якщо ваш хостинг дозволяє, то для доступу до нього потрібно перейти в Розширені/Термінал в 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 секунд.

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

Якщо хтось зіткнувся з такою ж проблемою і знайшов остаточне рішення, ми будемо вдячні за підказку.