خادم VPS بطيء: تشخيص من سبع خطوات قبل ترقية الخادم

يستغرق موقعك ثلاث ثوانٍ للاستجابة بدل 400 مللي ثانية، ويحتاج لوح التحكم إلى وقت طويل لحفظ طلب واحد، دون أن ينطلق أي تنبيه. خادم VPS البطيء لا يعني بالضرورة خادمًا صغيرًا: يُقرأ السبب في معظم الحالات التي نراها في الإنتاج من خلال ثلاثة أو أربعة عدّادات نظام، قبل التفكير في الترحيل. يقترح هذا الدليل تشخيصًا من سبع خطوات، بالترتيب الذي يجب اتباعه، مع الأوامر المطلوبة وقراءة كل نتيجة. الهدف واضح: التمييز بين خادم مشبع وتطبيق سيئ الإعداد، وعدم دفع تكلفة ترقية إلا عندما تكون مبرَّرة فعلاً.

خادم VPS بطيء لا يعني بالضرورة خادمًا صغيرًا

ثلاث عائلات من الأسباب تُنتج الأعراض نفسها. الموارد أولاً: معالج مشترك مع أجهزة أخرى على المضيف، وذاكرة غير كافية، وتخزين مشبع. الشبكة ثانياً: زمن استجابة مرتفع، وفقدان حزم، وتحليل DNS بطيء. التطبيق أخيراً: استعلامات SQL بلا فهارس، وغياب التخزين المؤقت، وإضافات سيئة الإعداد، ومهام مجدولة متداخلة. لكل سبب بصمته في السجلات والعدّادات، ولا يُصلَح أي منها بإضافة وحدة vCPU عشوائياً.

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

• بطء دائم: متوسط حمل مرتفع باستمرار، وغالباً تسريب ذاكرة أو قاعدة بيانات بلا فهارس.
• ذُرى منتظمة: نسخ احتياطي أو استيراد أو مهمة cron أو حملة بريد أو ذروة زيارات؛ الساعة الدقيقة للذروة تحدد السبب غالباً.
• صفحات معينة فقط: استعلام ثقيل، أو نداء إلى واجهة برمجية خارجية، أو صورة غير مضغوطة.
• الخادم هادئ والموقع بطيء: الشبكة أو DNS أو TLS أو المتصفح؛ المشكلة ليست في الجهاز.

الخطوات 1 إلى 3: المعالج والذاكرة والقرص

الخطوة 1 — قياس سرقة المعالج (CPU steal)

في خادم VPS بتقنية KVM تُشارَك وحدات vCPU مع أجهزة أخرى على المضيف. يعرض الأمر top سطر %Cpu(s) حيث تشير خانة st (steal) إلى الوقت الذي أراد فيه جهازك تنفيذ تعليمات دون الحصول على المعالج. إذا بقيت النسبة دون 2% فالسرقة مهملة؛ وفوق 5% لعدة دقائق يأتي التنافس من المضيف لا من تطبيقك. ويؤكد vmstat 1 10 القراءة كل ثانية: ارتفاع sy يعني إفراطاً في نداءات النظام، وارتفاع wa يعني انتظاراً للقرص، بينما id قريب من 100 مع شكوى المستخدمين ينقل المشكلة إلى مكان آخر.

الخطوة 2 — الذاكرة والـswap وقاتل OOM

قد يضلل الأمر free -m: خانة free لا تفيد كثيراً لأن لينكس يستخدم الذاكرة المتاحة للتخزين المؤقت. انظر إلى available. إذا انخفضت باستمرار تحت 10% من إجمالي الذاكرة، يبدأ النواة في استخدام swap وتتضاعف أزمنة الاستجابة مع بقاء المعالج هادئاً. ويؤكد swapon --show والمعطيان si/so في vmstat 1 وجود تبادل دائم. تحقق بعد ذلك مما إذا كانت النواة قد أنهت عمليات: dmesg -T | grep -i -E 'oom|killed process'. نادراً ما يترك OOM أثراً في سجلات التطبيق؛ يختفي PHP-FPM أو MySQL، ويعيد systemd تشغيله، ويتباطأ الموقع مدة إعادة التشغيل. ويحدد ps aux --sort=-rss | head العملية المستهلكة.

