السيرفر بطيء، والأوامر تتأخر، وربما توقفت قاعدة البيانات فجأة ثم عادت؟ غالبًا الرام ممتلئة. حين تكون الرام ممتلئة يلجأ النظام إلى القرص الأبطأ فيتباطأ كل شيء، وقد يقتل برامج لتحرير المساحة. في هذا الدليل نفحص الذاكرة بالطريقة الصحيحة (وأغلب الناس يقرؤون الرقم الخطأ)، ونعرف البرنامج المسبّب، ثم نعالج المشكلة: من إعادة تشغيل الخدمة، إلى ملف Swap — وقد كبّرناه فعلًا من 1G إلى 2G على سيرفر في مرام هوست — وحتى الترقية.

⚡ الإجابة المختصرة

نفّذ free -h وانظر عمود available لا free. اعرف المستهلك بـps -eo pid,%mem,comm --sort=-%mem | head، وتأكد من قتل البرامج بـjournalctl -k | grep -i "killed process". للحل السريع أعد تشغيل الخدمة، ولأمان أكبر كبّر Swap، وإن كان الاستهلاك دائمًا قرب الحد فرقِّ الخطة.

لماذا الرام ممتلئة تُبطئ سيرفرك؟

قبل الحل، لماذا تُعدّ الرام ممتلئة مشكلة تستحق العلاج الفوري؟

  • لجوء إلى Swap البطيء: عند الامتلاء ينقل النظام بيانات إلى القرص الأبطأ بمئات المرات من الرام.
  • قتل البرامج (OOM): إن نفدت تمامًا يقتل لينكس أكبر عملية — غالبًا قاعدة البيانات.
  • بطء عام: كل طلب يصبح أبطأ، وقد يسقط الموقع وقت الذروة.
  • تعطّل متقطّع: خدمات تتوقف وتعود، يصعب تشخيصها دون قراءة الذاكرة بشكل صحيح.

لذلك عند أول علامة على أن الرام ممتلئة، اقرأ الذاكرة بشكل صحيح (عمود available) وعالج السبب لا العَرَض. والأداة الأساسية free تكشف الوضع الحقيقي في ثوانٍ.

الخطوة 1: اقرأ الذاكرة بشكل صحيح

الرام ممتلئة: أوامر free -h وswapon وps لمعرفة استهلاك الذاكرة
مخرجات حقيقية
  • free صغير؟ لا تقلق. لينكس يستعمل الذاكرة الفارغة كاشًا (buff/cache) لتسريع القرص، ويعطيها للبرامج فور حاجتها.
  • available هو الرقم الحقيقي: كم تستطيع البرامج أن تأخذ الآن. في سيرفرنا 6.9Gi من 7.5Gi — مرتاح جدًا.
  • Swap مستعمل بكثرة مع available قليل = ضغط حقيقي على الذاكرة، والسيرفر يبطؤ لأن القرص أبطأ من الرام بكثير.

وللصورة عبر الوقت افتح رسم Memory في رسوم الأداء، واضبط تنبيه بريد عند تجاوز 90%.

الخطوة 2: من يأكل الذاكرة؟

ps -eo pid,user,%mem,rss,comm --sort=-%mem | head    # أكثر العمليات استهلاكًا
top            # ثم اضغط M لترتيب حسب الذاكرة، وq للخروج
sudo docker stats --no-stream                        # استهلاك كل حاوية
sudo journalctl -k | grep -i "killed process"        # هل قتل النظام برامج لنقص الذاكرة؟

الأمر الأخير مهم: عندما تنفد الذاكرة يقتل لينكس أكبر عملية تلقائيًا (OOM killer)، وغالبًا تكون قاعدة البيانات، فتبدو وكأنها «توقفت وحدها». في سيرفرنا لم يظهر أي سطر، أي لم يُقتل شيء.

الخطوة 3: الحلول من الأسرع إلى الأدوم

الحلكيف
أعد تشغيل الخدمة المسرّبةsudo systemctl restart php8.3-fpm أو sudo docker restart اسم-الحاوية. يحرر الذاكرة فورًا.
حدّد استهلاك البرامجقلّل pm.max_children في PHP-FPM، وinnodb_buffer_pool_size في MySQL، وضع --memory 1g لحاويات Docker.
إعادة تشغيل دوريةلتطبيق يسرّب الذاكرة ببطء: مهمة Reboot مجدولة ليلًا.
كبّر Swapشبكة أمان تمنع قتل البرامج عند الذروة (الخطوات أدناه).
رقِّ الخطةإن كان available قليلًا طوال الوقت — الترقية دون فقدان البيانات.

