كيف تحسب مواصفات الرام والمعالج المناسبة لسيرفرك قبل الشراء؟

أحد أكثر الأسئلة شيوعًا قبل شراء VPS أو Server هو:

كم أحتاج RAM؟ وكم vCPU أختار؟

المشكلة أن الإجابة لا تأتي من اسم التطبيق وحده.

موقع WordPress صغير قد يعمل براحة على موارد محدودة، بينما متجر WordPress آخر يستخدم WooCommerce وعشرات Plugins ومئات الزوار المتزامنين قد يحتاج عدة أضعاف تلك الموارد.

ونفس الأمر ينطبق على Docker وDatabases وAPIs وGame Servers وأنظمة الأتمتة.

لذلك بدل البحث عن جدول يقول:

WordPress = 2GB
Docker = 4GB
Database = 8GB

الأفضل أن تحسب احتياجك من خلال مكونات الحمل نفسها.

أولًا: RAM وCPU لا يحلان المشكلة نفسها

قبل الحساب، يجب أن تعرف الفرق.

RAM تحتفظ بالبيانات التي يحتاجها النظام بسرعة أثناء العمل:

• الـOperating System.
• الـApplication Processes.
• Database Buffers.
• Cache.
• Docker Containers.
• Queues وWorkers.

أما CPU فهي التي تنفذ العمل نفسه:

• تنفيذ PHP أو Node.js أو Python.
• تشغيل Queries.
• ضغط وفك ضغط الملفات.
• توليد Pages.
• معالجة الصور والفيديو.
• Encryption.
• AI Inference في بعض الحالات.

قد يكون لديك Server تملك RAM كثيرة لكنها بطيئة لأن CPU مشغولة باستمرار.

وقد يكون العكس: CPU شبه فارغة لكن التطبيقات تبدأ باستخدام Swap لأن RAM غير كافية.

الخطوة الأولى: اكتب كل ما سيعمل على السيرفر

قبل اختيار أي باقة، اكتب Stack كاملة.

مثال:

Ubuntu Server
Nginx
PHP-FPM
WordPress
MariaDB
Redis
Uptime Kuma
Backup Agent

أو:

Ubuntu Server
Docker
n8n
PostgreSQL
Redis
3 Workers
Nginx Proxy Manager

الخطأ الشائع هو حساب التطبيق الرئيسي فقط وتجاهل الخدمات المساندة.

n8n مثلًا لا تعمل وحدها إذا كانت بيئتك تحتوي PostgreSQL وRedis وWorkers وReverse Proxy.

قسّم RAM إلى خمس طبقات

طريقة عملية للحساب:

RAM المطلوبة =
النظام
+
التطبيقات
+
قواعد البيانات
+
الخدمات المساندة
+
هامش أمان

1. حصة نظام التشغيل

Linux نفسها تحتاج RAM.

Server خفيفة بدون Desktop قد تستهلك أقل بكثير من Windows Server أو نظام يحتوي واجهة رسومية، لكن لا تعامل استهلاك النظام على أنه صفر.

كمثال تخطيطي، من المعقول أن تحجز جزءًا من RAM للنظام والخدمات الأساسية حتى لو كان التطبيق خفيفًا.

ولا تستخدم كل RAM المتاحة للتطبيقات وتترك النظام بلا مساحة للتنفس.

2. حصة التطبيق

هنا تختلف الأرقام بشدة.

بعض التطبيقات تستخدم Process واحدة تقريبًا.

تطبيقات أخرى تشغل عدة Workers.

إذا كان كل Worker يستهلك مثلًا:

250MB

ولديك:

8 Workers

فأنت لا تتحدث عن 250MB.

بل تقريبًا:

250MB × 8
=
2000MB

وهذا قبل حساب Database والنظام وبقية الخدمات.

3. قاعدة البيانات قد تأخذ أكبر حصة

Database ليست مجرد Process تعمل في الخلفية.

MySQL أو MariaDB أو PostgreSQL تستخدم RAM للـBuffers والـCache والConnections وعمليات التنفيذ.

كلما كانت Database نشطة، زادت أهمية تخصيص RAM مناسبة لها.

في موقع صغير جدًا قد لا تكون Database هي الحمل الأكبر.

لكن في متجر أو SaaS أو تطبيق يحتوي عددًا كبيرًا من Queries، قد تصبح Database العامل الأساسي.

4. Redis والـCache ليست مجانية

الـCache تسرع التطبيق لأنها تحتفظ بالبيانات في الذاكرة.

لكن هذا يعني أنها تستخدم RAM عمدًا.

إذا قلت:

«سأستخدم Redis حتى أقلل الحمل»