الخطوة 3 — القرص: المساحة والـinodes وزمن الاستجابة

يعرض df -h المساحة، ويعرض df -i عدد inodes. النظام الذي تنفد منه inodes يرفض أي كتابة جديدة رغم وجود جيجابايتات حرة، وهو أمر شائع على الخوادم التي تتراكم فيها الجلسات والملفات المؤقتة. يُقاس زمن الاستجابة بالأمر iostat -x 1 (حزمة sysstat): على قرص NVMe يدل %util القريب من 100 وawait الذي يتجاوز بضع عشرات من المللي ثانية على إشباع. ويحدد iotop -oPa العملية التي تكتب. على VPS قد يأتي بطء الكتابة أيضاً من التخزين المشترك على المضيف، وهي من الحالات القليلة التي يكون الحل فيها لدى المزوّد.

الخطوتان 4 و5: الشبكة وقاعدة البيانات

الخطوة 4 — الشبكة وتحليل المسار

لا يستبعد النطاق الترددي غير المحدود وجود اختناق. يحصي ss -s المقابس، ويسرد ss -tulpn المنافذ في حالة استماع. آلاف الاتصالات في حالة TIME_WAIT تدل على تطبيق يفتح اتصالاً لكل طلب بدل إعادة استخدامه. ويحدد mtr -rwzbc 100 votre-domaine.tld موضع فقدان الحزم والقفزة التي يتضاعف عندها زمن الاستجابة. لا تنسَ تحليل DNS ومصافحة TLS: محلل بطيء يضيف مئات المللي ثانية إلى كل نداء خارجي.

الخطوة 5 — قاعدة البيانات

هذا هو السبب الأكثر شيوعاً لموقع بطيء يبدو خادمه هادئاً. على MySQL أو MariaDB يكشف SHOW FULL PROCESSLIST; الاستعلامات الجارية وحالتها، ويُقرأ سجل الاستعلامات البطيئة حسب الزمن الإجمالي لا المتوسط. على PostgreSQL استعلم من pg_stat_activity: SELECT pid, state, wait_event_type, now() - query_start AS duree, query FROM pg_stat_activity WHERE state <> 'idle' ORDER BY duree DESC;. استعلام بلا فهرس على جدول يضم مئات آلاف السطور يستغرق ثوانٍ ويحتكر نواة كاملة. كما يسبب buffer pool صغير في InnoDB قراءات قرص دائمة تظهر في الخطوة 3.

الخطوتان 6 و7: التطبيق والتخزين المؤقت

الخطوة 6 — التطبيق والمهام المجدولة

تحتوي السجلات غالباً على الجواب. يُظهر journalctl -u php8.3-fpm --since '1 hour ago' وسجلات Nginx والإطار الأخطاء المتكررة ومهل الانتظار وإعادة تشغيل العمال. تحقق من المهام المجدولة: مهمتا cron متداخلتان (تصدير، نسخ احتياطي، مزامنة) تُشبعان الخادم عشرين دقيقة كل ساعة دون أثر واضح في المؤشرات. على Odoo كما على WordPress، قائمة الإضافات المثبتة مسار آخر: إضافة غير مُصانة قد تنفّذ استعلاماً ثقيلاً عند كل تحميل صفحة.

الخطوة 7 — التخزين المؤقت والإعداد

الموقع الذي يعيد حساب كل صفحة عند كل زيارة يُشبع نواتين دون أن يكون العتاد سبباً. تحقق من التخزين المؤقت لـ HTTP، ومن ذاكرة الكائنات (Redis أو Memcached)، ومن OPcache في PHP، ومن الضغط وHTTP/2. نسبة إصابة منخفضة في OPcache تدل على ذاكرة مؤقتة صغيرة أو سيئة الضبط. وفي خادم الويب يجب أن يوافق عدد عمال PHP-FPM الذاكرة المتاحة فعلاً: عدد كبير من العمال على 2 جيجابايت يعيد إنتاج مشكلة OOM نفسها الموصوفة في الخطوة 2.

عندما يؤكد التشخيص أن الخادم صغير

