تخطَّ إلى المحتوى الرئيسي

حاسبة حجم الـ VPS — كم vCPU ورام تحتاج فعلاً؟

متجر ووكومرس بـ100,000 زيارة شهرية وذروة 200 مستخدم متزامن على لينكس يحتاج كحد أدنى 2 vCPU / 4 GB RAM — أي خطة KVM 2 من 2 vCPU / 8 GB (≈7-10 دولارات شهرياً). الحساب: ⌈100,000 ÷ 50,000⌉ = 2 كتلة → 2 vCPU، وذاكرة 2 × 1 × 1.75 + 0.5 = 4 GB، وقرص 50 GB NVMe ونطاق ≈ 300 GB/شهر. ومع هامش نمو +30% يصبح التوصية 3 vCPU / 6 GB KVM 4 (≈13-18 دولاراً). القاعدة: ابدأ بالخطة التي تستوعب الحد الأدنى — الترقية الرأسية على خطط KVM دقائق بلا إعادة تثبيت — ولا تشترِ خطة أكبر «احتياطاً»، فالذاكرة غير المستخدمة لا تجعل ووردبريس أسرع.

الحد الأدنى لحِملك (بلا هامش)2 vCPU / 4 GB
الموصى به مع هامش +30% → KVM 43 vCPU / 6 GB
قرص NVMe50 GB
النطاق الترددي — متوسط (100-500 جيجابايت/شهر)300 GB/mo
الحِملالزيارات/شهرvCPU / RAMالخطة
موقع ثابت100,0001 vCPU / 2 GBKVM 1
ووردبريس50,0001 vCPU / 2 GBKVM 1
ووردبريس200,0004 vCPU / 5 GBKVM 4
ووكومرس100,0002 vCPU / 4 GBKVM 2
ووكومرس300,0006 vCPU / 11 GBKVM 8
تطبيق Node.js100,0002 vCPU / 3 GBKVM 2
الحكمحجّم للحد الأدنى وهامِش للنمو: ابدأ بخطة KVM التي تستوعب مشروعك اليوم — الترقية الرأسية دقائق بلا إعادة تثبيت — ولا تدفع مقدماً لزيارات لم تأتِ بعد (ولا تُفرط فتشتري خطة لا يبررها حِملك).

حاسبة حجم الـ VPS — كم vCPU ورام تحتاج فعلاً؟

المدخلات

ما نوع مشروعك؟

ووكومرس: كتل ووردبريس بذاكرة ×1.75 — السلات واستعلامات الدفع والجلسات جائعة للذاكرة.

الزيارات الشهرية: 100,000

نحو 3,333 زيارة/يوم

ذروة المستخدمين المتزامنين: 200

دفعة الذروة للمواقع: +0 جيجابايت فوق أول 200 متزامن

حجم قاعدة البيانات؟ (لاعتمد قاعدة البيانات)

القاعدة: الذاكرة = 3 أضعاف حجم البيانات.

نظام التشغيل؟

لينكس 0.5 جيجابايت هامش — ويندوز يضيف 2 جيجابايت وقرصاً أكبر.

هل تخطط للنمو؟

هامش +30% للنمو المتوقع — يوصى به للمشاريع الصاعدة.

مثال افتراضي: ووكومرس · 100,000 زيارة · 200 متزامن · لينكس — عدّل المدخلات
الحجم الموصى به لخادمك · نموذج 2026
2 vCPU / 4 GB RAM
الحد الأدنى لحِملك → KVM 2
30 ر.س (سعر مثبّت)
⌈100,000 ÷ 50,000⌉ = 2 كتلة → 2 vCPU؛ RAM = 2 × 1 × 1.75 + دفعة 0 + نظام 0.5 جيجابايت؛ القرص 50 جيجابايت؛ النطاق ≈ 300 GB/شهر.
الحد الأدنى لحِملك (بلا هامش)2 vCPU / 4 GB
الموصى به مع هامش +30%3 vCPU / 6 GB
قرص NVMe (نظام + بيانات المشروع)50 GB
النطاق الترددي الشهري المتوقعمتوسط (100-500 جيجابايت/شهر) · ≈300 GB
خطط Hostinger KVM المطابقة
KVM 1 — 1 vCPU / 4 GB≈5-7 دولار/شهر
KVM 2 — 2 vCPU / 8 GB≈7-10 دولارات/شهر
KVM 4 — 4 vCPU / 16 GB≈13-18 دولاراً/شهر
KVM 8 — 8 vCPU / 32 GB≈25-35 دولاراً/شهر
Beyond KVM 8 — 8+ vCPU / 32+ GB≈60+ دولاراً/شهر أو سيرفر مخصص
الحكم: الحد الأدنى مقابل الموصى به

