LiteSpeed-Prozesse blockieren die Seite, nachdem ein Beitrag veröffentlicht wurde

Ich beschäftige mich schon seit einiger Zeit mit einem Problem, für das ich noch keine endgültige Lösung gefunden habe.

Das Problem ist, dass unmittelbar nach der Veröffentlichung eines Beitrags der CPU-Verbrauch und die Anzahl der Prozesse in die Höhe schießen, so dass die Website für längere Zeit praktisch unzugänglich ist.

Dies ist ein ernstes Problem, da die Abonnenten eine Benachrichtigung über eine neue Veröffentlichung erhalten, die sie nicht lesen können, weil die Seite nicht aufgelöst wird, ganz zu schweigen davon, was es für die Positionierung bedeutet, wenn die Seite häufig nicht erreichbar ist.

Nach einiger Zeit wird das System die Prozesse schließlich beenden, aber es kann Stunden dauern, bis das geschieht.

Wenn Sie cPanel verwenden, erhalten Sie normalerweise eine E-Mail mit einer Meldung wie dieser:

(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

Wenn ich DISABLE_WP_CRON in der wp-config.php aktiviert habe und trotzdem die Meldung "Killed" von cPanel erhalte, bedeutet das, dass ein anderer Prozess oder eine andere Konfiguration (die ich noch nicht entdeckt habe) versucht, wp-cron.php auszuführen, und das System beendet ihn wegen Überbeanspruchung der Ressourcen (Speicher, CPU usw.).

Heute habe ich ein wenig mehr untersucht und den CPU-Verbrauch überwacht. Dazu habe ich das Terminal im Browser für den SSH- und WP-CLI-Zugang genutzt, den LucusHost im cPanel anbietet.

Wenn Ihr Hosting dies zulässt, müssen Sie im cPanel zu Erweitert/Terminal gehen, um darauf zuzugreifen. Wenn sich Ihre Blog-Dateien im Ordner public_html befinden, müssen Sie wie folgt darauf zugreifen:

cd public_html

Um die laufenden Prozesse zu sehen, geben Sie dann

top

Und Sie sollten etwa so etwas sehen:

In meinem Fall finde ich eine Lawine von lsphp-Prozessen, die die CPU komplett auffressen.

Sie brauchen nur den WordPress-Administrationsbereich zu öffnen, um vier oder fünf LiteSpeed-Prozesse(lsphp) zu sehen, die nach einigen Sekunden geschlossen werden. Das ist normal. Die lsphp-Prozesse von LiteSpeed sind Teil seiner Architektur, um PHP-Verbindungen effizient zu verarbeiten.

Irgendetwas stimmt jedoch nicht, wenn nach der Veröffentlichung eines neuen Beitrags (manchmal genügt es, einen bereits veröffentlichten Beitrag zu bearbeiten) diese Prozesse sowohl in der Anzahl als auch in der CPU-Auslastung ausgelöst und nicht freigegeben werden, so dass die Website tot ist.

Die erste Notmaßnahme, um die Seite freizugeben, besteht darin, die "steckengebliebenen" Prozesse zu beenden, was zwar nicht das Problem löst, das die Blockade verursacht, aber Sie erhalten wieder Zugang zur Website.

pkill -u TuNombreDeUsuario lsphp

Wenn Sie es vorziehen, können Sie einen bestimmten Prozess über seine PID beenden, obwohl dies wahrscheinlich nicht viel nützt, da viele Prozesse in kurzen Abständen geschlossen und geöffnet werden.

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

Normalerweise führt LiteSpeed diese vier Aufgaben jede Minute aus, abhängig von der Konfiguration Ihres Plugins und den von Ihnen verwendeten Optionen.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

Die ersten beiden, imgoptm_pull und ccss, sind schwere Aufgaben, die manchmal zu Timeouts führen (vor allem bei gemeinsam genutztem Hosting), während ucss und lqip leichtere Aufgaben sind.

Also habe ich als erstes versucht, die automatische Regeneration von LiteSpeed zu blockieren, indem ich die automatische Cron-Verwaltung in LiteSpeed deaktiviert habe, dazu habe ich in der wp-config.php folgendes hinzugefügt

// Deshabilita la gestión automática de Cron en LiteSpeed
define('LITESPEED_DISABLE_CACHE_PURGE_CRON', true);
define('LITESPEED_DISABLE_AUTOUPDATE_CRON', true);

Mit der folgenden, in der functions.php hinzugefügten Funktion erzwingen Sie dann die Aufhebung des 1-Minuten-Intervalls und ändern es auf 1 Mal pro Tag, indem Sie diese Aufgaben auf verschiedene Zeiten verteilen, um einen übermäßigen CPU-Verbrauch zu vermeiden. Abhängig vom Traffic Ihres Blogs können Sie diese Zeiten z.B. auf verschiedene Zeiten am Morgen legen.

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

Sobald diese Änderungen angewendet werden, überprüfen Sie, ob sie funktionieren. Laut dem Advanced Database Cleaner Pro Plugin werden diese Änderungen angewendet. Sie können auch mit Wp Crontrol überprüfen.

Angenommen, Sie verwenden nicht das native virtuelle CRON von WordPress. Um den CPU-Verbrauch weiter zu senken, wurde ein neues CRON hinzugefügt, das die Häufigkeit auf 30 Minuten erhöht, Duplikate mit flok vermeidet und die Serverlast reduziert.

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

Wenn wir nun wp cron schedule list ausführen, stellen wir fest, dass der litespeed_filter oder irgendein anderer Filter nicht alle 60 Sekunden ausgeführt wird.

Dies ist nur ein erster Ansatz. Jetzt muss ich weiter testen und die Ressourcennutzung in verschiedenen Szenarien überwachen. Zumindest habe ich bis jetzt keinen weiteren Absturz der Seite beim Veröffentlichen eines neuen Beitrags gesehen.

Wenn jemand das gleiche Problem hat und eine endgültige Lösung gefunden hat, wäre ich für einen Tipp dankbar.