متى ترقّي الخادم ومتى تصلح الموقع؟ تخطيط سعة الخادم بالذكاء الاصطناعي

رقِّ الخادم حين يرتفع استخدام الموارد على أغلب الحسابات بشكل ثابت لأسابيع، والمواقع نفسها مضبوطة جيدًا. وأصلح الموقع حين يفسر حساب واحد أو عملية واحدة أو استعلام واحد معظم الحمل. الذكاء الاصطناعي يساعدك على التمييز بين الحالتين: يقرأ اتجاه CPU والذاكرة والقرص وI/O، ويفصل الذروة العابرة عن النمو الحقيقي، ويتوقع موعد امتلاء القرص، ويحدد الحساب المسؤول مع الدليل.

لماذا لا تكفي نظرة واحدة على استخدام CPU؟

القراءة اللحظية تخدعك في الاتجاهين. لقطة في وقت هادئ تجعل الخادم يبدو واسعًا، ولقطة أثناء النسخ الاحتياطي الليلي تجعله يبدو مختنقًا. قرار الترقية يحتاج إلى ثلاثة أسئلة لا يجيب عنها رقم واحد:

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

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

كيف تقرأ المقاييس الأربعة؟

CPU

الرقم الأهم ليس النسبة اللحظية بل Load Average (متوسط عدد العمليات التي تنتظر دورها) مقارنة بعدد الأنوية. خادم بأربع أنوية وLoad Average يبقى فوق 4 لساعات يعني أن الطلبات تنتظر.

الذاكرة

ذاكرة Linux الممتلئة ليست مشكلة بالضرورة، فالنظام يستخدم الفائض لتخزين الملفات مؤقتًا. انظر إلى عمود available لا free، وإلى Swap (جزء من القرص يُستخدم ذاكرةً احتياطية):

free -m
journalctl -k --since "7 days ago" | grep -i "out of memory"

ظهور سطر يقول إن النظام أوقف عملية mariadbd أو php-fpm لنقص الذاكرة علامة على مشكلة حقيقية، حتى لو بدا متوسط الاستخدام معقولًا.

القرص وI/O

المساحة ليست كل شيء. الملايين من الملفات الصغيرة، مثل ملفات الجلسات أو ذاكرة التخزين المؤقت لإضافة ما، قد تستهلك الـ inodes (سجلات الملفات في نظام الملفات) قبل المساحة. وبطء القرص يظهر في iowait:

df -h /
df -i /
iostat -x 5 3

كيف يتوقع الذكاء الاصطناعي موعد امتلاء القرص؟

بالطريقة نفسها التي تحسبها يدويًا، لكن على بيانات أدق ومع تفسير النمو. لنفترض خادمًا بقرص 160 GB، والمستخدم منه 118 GB، ومتوسط النمو في آخر 30 يومًا 0.9 GB يوميًا:

disk.size            160 GB
disk.used            118 GB
growth (30d avg)     0.9 GB/day
alert threshold      90%  -> 144 GB
days to threshold    (144 - 118) / 0.9 = ~29 days
days to full         (160 - 118) / 0.9 = ~46 days

الحساب الخطي بداية فقط. ما يضيفه الذكاء الاصطناعي هو تفسير مصدر النمو، لأن العلاج يختلف حسب المصدر:

du -xh --max-depth=3 /home 2>/dev/null | sort -h | tail -n 10

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

ماذا تفعل حين يستهلك حساب واحد موارد الخادم كله؟

هذا أكثر سيناريو يُخطئ فيه قرار الترقية. يبطؤ الخادم، فيُطلب خادم أكبر، ثم يمتلئ الخادم الأكبر بالطريقة نفسها. الخطوة الأولى معرفة من يستهلك الموارد فعلًا:

ps -eo user,pcpu,rss,comm --sort=-pcpu | head -n 8

USER       %CPU    RSS COMMAND
shop_ex    310.2 2411520 php-fpm8.3
shop_ex     95.4  612340 php-fpm8.3
mysql       88.1 3145728 mariadbd
blog_ex      4.2  110220 php-fpm8.3

حين يعمل كل حساب بمستخدم Linux خاص وPHP-FPM pool خاص، يظهر صاحب الحمل مباشرة باسم المستخدم. في هذا المثال الافتراضي حساب shop_ex يستهلك معظم CPU، وقاعدة البيانات مشغولة معه.

بعد ذلك يربط الذكاء الاصطناعي هذا بالسجلات ليعرف السبب. الأسباب الشائعة قليلة:

