العودة إلى المدونة

متطلبات تشغيل n8n: كم تحتاج من RAM والمعالج فعلًا؟

فريق تحرير IM Host14 أكتوبر 20267 دقائق قراءة
متطلبات تشغيل n8n: كم تحتاج من RAM والمعالج فعلًا؟

برنامج n8n نفسه خفيف: نسخة واحدة تشغّل عددًا قليلًا من الـ workflows المجدولة تعمل عادة براحة على 1 vCPU و2 GB RAM، ومعها PostgreSQL. ما يرفع المتطلبات ليس عدد الـ workflows، بل حجم البيانات التي يحملها كل تنفيذ وعدد التنفيذات التي تعمل في الوقت نفسه. احسب حجم السيرفر على أساس ذروة التوازي وأكبر حمولة بيانات، ثم تحكّم في مساحة القرص عبر حذف سجل التنفيذات القديم تلقائيًا.

ما الذي يستهلك الذاكرة والمعالج في n8n فعلًا؟

  • التنفيذات المتزامنة: كل تنفيذ قيد العمل يحتفظ ببياناته في الذاكرة. عشرة workflows تعمل معًا تحتاج تقريبًا عشرة أضعاف ذاكرة العمل التي يحتاجها واحد.

  • حجم البيانات: يعالج n8n مخرجات العقدة (node) كاملة كقائمة عناصر، ويحتفظ التنفيذ بمخرجات كل عقدة طوال مدة عمله. workflow يسحب عشرات الآلاف من الصفوف من API أو جدول بيانات قد يحمل عدة نسخ من هذه البيانات في الذاكرة قبل أن ينتهي.

  • الملفات (Binary data): ملفات PDF والصور والمرفقات أكبر بكثير من JSON. وحسب إصدارك وإعداداتك قد يبقيها n8n في الذاكرة ما لم تحوّل تخزينها إلى وضع filesystem.

  • عقد Code: عقد JavaScript وPython تشغّل منطقك الخاص، وفي الإصدارات الحديثة تعمل داخل عمليات task runner منفصلة. الحلقات على مصفوفات ضخمة والمكتبات الثقيلة تظهر سريعًا في استهلاك الذاكرة والمعالج.

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

  • حجم طلبات الـ Webhook: كل طلب رخيص في حد ذاته، لكن الدفعات المفاجئة تتحول إلى تنفيذات متزامنة كثيرة، وهنا تنفد موارد السيرفرات الصغيرة.

  • PostgreSQL: قاعدة البيانات تحتاج حصتها من الذاكرة للتخزين المؤقت، وهي التي تكتب كل تنفيذ محفوظ.

لماذا تهم نواة سريعة واحدة أكثر من أنوية كثيرة بطيئة؟

يعمل n8n على Node.js، وحلقة الأحداث الرئيسية فيه تنفّذ JavaScript على thread واحد. لذلك تعتمد عملية n8n الواحدة بشكل كبير على نواة واحدة، حتى على سيرفر بثماني أنوية. الأنوية الإضافية تفيد مع ذلك: يستخدمها PostgreSQL وعمليات task runner والـ reverse proxy ونظام التشغيل، وفي وضع queue mode يحصل كل worker على نواته. لكن إذا رأيت نواة واحدة عند 100% والبقية شبه خاملة، فإضافة vCPU إلى إعداد بعملية واحدة لن يحل المشكلة؛ ما يحلها هو توزيع العمل على عدة workers.

SQLite أم PostgreSQL؟

افتراضيًا يحفظ n8n كل شيء في ملف SQLite داخل مجلد بياناته. هذا مناسب للتجربة والاستخدام الشخصي الخفيف. أما لأي عمل تعتمد عليه فاستخدم PostgreSQL: يتعامل مع الكتابة المتزامنة بشكل أفضل، وأسهل في النسخ الاحتياطي والضبط، ووضع queue mode في n8n مصمم حوله لا حول SQLite. التحويل يتم بمتغيرات البيئة:

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=change-me

يشرح دليل تشغيل n8n على سيرفرك الخاص للإنتاج إعداد Docker الكامل مع PostgreSQL وHTTPS.

القرص: بيانات التنفيذ والحذف التلقائي

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