الحد الأدنى لحِملك 2 vCPU / 4 جيجابايت → KVM 2 (≈7-10 دولارات/شهر)؛ ومع هامش +30% يصبح 3 vCPU / 6 جيجابايت → KVM 4 (≈13-18 دولاراً/شهر). ابدأ بالخطة التي تستوعب الحد الأدنى: الترقية الرأسية من لوحة التحكم دقائق بلا إعادة تثبيت، فلا تدفع اليوم لزيارات لم تأتِ. ولا تُفرط بالمقابل: شراء KVM 8 لمدونة صغيرة «احتياطاً» يهدر نحو ≈25-35 دولاراً/شهر شهرياً — الذاكرة غير المستخدمة لا تجعل ووردبريس أسرع، والإشارة الصحيحة للترقية هي CPU فوق 80% باستمرار أو استخدام Swap.

حجّم للحد الأدنى وهامِش للنمو: ابدأ بخطة KVM التي تستوعب مشروعك اليوم — الترقية الرأسية دقائق بلا إعادة تثبيت — ولا تدفع مقدماً لزيارات لم تأتِ بعد (ولا تُفرط فتشتري خطة لا يبررها حِملك).

نموذج التحجيم تخطيطي من إرشادات 2026 المنشورة (كتل 50 ألف زيارة، 200 متزامن لكل وحدة، ذاكرة = 3 أضعاف البيانات) وشرائط خطط KVM المعلنة — ليست أسعاراً حية ولا ضماناً: قس CPU وRAM الحقيقيين بعد الإطلاق وأعد الحساب.

حالات شائعة (لينكس، بلا هامش، ≤200 متزامن)
الحِملالزيارات/شهرvCPU / RAMالخطة
موقع ثابت100,0001 vCPU / 2 GBKVM 1
ووردبريس50,0001 vCPU / 2 GBKVM 1
ووردبريس200,0004 vCPU / 5 GBKVM 4
ووكومرس100,0002 vCPU / 4 GBKVM 2
ووكومرس300,0006 vCPU / 11 GBKVM 8
تطبيق Node.js100,0002 vCPU / 3 GBKVM 2
تطبيق Node.js100,0005 vCPU / 6 GBKVM 8
خادم قاعدة بيانات100,0004 vCPU / 31 GBKVM 8

النتائج

💡 ضمّن هذه الحاسبة في موقعك

شارك هذه الأداة مع جمهورك. مجاني 100٪ ومتجاوب بالكامل.

كيف تعمل حاسبة حجم ال VPS