• زواحف وروبوتات تطلب صفحات البحث أو التصفية بلا توقف. يظهر ذلك في سجل الوصول كعدد كبير من الطلبات من عناوين قليلة.
• wp-cron يعمل مع كل زيارة بدل وظيفة Cron حقيقية.
• وظيفة Cron كل دقيقة تستغرق أكثر من دقيقة، فتتراكم نسخ منها.
• استعلام بطيء بلا فهرس، يظهر في سجل الاستعلامات البطيئة.
• غياب التخزين المؤقت، فكل زيارة تبني الصفحة من الصفر. الحل في دليل تسريع WordPress.

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

ما الحدود التي تضعها لكل حساب؟

الحدود لا تحمي الخادم فقط، بل تحمي الحسابات من بعضها. حساب يتجاوز حده يبطؤ هو، ولا يُسقط جيرانه.

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

متى تكون الترقية هي القرار الصحيح؟

حين تتحقق هذه الشروط معًا:

1. الاستخدام مرتفع على أغلب الحسابات، لا على حساب واحد.
2. الاتجاه صاعد لأسابيع، لا ذروة يوم واحد.
3. المواقع الأكبر مضبوطة: إصدار PHP حديث، وOPcache (ذاكرة التخزين المؤقت لشيفرة PHP) مفعّل، وتخزين مؤقت للصفحات.
4. لا يوجد تغيير حديث يفسر الارتفاع.
5. المورد الذي ينفد معروف: CPU أم الذاكرة أم القرص أم I/O.

النقطة الأخيرة تحدد نوع الترقية. خادم ينقصه I/O لن تنفعه أنوية إضافية، وخادم ينقصه الذاكرة لن ينفعه قرص أسرع.

كيف تختار حجم VPS المناسب؟

احسب الذاكرة من مكوناتها بدل التخمين. لنفترض خادمًا عليه 30 حساب استضافة، أغلبها مواقع WordPress صغيرة، وبعضها متاجر:

متوسط ذاكرة عملية PHP تقيسه على خادمك لا تفترضه، والطريقة مشروحة في مقال عمليات الذكاء الاصطناعي. وعدد العمليات النشطة في الذروة يأتي من المقاييس، لا من مجموع pm.max_children لكل الحسابات، فنادرًا ما تبلغ كل المواقع ذروتها معًا.

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

كيف تسأل الذكاء الاصطناعي عن السعة؟

السؤال العام يعطيك جوابًا عامًا. حدد الفترة والمورد والقرار الذي تريد اتخاذه:

• «قارن استخدام الذاكرة في آخر 30 يومًا بالشهر الذي قبله، وقل لي أي الحسابات تفسر الفرق.»
• «متى يصل القرص إلى 90% بمعدل النمو الحالي؟ وما المجلدات التي تنمو أسرع؟»
• «الموقع example.com بطيء كل مساء. هل السبب نقص في موارد الخادم أم شيء داخل الموقع؟»

والجواب الجيد يحتوي على ثلاثة أشياء: الأرقام التي بنى عليها مع فترتها، والحساب أو العملية المسؤولة، وما لم يستطع فحصه. وإن قال إن البيانات لا تكفي للحكم، فهذا جواب صحيح لا تقصير، والأفضل أن تنتظر أسبوعًا آخر من المقاييس قبل أن تدفع ثمن خادم أكبر.

وفرّق دائمًا بين تخطيط السعة والاستجابة لعطل قائم. إن كان الموقع متوقفًا الآن، فالأولوية إعادته للعمل ثم التحليل، كما في مقال الاستجابة للحوادث.

كيف يساعدك bPanel؟

يراقب الذكاء الاصطناعي في bPanel الخادم والمواقع، ويقرأ المقاييس والسجلات حين يظهر ضغط على الموارد، ويحدد السبب مع الدليل، ثم يقترح إصلاحًا محددًا، مثل تعديل حدود PHP-FPM لموقع واحد، لا يُنفَّذ إلا بعد موافقتك ويُسجَّل في سجل التدقيق. ولكل حساب استضافة مستخدم Linux خاص وPHP-FPM pool خاص ومستخدمو قواعد بيانات خاصون وحصة قرص، فيظهر صاحب الحمل باسمه.

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

الخلاصة

• القرار يبنى على الاتجاه لأسابيع وعلى توزيع الحمل بين الحسابات، لا على لقطة لحظية.
• إن فسر حساب واحد أو عملية واحدة معظم الحمل، فأصلح الموقع قبل أن ترقّي الخادم.
• توقع امتلاء القرص يحتاج إلى معرفة مصدر النمو: سجلات أم نسخ احتياطية محلية أم بريد أم نمو حقيقي.
• حدود كل حساب في حزمة الاستضافة تمنع حسابًا واحدًا من إسقاط الخادم.
• احسب حجم الخادم من مكوناته، واعرف أي مورد ينفد قبل أن تختار نوع الترقية.