فهذا صحيح من ناحية الأداء في حالات كثيرة، لكن يجب أن تحسب ذاكرة Redis ضمن الميزانية.

5. أضف Headroom

لا تشتر Server تحتاج تطبيقاتك في الظروف الطبيعية إلى 100% من مواردها.

إذا كانت حساباتك تقول:

الاستخدام المتوقع:
3.4GB RAM

فاختيار 4GB قد يعمل، لكنه يترك هامشًا ضيقًا جدًا.

أي زيادة مؤقتة في الحمل أو Backup أو Update أو Worker إضافية قد تدفع النظام نحو Swap أو OOM.

لهذا من المفيد إضافة هامش أمان.

مثال:

RAM الأساسية:
3.4GB

Headroom 25%:
0.85GB

الإجمالي:
4.25GB

في هذه الحالة 6GB أو 8GB قد تكون أكثر راحة بحسب خيارات المزود والنمو المتوقع.

كم Headroom أحتاج؟

لا يوجد رقم ثابت.

لكن يمكن استخدام نطاق تقريبي كبداية:

هذه ليست مواصفات إلزامية، وإنما طريقة تفكير.

مثال كامل: موقع WordPress متوسط

لنفترض أن لدينا:

Ubuntu
Nginx
PHP-FPM
MariaDB
Redis
WordPress
Backup Agent

ونقدر الاستخدام المتوقع في وقت عمل طبيعي:

OS + base services      700MB
PHP-FPM                 1200MB
MariaDB                 1200MB
Redis                    250MB
Other services           250MB
--------------------------------
Total                   3600MB

ثم نضيف 30% Headroom:

3600MB × 1.30
=
4680MB

في هذه الحالة 4GB ستكون ضيقة.

6GB قد تكون مناسبة، و8GB تعطي مساحة أكبر للنمو.

المهم هنا ليس الرقم نفسه؛ بل طريقة الوصول إليه.

لكن كيف أعرف استهلاك التطبيق قبل شرائه أصلًا؟

إذا كنت تنقل تطبيقًا موجودًا بالفعل، الأمر سهل نسبيًا.

راقب Server الحالية.

على Linux:

free -h
top
htop

ولـDocker:

docker stats

ولمعرفة أكثر Processes استهلاكًا للذاكرة:

ps aux --sort=-%mem | head

ولـCPU:

ps aux --sort=-%cpu | head

خذ قياسات في أوقات مختلفة، لا في وقت هادئ فقط.

إذا كان المشروع جديدًا تمامًا

هنا لن تكون لديك أرقام حقيقية بعد.

استخدم ثلاثة مصادر:

1. Minimum Requirements الرسمية للتطبيق.
2. تجربة صغيرة على بيئة Test.
3. تقدير عدد المستخدمين والعمليات المتزامنة.

ابدأ بحجم معقول يسمح بالترقية بدل شراء أكبر Server خوفًا من المستقبل.

الآن ننتقل إلى CPU

في VPS ستجد غالبًا:

1 vCPU
2 vCPU
4 vCPU
8 vCPU

لكن عدد vCPU وحده لا يخبرك بكل شيء.

أداء Core نفسها، نوع المعالج، Clock Speed، وسياسة المزود في مشاركة CPU كلها عوامل مؤثرة.

لهذا 4 vCPU عند مزود معين ليست بالضرورة مساوية تمامًا لـ4 vCPU عند مزود آخر.

هل تطبيقك Single-Threaded أم Parallel؟

هذه نقطة مهمة جدًا.

بعض الأحمال تستفيد من إضافة Cores بصورة ممتازة.

مثل:

• عدة PHP Workers.
• عدة Requests متزامنة.
• Background Jobs.
• عدة Containers.
• بعض عمليات Encoding.

أما برنامج يعتمد بصورة كبيرة على Thread واحدة، فقد لا يصبح أسرع كثيرًا بمجرد الانتقال من 4 إلى 8 vCPU إذا بقيت سرعة الـCore نفسها.

فكر بالـConcurrency وليس عدد المستخدمين فقط

موقع لديه 100,000 مستخدم مسجل لا يعني أنه يحتاج Server ضخمة.

السؤال الأهم:

كم منهم ينفذون عمليات في اللحظة نفسها؟

مثال:

100,000 Registered Users
لكن
30 Concurrent Users

هذا مختلف تمامًا عن:

5,000 Registered Users
لكن
800 Concurrent Users

طريقة تقريبية لتقدير حمل CPU

فكر في العملية الواحدة:

Request
→ Application
→ Database
→ Processing
→ Response

إذا كان التطبيق يستطيع معالجة الطلب بسرعة، CPU تتحرر سريعًا.