تحجيم ال VPS ليس تخميناً بل جدول تحميل: كل نوع مشروع يُقاس بوحدته — كتلة 50 ألف زيارة للووردبريس وووكومرس، وحدة 200 متزامن لNode.js، ثلاثة أضعاف حجم البيانات لقواعد البيانات، وكتلة 10 لاعبين للألعاب — ثم تُضاف هوامش ثابتة معروفة (نظام التشغيل وذروة الاستخدام وهامش النمو الاختياري). الناتج يُقارن بخطط KVM الحقيقية فتعرف الخطة التي تستوعب الحد الأدنى والتي تستوعب الموصى به، وتقرر بناءً على ميزانيتك: ابدأ بالأدنى وارتقِ رأسياً في دقائق حين تكبر الأرقام.

  1. 1

    الخطوة 1

    اختر نوع الحِمل (موقع ثابت / ووردبريس / ووكومرس / Node.js / قاعدة بيانات / خادم ألعاب) وحرّك منزلقي الزيارات الشهرية (10 آلاف - 2 مليون) والمستخدمين المتزامنين (10 - 2,000) — فتحسب الحاسبة كتل التحميل الأساسية: 1 vCPU و1 جيجابايت لكل 50 ألف زيارة للووردبريس (ووكومرس ×1.75 ذاكرة)، و1 جيجابايت لكل 200 متزامن لNode، وذاكرة = 3 أضعاف البيانات لقاعدة البيانات، وكتلة لكل 10 لاعبين للألعاب.

  2. 2

    الخطوة 2

    أضف هامش نظام التشغيل (0.5 جيجابايت لينكس أو 2 جيجابايت ويندوز) و«دفعة الذروة» للمواقع (المتزامنون ÷ 200)، ثم فعّل هامش النمو +30% إن أردت التخطيط للصعود — فتظهر المواصفات: vCPU وRAM وقرص NVMe وشريحة النطاق الشهري.

  3. 3

    الخطوة 3

    اقرأ الحكم: الحد الأدنى الذي يكفي حِملك مقابل الموصى به مع الهامش، وأصغر خطة KVM تستوعبهما (KVM 1 من 1 vCPU/4 جيجابايت إلى KVM 8 من 8/32) — مع الجدول المرجعي لحالات شائعة ورابط الأسعار الحالية للخطة المطابقة.

حالات الاستخدام

قبل شراء أول VPS: تعرف بالضبط هل مشروعك خطة KVM 1 أم أنك ستضيع شهوراً على خطة عطشى أو تبذر مالاً على خطة أكبر من حاجتك.

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

عند نقل مشروع من استضافة مشتركة: أحجام الزيارات الحالية والمتوقعة تُدخل في المنزلقات فتعرف أي خطة KVM تستقبل الترحيل بلا مفاجآت.

نصائح

  • 1

    راجع الناتج كل 3-6 أشهر: نمو الزيارات بنسبة 50% يغيّر عدد الكتل، والترقية قبل تشبّع الخطة أرخص من الطوارئ.

  • 2

    راقب مقاييس حقيقية بعد الإطلاق: CPU مستدام فوق 80% أو استخدام Swap يعني أنك على الحد — هذه إشارة الترقية لا «شعور» بالبطء.

  • 3

    ذاكرة التخزين المؤقت تُغيّر النتيجة: كاش صفحات كامل قد ينزلك درجة KVM كاملة — جرّب الكاش قبل دفع ثمن الخطة الأعلى.

الأخطاء الشائعة

  • شراء أكبر خطة «احتياطاً»: RAM غير مستخدمة لا تجعل ووردبريس أسرع — والفارق بين KVM 2 وKVM 8 يتراكم إلى مئات الدولارات سنوياً بلا مقابل.

  • نسيان نظام التشغيل والقاعدة معاً على نفس الجهاز: 1 جيجابايت «كافية نظرياً» تنفد بعد لينكس وMySQL وPHP — الحاسبة تضيف الهوامش لسبب.

  • الاعتماد على «زيارات الشهر» وحدها: ذروة المتزامنين هي ما يُسقط الخادم لحظة الإطلاق أو الحملة — لذلك فيها منزلق مستقل.

الأسئلة الشائعة

كم ذاكرة RAM يحتاج ووردبريس على VPS في 2026؟

نموذج التخطيط: كتلة واحدة لكل 50,000 زيارة شهرية تساوي 1 vCPU و1 جيجابايت ذاكرة، فوقها 0.5 جيجابايت لنظام التشغيل — أي أن 50 ألف زيارة ≈ 2 جيجابايت و100 ألف ≈ 4 جيجابايت. في الواقع العملي 2 جيجابايت هو الحد الأدنى العقلاني لموقع ووردبريس مع MySQL على نفس الجهاز (حد PHP memory_limit نحو 256M)، وإضافة إضافة تخزين مؤقت مثل LiteSpeed قد تنزلك درجة كاملة لأن الصفحات المخزنة لا تستهلك PHP أصلاً.

