لماذا نقيس قبل اختيار الخطة
يسأل العميل: «أي خادم VPS يحتاجه موقعي؟» وغالبًا ما يكون الجواب مجرد حدس. ومن هذا الحدس يخرج خطآن. الأول أخذ الخطة الأعلى «احتياطًا»: ففي محفظة من عشرين عميلًا يُدفع هذا الهامش الميت كل شهر ويأكل من هامش الوكالة. والثاني التضييق الزائد: أول ذروة زيارات أو نسخة احتياطية أو استيراد للكتالوج يُسقط الموقع، فيعلم العميل قبلكم.
الاعتراض المعتاد هو «ليس لدي وقت للقياس». لكن القياس لا يتجاوز ساعة من المراقبة الفعلية بأدوات موجودة أصلًا في كل توزيعة لينكس. ثم إن الاختيار الأول ليس نهائيًا: يمكن تغيير حجم خادم VPS عموديًا، أي الانتقال إلى خطة أكبر دون إعادة بناء البنية. فالمطلوب ليس إصابة الهدف من المحاولة الأولى، بل الاختيار بأرقام وهامش مكتوب يمكن الدفاع عنه أمام العميل.
وينطبق المنطق نفسه على المهني الذي يدير موقعه بنفسه، كمتجر إلكتروني مثلًا: كلفة الخطة الأكبر من اللازم تظهر في الفاتورة الشهرية، وكلفة الخطة الضيقة تظهر في المبيعات الضائعة أثناء ذروة الطلبات. وتتيح القراءات نفسها القرار عن بينة ودون وسيط.
يعالج هذا الدليل القياس قبل الشراء واختيار الخطة. وللمفاضلة بين VPS والاستضافة المشتركة، اقرؤوا أولًا VPS أم استضافة مشتركة لموقع عميل. وللتنبيه المستمر بعد دخول الخادم في الإنتاج، انظروا تنبيهات القرص والذاكرة على VPS.
ما الذي يمنحكم القياس
- عرض سعر يمكن الدفاع عنه — تحددون الخطة بقراءات مؤرخة لا بانطباع.
- لا هامش ميت — تتوقفون عن فوترة أو تحمّل خطة أكبر من اللازم عند كل عميل.
- انقطاعات أقل عند أول ذروة — ترون امتلاء الذاكرة قبل أن يقتل عملية.
- أساس للمقارنة — قراءة اليوم تتيح الحكم على النمو بعد ستة أشهر.
- تشخيص صادق — تميّزون الموقع الذي تنقصه الموارد من الموقع سيئ الإعداد.
- ترحيل أهدأ — تصلون إلى الخادم الجديد بخطة جُرّبت على الحمل الفعلي.
المتطلبات: ما يجب تجهيزه قبل القياس
يجري القياس على خادم العميل الحالي الذي يحمل الحمل الحقيقي، لا على نسخة فارغة. تحتاجون إلى وصول SSH للقراءة، وصلاحية تشغيل ps وfree وdf، وإن أمكن تثبيت الحزمة sysstat التي توفر sar وتحفظ سجلًا للحمل.
من حيث المدة، احسبوا أسبوعًا على الأقل من السجل إن كانت sysstat تعمل أصلًا، وإلا نافذة مراقبة لا تقل عن ساعة تشمل عمدًا لحظة ازدحام: ذروة زيارات معروفة أو النسخة الليلية أو مهمة مجدولة أو استيرادًا. القياس يوم الثلاثاء في الثالثة فجرًا لا يقول شيئًا عن يوم التخفيضات. وأخيرًا دوّنوا السياق: التطبيق (ووردبريس أو متجر أو تطبيق مخصص)، ووجود حاويات، وقاعدة البيانات على الجهاز نفسه أم لا.
قراءة الاستهلاك الفعلي خطوة بخطوة
عدّ الأنوية
شغّلوا
nproc. هذا الرقم هو مرجع قراءة الحمل: متوسط حمل 4 سليم على 8 vCPU وحرج على 2.قراءة الذاكرة من العمود الصحيح
شغّلوا
free -hوانظروا إلى العمودavailableلاfree. يملأ لينكس الذاكرة الحرة عمدًا بذاكرة تخزين مؤقت للقرص يمكن استرجاعها عند الطلب، فيبدوfreeمنخفضًا دائمًا، بينما يُظهرavailableما تبقى فعلًا للتطبيقات الجديدة دون اللجوء إلى swap.مراقبة المعالج والذاكرة والإدخال والإخراج
شغّلوا
vmstat 1 10. راقبواsiوso(التبادل مع swap، ويجب أن يبقيا صفرًا) وwa(انتظار الإدخال والإخراج) وr(العمليات المنتظرة للمعالج).قراءة متوسط الحمل
شغّلوا
uptime. القيم الثلاث هي المتوسطات على 1 و5 و15 دقيقة. قارنوها بـnproc: حمل يفوق عدد الأنوية باستمرار يدل على انتظار.تحديد كبار المستهلكين
شغّلوا
ps aux --sort=-%mem | head -15. مع الحاويات أضيفواdocker stats --no-stream، ومع systemd يرتبsystemd-cgtopالخدمات حسب الاستهلاك.قياس القرص والـ inodes
شغّلوا
df -hللمساحة وdf -iللـ inodes. قد يرفض القرص الكتابة رغم بقاء مساحة بالبايت إذا نفدت الـ inodes. دوّنوا أيضًا حجم المجلدات التي تكبر: الوسائط وقاعدة البيانات والسجلات والنسخ المحلية.تسجيل سجل تاريخي بـ sar
ثبّتوا
sysstatوفعّلوا الجمع بحسب توزيعتكم، ثم اقرؤوا الذاكرة بـsar -rوالمعالج بـsar -uوالحمل بـsar -q. وبلا سجل، خذوا العينات بأنفسكم: يعطيvmstat 60 120قراءة كل دقيقة طوال ساعتين.تدوين القيم القصوى
ضعوا في جدول ذروة الذاكرة المستعملة وذروة الحمل ونمو القرص. هذا الجدول، لا المتوسط، هو ما يُحسب به الحجم.
ما الذي يهيمن على الحمل بحسب نوع الموقع
مرّر الجدول أفقيًا
| نوع الموقع | المورد الذي يمتلئ أولًا | ما يجب تدوينه |
|---|---|---|
| موقع تعريفي أو ووردبريس قليل الزيارات | الذاكرة، عبر PHP وقاعدة البيانات | `free -h` عند الذروة، ذاكرة كل عملية PHP |
| متجر إلكتروني | الذاكرة والمعالج عند ذروة الطلبات | الحمل أثناء عرض ترويجي، عدد عمليات PHP المتزامنة |
| تطبيق أعمال بقاعدة بيانات | إدخال وإخراج القرص والذاكرة | `wa` في `vmstat`، حجم القاعدة، الاستعلامات البطيئة |
| موقع وسائط أو كتالوج صور | القرص وعرض النطاق | `df -h`، النمو الشهري لمجلد الوسائط |
| موقع باستيراد أو مهمة مجدولة ثقيلة | المعالج والذاكرة بصورة مؤقتة | الحمل والذاكرة أثناء المهمة، مدة المهمة |
| تطبيق في حاويات | مجموع ذاكرة الحاويات | `docker stats --no-stream`، حدود الذاكرة المعلنة |
قيسوا الذروة لا المتوسط
قد يعرض خادم متوسط معالج 25 % على مدى 24 ساعة وهو ممتلئ عشر دقائق كل مساء. المتوسط يمحو بالضبط ما يُسقط الموقع. وللتحديد، احتفظوا بالقيمة القصوى المرصودة في النافذة، وتأكدوا أنها تشمل أسوأ لحظة معروفة: ذروة الزيارات أو النسخة الاحتياطية أو مهمة cron ثقيلة أو استيراد.
إن لم يعرف العميل متى تقع ذرواته، فقارنوا مع سجلات الوصول لخادم الويب ومع تواريخ الحملات البريدية أو العروض. أسبوع من سجل sar يغطي دورة كاملة بما فيها نهاية الأسبوع. وحين يكون الموقع بطيئًا أصلًا، فقراءة واحدة أثناء البطء تساوي عشر قراءات في الهدوء.
قاعدة حساب بسيطة، معلنة كفرضية
القاعدة التالية تحريرية، لا معيار ولا وعد من الكتالوج: الذاكرة اللازمة = الاستهلاك عند الذروة، زائد هامش 30 %. رقم 30 % فرضية هذا المقال؛ وهو يغطي النمو القريب والذرى التي لم تلتقطها نافذتكم. أما القرص فاحسبوا المساحة المستعملة، زائد النمو المتوقع خلال ستة أشهر، زائد 20 % حرة على الأقل.
ولموقع يعمل بـ PHP-FPM، احسبوا ذاكرة العمليات بدل قراءتها إجمالًا: ذاكرة PHP = الذاكرة المقيسة لكل عملية مضروبة في pm.max_children. قيسوا ذاكرة العملية بـps -eo rss,args | awk '/[p]hp-fpm: pool/ {s+=$1; n++} END {print s/n/1024 " MB"}'. النتيجة تبالغ قليلًا لأن جزءًا من الذاكرة مشترك بين العمليات.
مثال رقمي افتراضي: 600 ميغابايت للنظام وخادم الويب وقاعدة البيانات، زائد 20 عملية بحجم 60 ميغابايت، أي 1200 ميغابايت، يعطي 1800 ميغابايت عند الذروة. مع هامش 30 % نحتاج نحو 2.4 غيغابايت: نختار الخطة التي ذاكرتها تعلو ذلك مباشرة.
اكتبوا الهامش في عرض السعر
دوّنوا في عرض السعر الذروة المقيسة والهامش المعتمد وتاريخ القراءة. وحين يسأل العميل لماذا هذه الخطة لا التي تليها، يكون الجواب مكتوبًا. كرروا القراءة كل ستة أشهر: الموقع النامي يغيّر خطته قبل أن يسقط لا بعده.
اكتشاف VPS صغير الحجم قبل العميل
بعد دخول الموقع الإنتاج، تدل إشارات قليلة على ضيق الخطة. وكل إشارة تترك أثرًا دقيقًا يمكنكم البحث عنه دون انتظار شكوى العميل.
الإشارات مع رسائلها الدقيقة
- عملية قُتلت لنفاد الذاكرة — ابحثوا بـ
journalctl -k | grep -i "out of memory"أوdmesg -T | grep -i "killed process"عن سطر من نوعOut of memory: Killed process. لقد ضحّت النواة بعملية، وغالبًا قاعدة البيانات. - swap نشط — قيمتان غير صفريتين لـ
siوsoفيvmstat 1: الخادم يبدّل الذاكرة مع القرص فيتباطأ كل شيء. - انتظار إدخال وإخراج مرتفع —
waمرتفع باستمرار فيtop: القرص أو قاعدة البيانات هي الكابح، أحيانًا لنقص التخزين المؤقت في الذاكرة. - حمل يفوق عدد الأنوية — متوسط حمل أعلى من
nprocباستمرار يعني أن العمليات تنتظر دورها. - PHP-FPM ممتلئ — السطر
server reached pm.max_children setting (N), consider raising itفي سجل الأخطاء يعني أن كل العمليات مشغولة وأن الطلبات تنتظر. - أخطاء 502 و504 من nginx — استجابات
502أو504معupstream timed out (110: Connection timed out)ترافق غالبًا امتلاء PHP-FPM. - قرص ممتلئ أو inodes منتهية — يقترب
df -hوdf -iمن 100 % وتفشل الكتابة.
ما لا تحله ذاكرة أكبر
قبل الانتقال إلى خطة أعلى، تأكدوا أن المشكلة مسألة موارد فعلًا. استعلام SQL بطيء يُشبع المعالج أيًّا كانت الخطة: الفهرس الناقص يُصلح ولا يُعوَّض. وغياب ذاكرة الكائنات المؤقتة يجبر PHP على إعادة حساب الصفحات نفسها في كل زيارة. وصورة بحجم 8 ميغابايت تُقدَّم كما هي تستهلك عرض النطاق ووقت المعالجة. وأخيرًا رفع pm.max_children دون رفع الذاكرة يسبب بالضبط قتل النواة للعمليات الذي أردتم تجنبه.
النهج السليم إصلاح هذه النقاط أولًا ثم قراءة جديدة ثم التحديد على النتيجة. وهكذا تتفادون فوترة العميل بخطة أكبر لا تخفي سوى عيب في الإعداد.
اختيار الخطة ثم التوسع
بعد تحديد الحاجة بالأرقام، قابلوها بالمجموعة. تقدّم خطة VPS Start 2 vCPU و4 GB من الذاكرة و50 GB SSD من التخزين؛ وتقدّم خطة VPS Power 4 vCPU و8 GB و100 GB SSD؛ وتقدّم خطة VPS Business 8 vCPU و16 GB و200 GB SSD. سعر الدخول إلى المجموعة: 99 درهم/شهر.
اختاروا أصغر خطة تغطي حاجتكم بالهامش المكتوب، ثم دعوا التوسع العمودي يتكفل بالباقي: إن أظهرت القراءة التالية أن الهامش يذوب، انتقلتم إلى الخطة الأعلى دون تغيير البنية. ولكي لا تنتظروا تلك القراءة، فعّلوا تنبيهات مستمرة، ولمعرفة هل يستجيب الموقع من الخارج استعينوا بمجس توافر: انظروا متابعة توافر مواقع العملاء.