أما إذا كانت كل Request تحتاج Processing ثقيلة، تتراكم العمليات.

لذلك ما يهم هو:

عدد العمليات المتزامنة
×
تكلفة كل عملية

CPU Usage متوسط قد يخدعك

لنفترض أن Server فيها 4 vCPU.

وترى:

CPU Usage = 25%

قد تقول إن الوضع ممتاز.

لكن ربما هناك Process أحادية Thread تستخدم Core واحدة بنسبة 100%، بينما الثلاث الأخرى شبه فارغة.

المتوسط:

100 + 0 + 0 + 0
÷ 4
=
25%

ومع ذلك التطبيق الذي يعتمد على تلك Thread يمكن أن يكون بطيئًا.

لهذا راقب Per-Core Usage أيضًا.

Load Average ماذا يخبرك؟

على Linux ستجد:

load average:
1.20, 0.95, 0.80

الأرقام تمثل متوسط الحمل خلال فترات زمنية مختلفة.

كقاعدة مبسطة، يجب تفسير Load Average نسبة إلى عدد Cores.

Load يساوي 4 على Server فيها 4 CPU Threads ليس له المعنى نفسه على Server فيها 16.

إذا كان الحمل يتجاوز قدرة CPU بصورة مستمرة، قد تبدأ الأعمال بالانتظار.

فرق مهم: CPU Peak وCPU مستمر

وصول CPU إلى:

100%

لمدة خمس ثوانٍ أثناء Update لا يعني أنك تحتاج ترقية.

لكن:

90% - 100%

لمدة طويلة أثناء ساعات الاستخدام، مع زيادة Response Time، إشارة مختلفة تمامًا.

راقب المدة والسياق، لا الرقم فقط.

مثال: n8n وWorkers

لنفترض أن لديك n8n تقوم بأتمتة أعمال خفيفة:

Webhooks
HTTP Requests
Database Updates
Email
CRM APIs

قد لا تكون كل Workflow ثقيلة على CPU.

لكن إذا بدأت بتنفيذ:

PDF Processing
Large JSON Transformations
Image Processing
Hundreds of Concurrent Executions

يتغير الحمل.

عدد Workflows ليس المقياس الصحيح.

الأهم هو عدد Executions المتزامنة ونوع العمل داخلها.

مثال: Database Server

في Database، زيادة CPU قد تفيد في معالجة Queries متزامنة.

لكن إذا كانت المشكلة Query سيئة بلا Index، إضافة Cores قد تخفي المشكلة مؤقتًا فقط.

مثلًا:

SELECT ...
FROM orders
WHERE customer_id = ?

إذا كانت Table كبيرة و`customer_id` تحتاج Index ولا توجد، فإن تحسين Query قد يعطيك نتيجة أكبر من مضاعفة CPU.

قبل زيادة RAM، تأكد أن التطبيق يستخدمها أصلًا

Linux تستخدم RAM الفارغة كـCache، لذلك:

used

وحدها ليست أفضل رقم للحكم.

راقب:

available

أيضًا.

أمر:

free -h

يعرض لك مثلًا:

total
used
free
buff/cache
available

وجود Cache كبيرة ليس مشكلة بحد ذاته؛ Linux تستطيع تحرير جزء منها عندما تحتاج التطبيقات للذاكرة.

Swap ليست RAM إضافية مجانية

Swap مفيدة كشبكة أمان في بعض الحالات، لكنها ليست بديلًا عن RAM.

RAM أسرع بكثير من التخزين.

إذا كان النظام يعتمد بصورة مستمرة على Swap لأن الذاكرة غير كافية، ستشعر بتراجع في الأداء.

المشكلة ليست وجود Swap.

المشكلة هي الحاجة المستمرة إليها.

ماذا يعني OOM Killer؟

إذا نفدت الذاكرة ولا يستطيع Linux تلبية طلبات جديدة، قد يتدخل:

Out Of Memory Killer

ويغلق Process حتى يحافظ على النظام.

إذا وجدت Application أو Database تتوقف فجأة، راجع:

dmesg
journalctl

وابحث عن OOM Events.

لا تنس Memory Limits في Docker

قد يكون لديك Host فيها:

16GB RAM

لكن Container محددة بـ:

2GB

فتتوقف Container بسبب Limit رغم أن Host لديها RAM فارغة.

لذلك عند تشخيص Docker اسأل سؤالين:

هل Host لديها RAM؟

وهل Container مسموح لها باستخدامها؟

هل أشتري RAM أكثر أم CPU أكثر؟

لا تجعل RAM وCPU المتهمين دائمًا

قد يكون لديك:

8 vCPU
16GB RAM

ومع ذلك الموقع بطيء.

السبب قد يكون:

• Disk I/O بطيئة.
• Database Queries سيئة.
• API خارجية بطيئة.
• DNS.
• Network Latency.
• Plugin سيئة.
• Lock داخل Database.
• Application Code غير فعال.

ترقية الموارد بدون تحديد Bottleneck قد تجعلك تدفع أكثر دون حل المشكلة.

حساب سريع قبل شراء VPS جديدة

يمكنك استخدام هذه الورقة:

1) OS:
_____ MB

2) Application:
_____ MB

3) Database:
_____ MB

4) Cache / Redis:
_____ MB

5) Workers:
_____ MB

6) Monitoring / Proxy / Agents:
_____ MB

--------------------------------

Base RAM:
_____ MB

Headroom:
_____ %

Final RAM:
_____ GB

ثم CPU:

Peak concurrent requests:
_____

CPU-heavy jobs:
_____

Workers:
_____

Does the app scale across cores?
Yes / No

Current peak CPU:
_____ %

Current load average:
_____

مثال آخر: Docker Server صغيرة

لنفترض أنك تريد تشغيل:

Nginx Proxy Manager
Uptime Kuma
Vaultwarden
FreshRSS
Linkwarden

الاستخدام الشخصي خفيف.

قد تكون RAM الإجمالية منخفضة نسبيًا، ولا يوجد سبب لاختيار 16 vCPU.

في هذا النوع من الأحمال، 2 إلى 4 vCPU مع RAM مناسبة قد تكون أكثر من كافية حسب عدد المستخدمين والاستخدام الفعلي.

المهم أن لا تجمع الأرقام القصوى المعلنة لكل تطبيق كما لو أنها ستصل إلى Peak كلها في اللحظة نفسها.

وفي المقابل: لا تعتمد على Average فقط

لو كل التطبيقات تستخدم في المتوسط:

2GB

لكن Backup الليلية ترفع الاستخدام إلى:

5GB

فالمتوسط لا يحميك من Peak.

صمم للمستوى المرتفع المعقول، لا للمتوسط وحده ولا لأسوأ سيناريو خيالي.

هل شراء ضعف احتياجك دائمًا فكرة جيدة؟

لا.

Oversizing له تكلفة أيضًا.

إذا كان التطبيق يستخدم:

1.5GB RAM
و
10% من 2 vCPU

فشراء:

32GB RAM
16 vCPU

لن يجعل الموقع أسرع 16 مرة.

قد لا تلاحظ فرقًا أصلًا.

الأفضل اختيار Server تسمح بالنمو والترقية بسهولة.

متى أقرر الترقية؟

لا تنتظر حتى تتوقف Server.

حدد مؤشرات مسبقًا.

مثلًا:

Available RAM
أقل من 15%-20%
بصورة مستمرة

أو

CPU
أعلى من 80%
لفترات طويلة أثناء الاستخدام

أو

Response Time
يرتفع بوضوح أثناء Peak

الأرقام ليست قوانين ثابتة، لكنها تساعدك على اتخاذ القرار قبل الانهيار.

راقب P95 بدل المتوسط فقط

إذا كان متوسط Response Time:

200ms

فقد يبدو كل شيء ممتازًا.

لكن إذا كان P95:

2.8 seconds

فهذا يعني أن جزءًا ملحوظًا من الطلبات أبطأ بكثير من المتوسط.

التخطيط للسيرفر لا يجب أن يعتمد فقط على Average CPU وAverage RAM.

قاعدة مفيدة عند البداية

إذا كان مشروعك يسمح بالترقية دون Migration معقدة:

ابدأ بحجم يغطي:

الحمل المتوقع الحالي
+
25% إلى 40% Headroom

ثم راقب الاستخدام الحقيقي.

بعد أسبوعين أو شهر ستملك بيانات أفضل من أي Estimate كتبته قبل الإطلاق.

قبل الضغط على زر الشراء

لا تسأل فقط:

«هل 4GB تكفي؟»

اسأل:

ما التطبيقات التي ستعمل؟

كم Process أو Worker؟

كم RAM تستخدم كل واحدة؟

كم مستخدمًا يعمل بالتزامن؟

ما Peak المتوقع؟

هل الحمل CPU-heavy؟

هل Database هي Bottleneck؟

هل هناك Backups أو Jobs دورية؟

كم Headroom أحتاج؟

وهل أستطيع ترقية الخطة بسهولة؟

إذا أجبت عن هذه الأسئلة، يصبح اختيار RAM وCPU قرارًا مبنيًا على حمل حقيقي بدل التخمين.