أيهما أهم: vCPU أم RAM؟

للحِمل النموذجي (ووردبريس، قواعد بيانات، تطبيقات PHP) ابدأ بالذاكرة: نقص RAM يعني Swap على القرص فيتباطأ الموقع انهياراً بينما نقص vCPU يعني بطئاً متناسباً فقط. أما المواقع الديناميكية الثقيلة الحسابياً (ووكومرس عند الدفع، استيرادات، كرون) فهي التي تحتاج معالجاً أكثر. لهذا يقرن نموذج الحساب 1 vCPU بكل 1 جيجابايت كنقطة بداية، ثم يترك لك تعديل الاتجاه حسب مقاييسك الحقيقية بعد الإطلاق.

متى يكفي 1 جيجابايت ذاكرة فقط؟

في حالات محددة: موقع ثابت (HTML/nginx)، بروكسي عكسي، أو واجهة API صغيرة على Node بلا قاعدة بيانات على نفس الجهاز. أما ووردبريس مع MySQL معاً في 2026 فهذا غير واقعي على 1 جيجابايت — نظام لينكس وحده يأكل نحو 0.5 جيجابايت وMySQL يحتاج مخزناً مؤقتاً على الأقل، وستعيش على ال Swap. إن أصررت على أصغر خطة، اجعلها KVM 1 بسعتها 4 جيجابايت لا خطة 1 جيجابايت قديمة الطراز.

ما قاعدة تحجيم قواعد البيانات؟

ذاكرة ≈ 3 أضعاف حجم البيانات تُبقي «الجزء الساخن» مخزّناً في الذاكرة بدل القرص: قاعدة 10 جيجابايت → نحو 30 جيجابايت RAM → خطة KVM 8 (8 vCPU / 32 جيجابايت). أقل من 1 جيجابايت بيانات تكفيها KVM 1، و50 جيجابايت فأكثر يتجاوز سقف خطط KVM — حان وقت سيرفر مخصص أو قاعدة بيانات مُدارة، أو فهرسة وتقسيم يقلص Working Set فعلياً.

هل ويندوز يحتاج فعلاً +2 جيجابايت ذاكرة؟

نعم: Windows Server يستهلك وحده نحو 2 جيجابايت في وضع الخمول مقابل نحو 0.5 جيجابايت للينكس، ويحتاج قرصاً أكبر (نحو 45 جيجابايت أساس مقابل 20). اجعلها +2 جيجابايت فقط إذا كان تطبيقك .NET أو ASP قديماً — أغلب حِزم 2026 (PHP، Node، Python، MySQL، PostgreSQL) تعمل على لينكس أفضل وأرخص، والترخيص نفسه يوفره.

ما الفرق بين التوسع الرأسي والأفقي؟

الرأسي: خطة أكبر على نفس الجهاز — لا تغيير في الكود ولا في النشر، وهو الصحيح ل95% من المشاريع الصغيرة. الأفقي: عدة أجهزة خلف موزّع أحمال — يضيف تعقيداً حقيقياً (جلسات مشتركة، نشر متعدد، قاعدة بيانات مركزية) ولا يستحق قبل أن تشبع أكبر خطة متاحة أو تحتاج توافراً جغرافياً. ابدأ رأسياً: KVM 1 → KVM 2 → KVM 4 كلها تغييرات خطة بدقائق.

مُدار أم غير مُدار (Managed vs Unmanaged)؟

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

هل أستطيع الترقية لاحقاً دون إعادة تثبيت؟

نعم على خطط KVM: الترقية رأسية من لوحة التحكم — تغيير خطة، إعادة تشغيل قصيرة بدقائق، وملفاتك وقاعدة بياناتك وإعداداتك كما هي بلا إعادة تثبيت ولا ترحيل. هذا بالضبط سبب توصية «ابدأ بالحد الأدنى المناسب»: لا تدفع اليوم مقابل زيارات لم تأتِ بعد. ومع ذلك خذ نسخاً احتياطية أسبوعية خارج الجهاز — الترقية ليست نسخة احتياطية، والقرص الصلب لا يعرف مواعيدك.