Procesy LiteSpeed blokują stronę po opublikowaniu posta

Od jakiegoś czasu borykam się z problemem, dla którego nie znalazłem jeszcze ostatecznego rozwiązania.

Problem polega na tym, że zaraz po opublikowaniu postu zużycie procesora gwałtownie wzrasta, a liczba procesów pozostawia witrynę praktycznie niedostępną przez długi czas.

Jest to poważny problem, ponieważ subskrybenci otrzymają powiadomienie o nowej publikacji, której nie będą mogli przeczytać, ponieważ strona się nie rozwiązuje, nie wspominając już o tym, co oznacza dla pozycjonowania częste wyłączanie strony.

Po pewnym czasie system ostatecznie zabije procesy, ale może to potrwać kilka godzin.

Jeśli korzystasz z cPanel, zazwyczaj otrzymasz wiadomość e-mail z takim komunikatem:

(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 włączeniu DISABLE_WP_CRON w wp-config.php, nadal otrzymując komunikat "Zabity" z cPanel, oznacza to, że istnieje inny proces lub konfiguracja (której jeszcze nie odkryłem), która próbuje uruchomić wp-cron.php, a system kończy go z powodu nadmiernego zużycia zasobów (pamięci, procesora itp.).

Dzisiaj zbadałem nieco więcej i monitorowałem zużycie procesora. W tym celu wykorzystałem terminal w przeglądarce do SSH oraz dostęp do WP-CLI oferowany przez LucusHost w cPanelu.

Jeśli twój hosting na to pozwala, aby uzyskać dostęp, musisz przejść do Advanced/Terminal w cPanel. Jeśli pliki bloga znajdują się w folderze public_html, należy uzyskać do niego dostęp w następujący sposób:

cd public_html

Następnie, aby zobaczyć uruchomione procesy, wpisz

top

Powinieneś zobaczyć coś takiego:

W moim przypadku znajduję lawinę procesów lsphp, które całkowicie pochłaniają procesor.

Wystarczy otworzyć obszar administracyjny WordPress, aby zobaczyć cztery lub pięć procesów LiteSpeed(lsphp), które zamykają się po kilku sekundach. Jest to normalne, procesy lsphp LiteSpeed są częścią jego architektury do wydajnej obsługi połączeń PHP.

Jednak coś jest nie tak, gdy po opublikowaniu nowego posta (czasami wystarczy tylko edytować już opublikowany), procesy te są uruchamiane zarówno pod względem liczby, jak i wykorzystania procesora i nie są zwalniane, pozostawiając witrynę martwą.

Pierwszym awaryjnym sposobem na odblokowanie strony jest zabicie tych "zablokowanych" procesów, co nie rozwiązuje problemu powodującego blokadę, ale pozwala odzyskać dostęp do strony.

pkill -u TuNombreDeUsuario lsphp

Jeśli wolisz, możesz zabić konkretny proces za pomocą jego PID, choć prawdopodobnie nie przyniesie to wiele korzyści, ponieważ wiele procesów jest zamykanych i otwieranych w krótkich odstępach czasu.

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

Zwykle, domyślnie, LiteSpeed uruchamia te cztery zadania co minutę, w zależności od konfiguracji wtyczki i używanych opcji.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

Pierwsze dwa, imgoptm_pull i ccss, są ciężkimi zadaniami, które czasami powodują przekroczenie limit u czasu (szczególnie na hostingu współdzielonym), podczas gdy ucss i lqip są lżejszymi zadaniami.

Pierwszą rzeczą, którą wypróbowałem, było zablokowanie automatycznej regeneracji LiteSpeed poprzez wyłączenie automatycznego zarządzania Cronem w LiteSpeed, w tym celu dodałem to w 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);

Następnie za pomocą poniższej funkcji dodanej w pliku functions.php można wymusić usunięcie 1-minutowego interwału i zmienić go na 1 raz dziennie, rozdzielając te zadania o różnych porach, aby uniknąć nadmiernego zużycia procesora. W zależności od ruchu na blogu, można ustawić te godziny na różne pory rano, na przykład.

/**
 * 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 zastosowaniu tych zmian sprawdź, czy działają, zgodnie z wtyczką Advanced Database Cleaner Pro, zmiany te są stosowane. Można to również sprawdzić za pomocą Wp Crontrol.

Zakładając, że nie używasz natywnego wirtualnego CRON WordPressa, aby jeszcze bardziej zmniejszyć zużycie procesora, dodano nowy CRON, który zwiększa częstotliwość do 30 minut, unika duplikatów z flok i zmniejsza obciążenie serwera.

*/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, gdy uruchamiamy listę harmonogramu wp cron, okazuje się, że filtr litespeed_filter lub jakikolwiek inny filtr nie jest uruchamiany co 60 sekund.

To tylko pierwsze podejście. Teraz muszę testować i monitorować wykorzystanie zasobów w różnych scenariuszach. Przynajmniej na razie nie zaobserwowałem ponownej awarii strony podczas publikowania nowego posta.

Jeśli ktoś ma ten sam problem i znalazł ostateczne rozwiązanie, będzie wdzięczny za podpowiedź.