ملف Swap: إنشاؤه وتكبيره

Swap مساحة على القرص يستعملها النظام كذاكرة إضافية عند الامتلاء. أبطأ من الرام بكثير، لكنه يمنع توقف البرامج فجأة. قوالب لينكس في مرام تنشئ ملف Swap بحجم 1G تلقائيًا عند أول تشغيل، مع swappiness=10 (أي لا يلجأ إليه النظام إلا عند الحاجة الحقيقية). إن احتجت أكبر، هكذا كبّرناه إلى 2G:

تكبير ملف swap إلى 2G بأوامر fallocate وmkswap وswapon
مخرجات حقيقية: من 1G إلى 2G
# تكبير ملف swap موجود (أو إنشاؤه إن لم يوجد)
sudo swapoff /swapfile                  # أوقفه أولًا (تجاهل الخطأ إن لم يوجد)
sudo fallocate -l 2G /swapfile          # الحجم الجديد
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# اجعله دائمًا بعد إعادة التشغيل (موجود أصلًا في قوالب مرام)
grep -q '^/swapfile' /etc/fstab || echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
رام السيرفرحجم Swap المقترح
1 إلى 2 GB1 إلى 2 GB
4 GB2 GB
8 GB فأكثر2 إلى 4 GB

تذكّر: Swap شبكة أمان وليس بديلًا عن الرام. إن رأيته مستعملًا باستمرار والسيرفر بطيء، فالحل الحقيقي تحديد استهلاك البرامج أو الترقية.

علامات الرام ممتلئة وأخطاء شائعة

لتعالج مشكلة الرام ممتلئة بشكل صحيح، انتبه لهذه العلامات والأخطاء:

  • قراءة free بدل available: رقم free الصغير طبيعي؛ الرقم الحقيقي هو available.
  • توقّف قاعدة البيانات فجأة: غالبًا OOM killer عند نفاد الذاكرة؛ تأكّد بـjournalctl -k.
  • Swap مستعمل باستمرار: مؤشّر ضغط حقيقي؛ حدّد استهلاك البرامج أو رقِّ الخطة.
  • اعتبار Swap بديلًا عن الرام: هو شبكة أمان أبطأ بمئات المرات، لا حلّ دائم.
  • عدم تحديد استهلاك PHP وMySQL: اضبط pm.max_children وinnodb_buffer_pool_size.
  • تجاهل المراقبة: اضبط تنبيه بريد عند تجاوز الذاكرة 90% لتعرف قبل التوقف.

أسئلة شائعة عن مشكلة الرام ممتلئة

كيف أعرف أن الرام ممتلئة فعلًا؟

نفّذ free -h وانظر عمود available لا free. إن كان available قليلًا وSwap مستعملًا بكثرة فالذاكرة تحت ضغط حقيقي.

ما الفرق بين free وavailable؟

free هو الفارغ تمامًا، بينما available هو ما تستطيع البرامج أخذه فعلًا لأنه يشمل الكاش القابل للتحرير. لينكس يستعمل الفارغ كاشًا عمدًا، فرقم free الصغير طبيعي.

لماذا توقفت قاعدة بياناتي وحدها؟

عندما تنفد الذاكرة يقتل لينكس أكبر عملية تلقائيًا (OOM killer)، وغالبًا تكون قاعدة البيانات، فتبدو وكأنها توقفت وحدها. تأكّد بـjournalctl -k | grep -i "killed process".

ما حجم ملف Swap المناسب؟

لرام 1-2GB اجعل Swap 1-2GB، ولرام 4GB اجعله 2GB، ولرام 8GB فأكثر 2-4GB. قوالب مرام تنشئ 1GB تلقائيًا مع swappiness=10.

هل Swap يغني عن ترقية الرام؟

لا؛ Swap شبكة أمان على القرص أبطأ بكثير من الرام. إن رأيته مستعملًا باستمرار والسيرفر بطيء فالحل الحقيقي تحديد استهلاك البرامج أو ترقية الخطة.

كيف أقلّل استهلاك الذاكرة على السيرفر؟

أعد تشغيل الخدمة المسرّبة فورًا، ثم حدّد الاستهلاك بضبط pm.max_children في PHP-FPM وinnodb_buffer_pool_size في MySQL و–memory لحاويات Docker.