# سجل التنفيذات: اجعله محدودًا
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168            # عدد الساعات (الافتراضي 336 أي 14 يومًا)
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000  # حد أقصى لعدد التنفيذات المحفوظة
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none   # احفظ التنفيذات الفاشلة فقط بالكامل
EXECUTIONS_DATA_SAVE_ON_ERROR=all

تفصيلتان تفاجئان كثيرين. الأولى أن PostgreSQL يعيد استخدام المساحة التي تحررها الصفوف المحذوفة، لكن ملفات قاعدة البيانات لا تصغر وحدها؛ فقط VACUUM FULL يعيد المساحة لنظام التشغيل، وهو يقفل الجدول أثناء عمله. الثانية أن السجلات (logs) وصور Docker والنسخ الاحتياطية المحلية تعيش على القرص نفسه. لمعرفة أين تذهب المساحة:

SELECT pg_size_pretty(pg_database_size('n8n'));
SELECT pg_size_pretty(pg_total_relation_size('execution_data'));

أقراص NVMe السريعة تفيد هنا، لأن حفظ التنفيذات وحذفها سيل مستمر من عمليات الكتابة الصغيرة على قاعدة البيانات.

إعدادات تحمي السيرفر الصغير

NODE_OPTIONS=--max-old-space-size=3072     # حد ذاكرة heap بالميجابايت، أقل من RAM المتاحة
N8N_CONCURRENCY_PRODUCTION_LIMIT=10         # حد للتنفيذات المتوازية (الوضع العادي)
N8N_DEFAULT_BINARY_DATA_MODE=filesystem     # الملفات على القرص لا في الذاكرة

  • اجعل حد ذاكرة Node.js أقل من الذاكرة المتاحة فعلًا، مع ترك مساحة لـ PostgreSQL ونظام التشغيل.

  • استخدم حدًا للتوازي حتى تنتظر دفعات الـ webhooks في الطابور بدل أن تستنزف الذاكرة.

  • عالج البيانات الكبيرة على دفعات بعقدة Loop Over Items، وانقل الجزء الثقيل إلى sub-workflow؛ فالذاكرة التي يستخدمها يمكن أن تتحرر بعد انتهائه.

  • اطلب من عقد HTTP Request وقواعد البيانات الحقول التي تحتاجها فقط بدل السجلات كاملة.

أسماء المتغيرات وقيمها الافتراضية تتغير بين الإصدارات، لذا راجع مرجع متغيرات البيئة في توثيق n8n الخاص بإصدارك.

مستويات الحجم حسب نوع العمل

هذه نقاط بداية وليست ضمانات؛ حجم بياناتك الفعلية هو ما يحدد الإجابة النهائية. وهي تقابل خططًا تبدأ من 1 vCPU و2 GB وتصل إلى 8 vCPU و32 GB.

استخدام شخصي وتعلّم

عدد قليل من الـ workflows المجدولة، بيانات JSON صغيرة، بلا معالجة ملفات. الحجم الأول بـ 1 vCPU و2 GB RAM مع PostgreSQL كافٍ عادة.

أتمتة لفريق صغير

عشرات الـ workflows لمزامنة CRM والبريد والنماذج وجداول البيانات، مع بعض الـ webhooks ومرفقات من حين لآخر. نطاق يتراوح بين 2 و4 vCPU و4 إلى 8 GB RAM يمنح n8n وPostgreSQL مساحة مريحة.

Webhooks كثيفة أو ملفات أو وكلاء ذكاء اصطناعي

زيارات واردة على دفعات، معالجة PDF أو صور، ووكلاء ذكاء اصطناعي بذاكرة واسترجاع معلومات. الأولوية هنا للذاكرة: فكّر في 8 إلى 16 GB مع 4 vCPU أو أكثر، واستخدم حدود التوازي.

workflows كثيرة متوازية وحرجة للعمل

حجم عمل مرتفع ومستمر، حيث لا يجوز أن يبطئ تنفيذ عالق بقية التنفيذات. هنا يؤتي وضع queue mode مع Redis وعمليات workers منفصلة ثماره، على سيرفر قريب من أعلى النطاق يصل إلى 8 vCPU و32 GB.

