عمليات 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، لا يزال يتلقى رسالة "تم القتل" من cPanel، يعني أن هناك عملية أو تكوين آخر (لم أكتشفه بعد) يحاول تشغيل wp-cron.php، ويقوم النظام بإنهائه بسبب الاستهلاك الزائد للموارد (الذاكرة، وحدة المعالجة المركزية، إلخ).

لقد قمت اليوم بالتحقيق أكثر قليلاً وكنت أراقب استهلاك وحدة المعالجة المركزية. لهذا الغرض، استخدمت المحطة الطرفية في المتصفح للوصول إلى SSH و WP-CLI الذي يوفره LucusHost في cPanel.

إذا كانت الاستضافة الخاصة بك تسمح بذلك، فلكي تتمكن من الوصول إليها يجب عليك الانتقال إلى خيارات متقدمة/مدخل في cPanel. إذا كانت ملفات مدونتك موجودة في مجلد public_html، فيجب عليك الوصول إليها على هذا النحو:

cd public_html

ثم، لرؤية العمليات قيد التشغيل، اكتب

top

ويجب أن ترى شيئاً كهذا:

تقوم عمليات LiteSpeed بحظر الصفحة بعد نشر المنشور 0

في حالتي أجد سيلًا من عمليات lsphp التي تلتهم وحدة المعالجة المركزية بالكامل.

ما عليك سوى فتح منطقة إدارة WordPress لترى أربع أو خمس عمليات LiteSpeed(lsphp) التي تغلق بعد بضع ثوانٍ. هذا أمر طبيعي، فعمليات LiteSpeed lsphpp جزء من بنيتها للتعامل مع اتصالات PHP بكفاءة.

ومع ذلك، هناك شيء غير صحيح عندما يتم تشغيل هذه العمليات من حيث العدد واستخدام وحدة المعالجة المركزية بعد نشر منشور جديد (في بعض الأحيان يكفي فقط تحرير منشور منشور منشور بالفعل)، ولا يتم تحريرها، مما يجعل الموقع ميتًا.

أول إجراء طارئ لإلغاء حظر الصفحة هو إيقاف تلك العمليات "العالقة"، وهذا لا يحل المشكلة التي تسببت في الانسداد، ولكنك تستعيد إمكانية الوصول إلى الموقع.

pkill -u TuNombreDeUsuario lsphp

إذا كنت تفضل ذلك، يمكنك إيقاف عملية معينة باستخدام معرّف PID الخاص بها، على الرغم من أن هذا لن يفيدك كثيرًا على الأرجح لأن العديد من العمليات يتم إغلاقها وفتحها على فترات قصيرة.

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

في العادة، وبشكل افتراضي، يقوم LiteSpeed بتشغيل هذه المهام الأربع كل دقيقة بناءً على تكوين الإضافة والخيارات التي تستخدمها.

Litespeed_task_imgoptm_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);

ثم، باستخدام الوظيفة التالية المضافة في function.php، يمكنك فرض إزالة الفاصل الزمني الذي مدته دقيقة واحدة وتغييره إلى مرة واحدة في اليوم الواحد بتوزيع هذه المهام في أوقات مختلفة لتجنب الاستهلاك المفرط لوحدة المعالجة المركزية. اعتمادًا على حركة مرور مدونتك، يمكنك تعيين هذه الساعات في أوقات مختلفة في الصباح، على سبيل المثال.

/**
 * 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.

تقوم عمليات LiteSpeed بحظر الصفحة بعد نشر المنشور 1

على افتراض أنك لا تستخدم CRON الافتراضي الأصلي في ووردبريس، لتخفيف استهلاك وحدة المعالجة المركزية بشكل أكبر، تمت إضافة CRON جديد يزيد التردد إلى 30 دقيقة، ويتجنب التكرار مع فلوك ويقلل من حمل الخادم.

*/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 ثانية.

تقوم عمليات LiteSpeed بحظر الصفحة بعد نشر المنشور 2

هذا مجرد نهج أولي. الآن يجب أن أواصل اختبار ومراقبة استخدام الموارد في سيناريوهات مختلفة. على الأقل، في الوقت الحالي، لم أر الصفحة تتعطل مرة أخرى عند نشر منشور جديد.

إذا كان لدى أي شخص لديه نفس المشكلة ووجد حلاً نهائياً لها، فسيكون من دواعي تقديري أن يقدم نصيحة.