إذا خرجت الخطوات السبع نظيفة — لا سرقة معالج غير طبيعية، وذاكرة مستقرة، و%util معقول، وقاعدة بيانات مفهرسة، وتخزين مؤقت نشط — ومع ذلك بقي الحمل مرتفعاً في ساعات الذروة، فالخطة هي السقف. يلخّص الجدول أدناه الخطط الخمس لخوادم VPS NVMe من Open Vista بأسعارها، للمفاضلة بين ذاكرة أكبر وأنوية أكثر. الأسعار بالدولار الأمريكي شهرياً مع ما يقابلها بالدرهم دون احتساب الضريبة.

تتضمن كل خطة عنوان IPv4 مخصصاً، ونطاقاً ترددياً غير محدود، وصلاحية root، ولوحة إدارة (طرفية ويب، إعادة تشغيل، إعادة تثبيت، DNS)، ونسخاً احتياطياً تلقائياً، وجدار حماية مع حماية من هجمات DDoS، ومراقبة 24/7، ودعماً لمدة ستة أيام من سبعة، واتفاقية مستوى خدمة 99.9% على البنية التحتية. ويُعلن عن التسليم في أقل من خمس عشرة دقيقة بعد الطلب، ويتم الانتقال إلى خطة أكبر دون ترحيل مؤلم.

ملاحظة تهم الجمهور المغربي: مركز البيانات الإنتاجي يقع في نيويورك، بأزمنة استجابة تقارب أقل من 5 مللي ثانية إلى نيويورك، و8 مللي ثانية إلى أشبرن، ومن 10 إلى 20 مللي ثانية إلى مونتريال، ونحو 14 مللي ثانية إلى تورونتو. هناك مركز بيانات مُعلن في الرباط لكنه غير مفتوح بعد، فلا تبنِ معماريتك على توفره. ولموقع يُزار أساساً من المغرب، يُضاف زمن استجابة الشبكة إلى زمن استجابة التطبيق، وهو ما يفسر أحياناً البطء أكثر من المعالج.

الأسئلة الشائعة (FAQ)

كيف أعرف إن كان البطء من خادم VPS أم من تطبيقي؟

قارن حمل المعالج بالزيارات الفعلية. معالج عند 10% وموقع بطيء يوجّهك إلى الإدخال والإخراج أو قاعدة البيانات أو الشبكة أو الشيفرة. أما متوسط حمل يتجاوز عدد وحدات vCPU باستمرار فيشير إلى الجهاز نفسه.

هل سرقة المعالج مسؤوليتي؟

لا، لأنّ steal يقيس التنافس على المضيف الفيزيائي ولا سلطة لك فيه. وثّق القيمة بالأمر vmstat 1 10 على مدى دقائق وأرسلها إلى الدعم، الذي يمكنه نقل الجهاز أو التحقق من حمل المضيف.

هل يجب إعادة تشغيل خادم VPS بطيء؟

تخفف إعادة التشغيل المشكلة لحظياً لكنها تمحو الأدلة: العملية التي كانت تسرّب الذاكرة، والمقابس، والذاكرة. سجّل أولاً free -m وtop وdmesg -T وiostat -x 1، ثم أعد التشغيل إذا وجب أن تعود الخدمة فوراً.

هل تحل الترقية إلى خطة أكبر المشكلة دائماً؟

لا. بلا فهارس ولا تخزين مؤقت يبقى الموقع بطيئاً حتى بـ 5 جيجابايت من الذاكرة. الترقية تصحح نقص موارد مقيساً، لا استعلاماً بلا فهرس ولا إضافة معطوبة.

ابدأ التشخيص بالترتيب ثم قرّر

سبع خطوات وساعة قياس وبعض الأوامر تكفي عادةً لتسمية السبب. إن كان الحكم نقص الموارد، قارن خطط VPS NVMe من Open Vista بالتفصيل في صفحة VPS، مع الأسعار المحدثة في صفحة الأسعار والطلب المباشر من المتجر الإلكتروني. وإن كان الحكم تطبيقياً، فالقرار الصحيح هو تصحيح الفهرس أو التخزين المؤقت أو الإضافة المعطوبة قبل إنفاق أي درهم إضافي.