وإذا كنت ما زلت تقارن بين اشتراك n8n المُدار وسيرفرك الخاص، فمقال مقارنة تكلفة n8n Cloud والاستضافة الذاتية يغطي جانب التسعير المبني على عدد التنفيذات.

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

docker stats --no-stream                 # استهلاك المعالج والذاكرة لكل حاوية
free -h && df -h                         # الذاكرة والقرص على السيرفر
docker compose logs n8n | grep -i "memory"

افحص الاستهلاك في ساعة الذروة لا في منتصف الليل. في واجهة n8n رتّب التنفيذات حسب المدة لتجد البطيء منها، وافتحها لترى أي عقدة تحمل أكبر عدد من العناصر. رسائل مثل "n8n may have run out of memory" على تنفيذ فاشل، أو "JavaScript heap out of memory" في السجلات، دليل مباشر على نقص الذاكرة.

علامات تعني أنك تحتاج سيرفرًا أكبر

  • تنفيذات تفشل بأخطاء ذاكرة، أو الحاوية تعيد التشغيل تحت الضغط.

  • استخدام swap يرتفع ويبقى مرتفعًا في ساعات الذروة.

  • المحرر يصبح بطيئًا في فتح التنفيذات الكبيرة أو حفظ الـ workflows.

  • ردود الـ webhooks تبطؤ عندما تعمل عدة workflows معًا.

  • نواة معالج واحدة عند 100% لفترات طويلة: هذه إشارة إلى queue mode وليس فقط إلى سيرفر أكبر.

  • مساحة القرص تستمر في الزيادة رغم تفعيل الحذف التلقائي.

يحتاج n8n سيرفرًا يعمل عليه كعملية دائمة، وهذا يستبعد الاستضافة المشتركة التقليدية؛ ويشرح دليل أنواع الاستضافة أين يقع سيرفر VPS والسيرفرات المخصصة للتطبيقات.

أسئلة شائعة

هل يعمل n8n على 1 GB RAM؟

يمكنه أن يبدأ، وقد يكفي للتجربة مع SQLite. لكن مع PostgreSQL ونظام التشغيل وworkflows حقيقية، يكون 2 GB حدًا أدنى أكثر واقعية.

هل يحتاج n8n كرت شاشة GPU؟

لا. n8n ينسّق العمل ويستدعي واجهات API للنماذج عبر HTTP. الـ GPU يهم فقط إذا شغّلت نموذجًا محليًا على الجهاز نفسه، والأفضل إبقاء ذلك على عتاد منفصل.

هل SQLite مناسب للإنتاج؟

يصلح لنسخة شخصية خفيفة. أما لاستخدام فريق أو شركة فـ PostgreSQL هو الخيار الأكثر أمانًا من حيث التوازي والنسخ الاحتياطي والانتقال لاحقًا إلى queue mode.

كم مساحة قرص يحتاج n8n؟

يعتمد على عدد التنفيذات التي تحفظها ومدة الاحتفاظ بها. فعّل الحذف التلقائي، واحفظ التنفيذات الفاشلة فقط بالكامل إن أمكن، وراقب حجم قاعدة البيانات لبضعة أسابيع.

تشغيل n8n على IM HOST

تمنحك استضافة n8n من IM HOST نسخة n8n خاصة بك على سيرفر KVM مخصص بأقراص NVMe، مع أحدث إصدار من n8n وPostgreSQL مثبتين، وعنوان HTTPS بشهادة SSL مجانية، وصلاحيات root كاملة ونسخ احتياطي يومي مجاني، وتكون جاهزة خلال 15 دقيقة تقريبًا. هناك خمس خطط من 1 vCPU و2 GB حتى 8 vCPU و32 GB، بلا حد لعدد الـ workflows أو التنفيذات، ووضع queue mode مع Redis workers متاح في خطة Pro وما فوقها. السيرفرات متوفرة في ألمانيا وبولندا وبريطانيا وأمريكا ومصر؛ راجع صفحة مراكز البيانات لمعرفة المتوفر حاليًا.

المزيد من مدونتنا

اكتشف المزيد من الأدلة العملية ورؤى الخدمات من فريق IM Host.

عرض كل المقالات