أصبح موقعك بطيئًا، أو بدأ الزوار يرون خطأ 503 Resource Limit Reached. أول ما يخطر في البال هو إلقاء اللوم على الخادم أو الانتقال إلى خطة أكبر. لكن السبب في الاستضافة المشتركة يكون عادةً داخل تطبيقك، ويمكنك اكتشافه بنفسك خلال دقائق باستخدام أدوات متوفرة بالفعل في cPanel.
أهم النقاط
- يعمل كل حساب استضافة مشتركة أو استضافة موزعين لدى WebGee داخل بيئة CloudLinux LVE مستقلة بحدود ثابتة للمعالج وعمليات الإدخال والإخراج (I/O) وعمليات الدخول والذاكرة.
- حدود المعالج وI/O تجعل الموقع بطيئًا، بينما تؤدي حدود عمليات الدخول والذاكرة إلى ظهور أخطاء 503 Resource Limit Reached.
- تحسب عمليات الدخول الطلبات التي تجري معالجتها في اللحظة نفسها، لذا تبلغ الصفحة البطيئة الحد بعدد زوار أقل بكثير من الصفحة السريعة.
- تخبرك أداة Resource Usage في cPanel ولقطاتها بالحد الذي بلغه حسابك والعمليات التي تسببت في ذلك، بينما تُظهر أداة PHP X-Ray أين يُستهلك الوقت داخل كل طلب.
- يأتي التخزين المؤقت ومراجعة الإضافات وإصلاح مهام cron قبل الترقية، لأن الترقية ترفع السقف دون أن تعالج ما يستهلك الموارد.
قبل أن تبدأ
- سجّل الدخول إلى cPanel الخاص بالحساب المتأثر.
- دوّن الوقت التقريبي الذي حدث فيه البطء أو ظهرت فيه أخطاء 503.
- اعرف عنوان IP الحالي الخاص بك، حتى تتتبع أداة PHP X-Ray زياراتك أنت فقط.
- إذا كنت تستخدم Bolt-Cache، فاستعد لتحويل الموقع إلى وضع Proxy أثناء التتبع.
حسابك يعمل داخل حاوية مستقلة
يعمل كل حساب استضافة مشتركة أو استضافة موزعين لدى WebGee داخل بيئة افتراضية خفيفة (LVE) خاصة به، وهي حاوية CloudLinux ذات حدود موارد ثابتة. فإذا شغّل أحد الحسابات سكربتًا خارجًا عن السيطرة أو تعرّض لهجوم، تُقيَّد موارده أو تُنهى عملياته، بينما تواصل بقية الحسابات عملها دون أي تأثر. وُجدت هذه الحدود حتى لا تتحول مشكلة غيرك إلى مشكلتك أنت.
ما لم تنص خطتك على غير ذلك، يحصل كل حساب على:
- المعالج (CPU): نواة واحدة (1 core)
- الذاكرة: 1 GB
- عمليات الدخول: 30 عملية متزامنة
اقرأ الشرح الكامل في شرح CloudLinux وحدود LVE.
اربط العَرَض بالحد المسؤول عنه
يتصرف كل حد بطريقة مختلفة عند بلوغه، وهذا يدلّك على المكان الذي يجب أن تبحث فيه:
- المعالج (CPU): يتباطأ الموقع، لكن الطلبات تكتمل في النهاية.
- عمليات الإدخال والإخراج (I/O): يتباطأ الموقع، خاصةً في كل ما يعتمد بكثافة على القرص.
- عمليات الدخول (EP): يظهر خطأ 503، لأن الطلبات تُنهى مباشرة.
- الذاكرة الفعلية (PMEM): يظهر خطأ 503، أو تُنهى العملية.
حدود المعالج وI/O تُضعف أداء موقعك، أما حدود عمليات الدخول والذاكرة فتُعطّله. فالموقع البطيء يصطدم بحد مختلف عن الموقع الذي يعرض أخطاء 503.
لماذا تستنفد المواقع البطيئة عمليات الدخول
عملية الدخول هي طلب تجري معالجته حاليًا داخل حسابك. والحد هو عدد الطلبات التي يمكن تشغيلها في اللحظة نفسها، لا في الساعة ولا لكل زائر. عادةً ما ينتهي طلب PHP في جزء من الثانية، ويتحرر مكانه فور انتهائه.
لكن المشكلة أنه كلما طال زمن كل طلب، قلّ عدد الزوار اللازم لبلوغ الحد. فالصفحة التي تستغرق 5 ثوانٍ تشغل مكانها مدة أطول 25 مرة من صفحة تستغرق 200 ms. وما إن تبدأ الطلبات بالاصطفاف في الانتظار حتى تزداد الصفحات بطئًا وتشغل أماكنها مدة أطول. هذه الحلقة المفرغة هي السبب في أن المواقع تتعطل فجأة لا بشكل تدريجي.
تُنهي النواة الطلبات التي تتجاوز الحد بإشارة SIGKILL، فيرى الزائر خطأ 503. وعادةً ما يكون السبب عملًا يستغرق وقتًا طويلًا:
- مهمة cron تستغرق عدة دقائق وتعمل كل دقيقة
- تشغيل WP-Cron عند تحميل الصفحات
- إضافة تُجري اتصالًا بطيئًا بواجهة API خارجية مع كل طلب
- استعلام قاعدة بيانات بلا فهرس
مزيد من التفاصيل في ما هي عمليات الدخول.
تنبيه الموارد لا يعني إيقاف الحساب إذا أرسلت إليك WebGee رسالة بريد إلكتروني تفيد بأن حسابك بلغ حدود موارده، فلم يُوقَف أي شيء. الغرض من التنبيه أن تعرف بمشكلة الأداء منّا قبل أن تعرفها من أحد عملائك. التنبيهات العرضية لا يترتب عليها أي إجراء، أما الحالات المستمرة التي تؤثر في استقرار الخادم فنتابعها بشكل فردي.
اعرف الحد الذي بلغته
ابدأ من cPanel ← Resource Usage. تعرض لك هذه الأداة الحد الذي بلغته، ومتى حدث ذلك، وما الذي كان يعمل في ذلك الوقت.
- افتح Resource Usage في cPanel.
- اختر الفترة التي تشمل البطء أو أخطاء 503 أو وقت وصول رسالة التنبيه.
- تحقق من الحد الذي بلغته: المعالج أو I/O أو عمليات الدخول أو الذاكرة.
- افتح اللقطة (snapshot) الخاصة بتلك اللحظة، فهي تعرض العمليات المسؤولة.
اللقطة هي ما يحوّل العَرَض إلى سبب واضح. وإذا تركزت الأعطال في وقت معين، فتحقق بعد ذلك من cPanel ← Cron Jobs، لأن المهام الثقيلة ذات الجداول الزمنية القصيرة من الأسباب الشائعة.
راجع وصلك تنبيه باستخدام الموارد وإصلاح خطأ 503 Resource Limit Reached للاطلاع على الشرح الكامل.
تتبّع الطلبات البطيئة باستخدام PHP X-Ray
تخبرك أداة Resource Usage بالحد الذي بلغته، أما PHP X-Ray فتخبرك أين يُستهلك الوقت داخل الطلب. فهي تتتبع الطلبات الحقيقية وتحلل كل طلب بالتفصيل، فتتوقف عن التخمين بشأن ما إذا كانت المشكلة في إضافة أو استعلام قاعدة بيانات أو اتصال خارجي. وهي متاحة في الاستضافة المشتركة واستضافة الموزعين واستضافة Premium.
- افتح X-Ray في cPanel.
- اختر النطاق أو النطاق الفرعي المراد تتبّعه.
- أدخل عنوان IP الخاص بك، واضبط عدد الطلبات المراد جمعها على 10–20، واختر مدة زمنية كافية لإعادة حدوث البطء.
- ابدأ التتبع، ثم زر الصفحة البطيئة عدة مرات من متصفحك.
- افتح نتيجة التتبع بعد أن يمتلئ عمود Collected Requests.
ابحث عن الأمور التالية، مرتبةً تقريبًا حسب تكرار كونها السبب:
- استعلام قاعدة بيانات بطيء يتكرر مرات عديدة، وغالبًا ما تكون إضافة تُجري الاستعلام داخل حلقة تكرار. وكثيرًا ما يحل التخزين المؤقت للكائنات هذه المشكلة تمامًا.
- اتصال HTTP خارجي بطيء، مثل إضافة تتصل بخادم تراخيص أو بواجهة API. ولا يمكن للصفحة أن تكتمل حتى يعود الرد.
- إضافة واحدة تستحوذ على معظم الوقت الإجمالي. عطّلها ثم أعد التتبع للتأكد.
تجد لقطات شاشة توضح الخطوات في اكتشف سبب بطء موقعك.
تحتاج X-Ray إلى وضع Proxy لا تجمع X-Ray البيانات إلا عند تعطيل Bolt-Cache واستخدام مواقعك وضع Proxy. أما مع تفعيل Bolt-Cache فيبقى التتبع فارغًا، وهذا أكثر سبب شائع يجعل البعض يظن أن X-Ray معطلة. وإذا كانت الصفحة تُعرض من التخزين المؤقت، فأضف ?xray=1 إلى عنوان URL أثناء الاختبار.
لا تخلط بين memory_limit في PHP وحد حسابك
تحدد قيمة memory_limit مقدار الذاكرة الذي يُسمح لسكربت PHP واحد بحجزه. ويمكنك تغييرها من cPanel ← Select PHP Version ← Options (راجع تغيير إصدار PHP وإعداداته). ورفع هذه القيمة أمر معقول في حالات مثل عمليات الاستيراد الكبيرة، أو معالجة الصور عند رفع ملفات كبيرة، أو متجر WooCommerce بكتالوج ضخم، أو تطبيق تنص وثائقه على متطلبات أعلى.
لكنها لا ترفع حد الذاكرة الخاص بحسابك، فهذا الحد تحدده خطتك، وهو ما يسبب أخطاء 503. وضبط memory_limit على قيمة أعلى من مخصصات حسابك لا يحقق شيئًا، لأن السكربت يُنهى عند حد الحساب في جميع الأحوال.
يتسع تحميل صفحة WordPress العادية بسهولة ضمن 128–256 MB. فإذا كانت صفحتك الرئيسية تحتاج إلى 1 GB، فهناك شيء يحمّل أكثر بكثير مما ينبغي: إضافة تُجري استعلامات بلا حدود، أو حلقة تكرار غير محدودة، أو معالجة للصور مع كل طلب بدلًا من مرة واحدة عند الرفع. تتبّع المشكلة باستخدام X-Ray قبل رفع أي قيمة.
للتحقق من القيمة المطبقة فعليًا، أنشئ ملف PHP يحتوي على <?php echo ini_get('memory_limit');، وافتحه في المتصفح، ثم احذفه. وعند استخدام Bolt-Cache يُتجاهَل PHP Selector وتؤخذ القيمة من .user.ini. مزيد من المعلومات في فهم حدود ذاكرة PHP.
خفّض استهلاك الموارد من جديد
أصلح التطبيق أولًا. هذه الخطوات، بهذا الترتيب، تحل معظم الحالات:
- فعّل التخزين المؤقت. الصفحة المخزنة مؤقتًا لا تصل إلى PHP أبدًا، وبالتالي لا تتحول إلى عملية دخول. ابدأ بـ LiteSpeed Cache، ثم أضف التخزين المؤقت للكائنات باستخدام Redis لزيارات المستخدمين المسجلين ولوحة الإدارة.
- راجع إضافاتك. عطّلها جميعًا، وانتظر دقيقتين تقريبًا، ثم أعد تفعيلها واحدة تلو الأخرى مع مراقبة Resource Usage.
- أصلح مهام cron. يعمل WP-Cron عند تحميل الصفحات، وهذا سلوك غير مناسب تحت الضغط. استبدل WP-Cron بمهمة cron حقيقية، وأطِل الفاصل الزمني لأي مهمة ثقيلة أخرى.
- تحقق من وجود زيارات غير طبيعية. تستهلك الروبوتات وأدوات جمع البيانات الموارد نفسها التي يستهلكها العملاء.
- افحص الموقع بحثًا عن البرمجيات الخبيثة. الموقع المخترق يستنزف الموارد في تنفيذ أعمال لصالح غيرك. افحص موقعك بحثًا عن البرمجيات الخبيثة.
اكتشف المشكلات قبل أن يكتشفها زوارك
تتحقق أداة Site Quality Monitoring في cPanel من جاهزية نطاق واحد كل ساعة، وتُجري فحصًا شاملًا للسلامة والأداء أسبوعيًا، بحثًا عن الروابط المعطلة والبيانات الوصفية المفقودة والصفحات البطيئة والمحتوى المختلط. وتكون الأداة معطلة إلى أن تنشئ مشروعًا:
- اختر Site Quality Monitoring في cPanel.
- اختر Monitored domain وأدخل Email Address لتلقي الإشعارات.
- حدد مربع الموافقة ثم اختر Create Project.
استخدم عنوان بريد غير مستضاف على الحساب الخاضع للمراقبة، وإلا فقد لا يصلك تنبيه التوقف أبدًا. ترى أداة المراقبة ما يراه الزائر، لذا لا يمكنها أن تخبرك لماذا تكون الصفحة بطيئة. وإذا أبلغت عن توقف متقطع، فتحقق من Resource Usage، لأن السبب غالبًا ما يكون حدود الموارد لا انقطاع الخدمة.
تفاصيل الإعداد في Site Quality Monitoring.
متى تكون الترقية هي الحل الصحيح
لا تلجأ إلى الترقية إلا بعد التشخيص. فالترقية ترفع السقف دون معالجة ما يستهلك الموارد، فتستهلك الإضافة الخارجة عن السيطرة ببساطة قدرًا أكبر. أما إذا أظهرت لقطة Resource Usage زيارات مشروعة تؤدي عملًا مشروعًا، فيمكن رفع الحدود، وهذا بالضبط هو الغرض من خطط Elastic Cloud. افتح تذكرة دعم مرفقًا بها أرقام Resource Usage الخاصة بك، وسيقدم لك فريق WebGee المشورة.
الأسئلة الشائعة
هل يعني خطأ 503 Resource Limit Reached أن الخادم متوقف؟
لا. بل يعني أن حسابك أنت بلغ أحد حدود الموارد المخصصة له، فرُفضت الطلبات حتى انخفض الاستهلاك. ولا تتأثر الحسابات الأخرى على الخادم.
هل حد عمليات الدخول هو نفسه حد عدد الزوار؟
لا. فهو يحدد عدد الطلبات التي تجري معالجتها في اللحظة نفسها، وكل طلب سريع لا يشغل مكانه إلا لوقت قصير جدًا. فالموقع الذي يعرض صفحاته خلال 200 ms يستطيع خدمة أكثر من 30 زائرًا متزامنًا بكثير دون أن يقترب من حد 30 عملية دخول.
هل يؤدي رفع قيمة memory_limit من Select PHP Version إلى إيقاف أخطاء 503؟
لا. فقيمة memory_limit تحدد الذاكرة المتاحة لسكربت PHP واحد، بينما تنتج أخطاء 503 عن حد الذاكرة الخاص بحسابك، والذي تحدده خطتك. ويُنهى السكربت عند بلوغ حد الحساب بصرف النظر عن قيمة memory_limit.
لماذا لا تجمع أداة PHP X-Ray أي طلبات؟
لا تجمع X-Ray البيانات إلا عند تعطيل Bolt-Cache واستخدام مواقعك وضع Proxy. تحقق كذلك من أنك أدخلت عنوان IP الحالي الخاص بك، وأضف سلسلة استعلام مثل ?xray=1 لتجاوز التخزين المؤقت للصفحات أثناء الاختبار.
