LiteSpeed işlemleri bir gönderi yayınlandıktan sonra sayfayı engeller

Bir süredir henüz kesin bir çözüm bulamadığım bir sorunla uğraşıyorum.

Sorun şu ki, bir gönderiyi yayınladıktan hemen sonra CPU tüketimi ve işlem sayısı hızla artıyor ve siteye uzun süreler boyunca neredeyse erişilemiyor.

Bu ciddi bir sorundur, zira aboneler yeni bir yayının haberini alacaklar ve sayfa çözülmediği için okuyamayacaklardır, ayrıca sayfanın sık sık kapatılmasının konumlandırma açısından ne anlama geldiğinden bahsetmeye bile gerek yoktur.

Bir süre sonra, sistem eninde sonunda işlemleri öldürecektir, ancak bunun gerçekleşmesi saatler alabilir.

cPanel kullanıyorsanız, genellikle buna benzer bir mesaj içeren bir e-posta alırsınız:

(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'de DISABLE_WP_CRON 'un etkinleştirilmiş olması, cPanel'den hala "Öldürüldü" mesajının alınması, wp-cron.php'yi çalıştırmaya çalışan (henüz keşfedemediğim) başka bir işlem veya yapılandırma olduğu ve sistemin aşırı kaynak tüketimi (bellek, CPU, vb.) nedeniyle bunu sonlandırdığı anlamına gelir.

Bugün biraz daha araştırma yaptım ve CPU tüketimini izledim. Bunun için tarayıcıdaki terminali SSH ve cPanel'de LucusHost tarafından sunulan WP-CLI erişimi için kullandım.

Hostinginiz izin veriyorsa, erişmek için cPanel'de Gelişmiş/Terminal 'e gitmelisiniz. Blog dosyalarınız public_html klasöründeyse, bu şekilde erişmelisiniz:

cd public_html

Ardından, çalışan işlemleri görmek için

top

Ve bunun gibi bir şey görmelisiniz:

Benim durumumda CPU'yu tamamen tüketen bir lsphp süreçleri çığı buluyorum.

Birkaç saniye sonra kapanan dört veya beş LiteSpeed işlemi(lsphp) görmek için WordPress yönetim alanını açmanız yeterlidir. Bu normaldir, LiteSpeed'in lsphp süreçleri PHP bağlantılarını verimli bir şekilde işlemek için mimarisinin bir parçasıdır.

Ancak, yeni bir gönderi yayınladıktan sonra (bazen sadece yayınlanmış olanı düzenlemek yeterlidir), bu işlemler hem sayı hem de CPU kullanımı olarak tetiklendiğinde ve serbest bırakılmadığında, siteyi ölü bıraktığında bir şeyler doğru değildir.

Sayfanın engelini kaldırmak için ilk acil durum önlemi, bu "sıkışmış" işlemleri öldürmektir; bu, tıkanmaya neden olan sorunu çözmez, ancak siteye yeniden erişim sağlarsınız.

pkill -u TuNombreDeUsuario lsphp

İsterseniz, PID'sini kullanarak belirli bir süreci öldürebilirsiniz, ancak birçok süreç kısa aralıklarla kapatılıp açıldığından bu muhtemelen size pek iyi gelmeyecektir.

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

Normalde, LiteSpeed varsayılan olarak, eklentinizin yapılandırmasına ve kullandığınız seçeneklere bağlı olarak bu dört görevi her dakika çalıştırır.

litespeed_task_imgoptm_pull
litespeed_task_ccss
litespeed_task_ucss
litespeed_task_lqip

İlk ikisi, imgoptm_pull ve ccss, bazen zaman aşımına neden olan ağır görevlerdir (özellikle paylaşımlı barındırmada), ucss ve lqip ise daha hafif görevlerdir.

Bu yüzden ilk denediğim şey LiteSpeed'deki otomatik Cron yönetimini devre dışı bırakarak LiteSpeed'in otomatik yenilenmesini engellemek oldu, bunun için wp-config.php dosyasına şunu ekledim

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

Ardından, functions.php dosyasına eklenen aşağıdaki işlevle 1 dakikalık aralığı kaldırmaya zorlar ve aşırı CPU tüketimini önlemek için bu görevleri farklı zamanlara dağıtarak günde 1 kez olarak değiştirirsiniz. Blogunuzun trafiğine bağlı olarak, bu saatleri örneğin sabahları farklı saatlere ayarlayabilirsiniz.

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

Bu değişiklikler uygulandıktan sonra, çalıştıklarını kontrol edin, Advanced Database Cleaner Pro eklentisine göre bu değişiklikler uygulanıyor. Wp Crontrol ile de kontrol edebilirsiniz.

Yerel WordPress sanal CRON'unu kullanmadığınızı varsayarsak, CPU tüketimini daha da hafifletmek için sıklığı 30 dakikaya çıkaran, flok ile kopyaları önleyen ve sunucu yükünü azaltan yeni bir CRON eklenmiştir.

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

Şimdi, wp cron zamanlama listesini çalıştırdığımızda, litespeed_filter veya başka bir filtrenin her 60 saniyede bir çalışmadığını görüyoruz.

Bu sadece bir ilk yaklaşım. Şimdi farklı senaryolarda kaynak kullanımını test etmeye ve izlemeye devam etmem gerekiyor. En azından şimdilik, yeni bir gönderi yayınlarken sayfanın tekrar çöktüğünü görmedim.

Aynı sorunu yaşayan ve kesin bir çözüm bulan varsa, bir ipucu takdir edilecektir.