Docker على VPS: كم Container تستطيع تشغيله قبل أن يتراجع الأداء؟

«كم حاوية (Container) يتحمّل خادم واحد؟» سؤالٌ يطرحه كل من يبني بيئة Docker VPS. الجواب الشائع «يعتمد» صحيح لكنه غير مُرضٍ — فقرّرنا أن نقيسه فعليًا. شغّلنا حاويات حقيقية بأعداد متزايدة على خادم مرام وراقبنا الذاكرة والمعالج وزمن الاستجابة حتى نرى أين يبدأ الأداء بالتراجع. في هذا الدليل العملي — الموجّه لمن يبحث عن Docker VPS وDevOps Hosting العربية — نكشف بالأرقام الحقيقية ما الذي يحدّ عدد الحاويات فعلًا، وكيف يختلف الجواب جذريًا بين حاوية nginx فارغة وستاكٍ كامل (تطبيق + قاعدة بيانات + كاش).

ما الذي يحدّ عدد الحاويات؟

قبل الأرقام، افهم أنّ عدد الحاويات على خادم Docker VPS لا تحدّه الحاويات نفسها بل مواردها:

• الذاكرة (RAM): أهمّ حدٍّ عمليًا. كل حاوية تحجز ذاكرة، وحين تمتلئ الذاكرة يبدأ الخادم بالـswap ثم ينهار. قاعدة بيانات تأكل أضعاف حاوية nginx فارغة.
• المعالج (CPU): الحاويات الخاملة لا تستهلكه تقريبًا، لكن الحاويات الفعّالة تتزاحم على الأنوية فيرتفع زمن الاستجابة تحت الحِمل.
• القرص والشبكة (I/O): قواعد البيانات والسجلّات تضغط على القرص؛ قرص NVMe سريع بـIOPS عالية يرفع السقف كثيرًا.

اختبار Docker VPS حقيقي على خادم مرام

لتحويل «يعتمد» إلى أرقام، أجرينا اختبارًا فعليًا على خادم مرام (Intel Xeon، 4 vCPU، 8GB RAM، Docker 29.1). شغّلنا حاويات nginx بأعداد متزايدة (1، 25، 50، 100، 150، 200)، وعند كل مستوى قِسنا: الذاكرة المستهلكة، ومتوسّط الحِمل (load)، وإنتاجية حاوية اختبار (probe) بأداة قياس الحِمل:

# قياس الكثافة (مبسّط)
for n in 1 25 50 100 150 200; do
  # شغّل حاويات حتى العدد المطلوب
  docker run -d --rm nginx:alpine sleep 100000
  free -m           # الذاكرة المستهلكة
  cat /proc/loadavg # حِمل المعالج
  bombardier -c 30 -d 5s http://127.0.0.1:8097/  # إنتاجية الـprobe
done

النتائج: الذاكرة هي القيد

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

🤝 من واقع مرام: النتائج المقاسة فعليًا: كل حاوية nginx خاملة كلّفت نحو 5 ميغابايت من الذاكرة، فبلغ استهلاك 200 حاوية حوالي 1 غيغابايت فقط. والأهمّ: الإنتاجية بقيت مستقرّة بين ~14 و15 ألف طلب في الثانية طوال الاختبار، وزمن الاستجابة p95 عند 200 حاوية كان 4.53 مِلّي ثانية فقط. صحيحٌ أنّ متوسّط الحِمل تجاوز عدد الأنوية (4) عند 100 حاوية فأكثر، لكن ذلك لم يضرّ الإنتاجية لأنّ الحاويات كانت خاملة. الدرس: على خادم Docker VPS نموذجي، الذاكرة — لا الإنتاجية — هي الجدار الذي تصطدم به أولًا.

حاوية فارغة مقابل ستاك كامل

لكن حاوية nginx فارغة ليست تطبيقًا حقيقيًا. فماذا عن ستاكٍ كامل؟ قِسنا وحدة إنتاجية واقعية (nginx + Redis + PostgreSQL) فكانت النتيجة مختلفة جذريًا:

• 200 حاوية nginx خاملة: ~1GB ذاكرة — أي مئات الحاويات ممكنة نظريًا.
• وحدة ستاك كاملة واحدة (nginx + Redis + PostgreSQL): استهلكت ~117 ميغابايت فعليًا.
• الحساب العملي: على 8GB (مع ترك هامش)، يمكن تشغيل نحو 55 وحدة ستاك كاملة تقريبًا.

ملاحظة: هذا هو جوهر السؤال: «كم حاوية؟» تعني حقًّا «كم تستهلك كل حاوية؟». المواقع الثقيلة (قواعد بيانات، تطبيقات جافا/PHP كبيرة) تحدّ العدد سريعًا، بينما الخدمات الخفيفة (nginx، microservices صغيرة بلغة Go) تسمح بكثافة أعلى بكثير.

كيف تشغّل حاويات أكثر على Docker VPS؟

لرفع سقف الكثافة على Docker VPS دون تراجع الأداء، اتبع هذه الممارسات:

# حدّد ذاكرة كل حاوية لمنعها من ابتلاع الخادم
docker run -d --memory=256m --memory-swap=256m myapp

# راقب الاستهلاك الحيّ لكل الحاويات
docker stats

# للمراقبة الكاملة: cAdvisor + Prometheus + Grafana كحاويات

💡 نصيحة: أهمّ قاعدة: اترك هامشًا (~20% من الذاكرة) ولا تملأ الخادم حتى الحافّة. الخادم الممتلئ يبدأ الـswap فينهار الأداء فجأة. وراقب دائمًا بـdocker stats أو لوحات Grafana لترى متى تقترب من الحدّ.

الخلاصة

سؤال «كم حاوية يتحمّل خادم Docker VPS؟» لا جواب ثابت له — لكن اختبارنا الحقيقي أعطى قاعدة واضحة: الذاكرة هي القيد الأول، والإنتاجية تبقى ممتازة حتى مع مئات الحاويات الخفيفة (200 nginx = ~1GB، p95 = 4.53ms). الجواب العملي يعتمد على ما بداخل حاوياتك: مئات الخدمات الخفيفة، أو عشرات من وحدات الستاك الكاملة (~55 وحدة على 8GB). فبدل السؤال «كم حاوية؟»، اسأل «كم تستهلك كل حاوية؟»، وخصّص خادمًا بذاكرة كافية وقرص NVMe سريع، وراقب دائمًا، واترك هامشًا — وستشغّل ما تحتاجه بثقة.

لتعميق رحلتك في DevOps: راجع Docker للمطورين: من Laptop إلى Production، وDocker Compose أم Kubernetes؟، وKubernetes من VPS واحد إلى Cluster. وللتوثيق الرسمي: حدود موارد Docker، وcAdvisor، وPrometheus.