Cloud: التنفيذات عالقة في حالة „قيد الانتظار / سيبدأ قريباً

أسئلة
,
1

وصف المشكلة/الخطأ/السؤال

مشكلتان على نفس مثيل Cloud. قد تكونان مرتبطتين فعلاً.

المشكلة أ - التنفيذات عالقة في قائمة الانتظار منذ 2026-07-01

دخلت عدة تنفيذات قائمة الانتظار المتزامنة في 2026-07-01 الساعة 00:52:48-00:52:51 بتوقيت وسط أوروبا الصيفي ولم تخرج منها أبداً. لم تنتقل أبداً إلى حالة “قيد التنفيذ”. لا يمكنني إلغاء أو إيقاف هذه التنفيذات من واجهة المستخدم، ولا يمكنني فرض بدء تشغيلها. يشير نظرة عامة على التنفيذات إلى عدم وجود تنفيذات نشطة بينما تبقى هذه الإدخالات معلقة كـ “في قائمة الانتظار / قريباً”

استمرت هذه الحالة الآن لأكثر من شهر.

مثال على التنفيذ العالق: 698563

المشكلة ب - أعطال OOM في 2026-08-01

في 2026-08-01 حوالي الساعة 00:52 بتوقيت وسط أوروبا الصيفي، قام نظام خارجي واحد بإرسال حوالي 70 استدعاء webhook خلال 30 ثانية إلى سير العمل IJ2lzInmEthm4e22. أي 2.33 طلب في الثانية. فشل عدد كبير من التنفيذات بعد ذلك مع خطأ نقص الذاكرة، أي تم قتل عملية المثيل بسبب نقص الذاكرة وأعادت التشغيل بشكل متكرر.

مثال على التنفيذ الفاشل: 778602

ما رسالة الخطأ (إن وجدت)؟

للمشكلة ب:

تم إيقاف التنفيذ عند هذه العقدة
قد يكون n8n قد نفد من الذاكرة أثناء تنفيذ هذا التنفيذ.

الطابع الزمني في تفاصيل الخطأ: 1.8.2026، 00:54:07
إصدار n8n المعروض في تفاصيل الخطأ: 2.32.7 (Cloud)

للمشكلة أ لا توجد رسالة خطأ على الإطلاق. التنفيذات ببساطة لا تبدأ أبداً.

معلومات عن إعداد n8n الخاص بك

  • إصدار n8n: 2.32.7
  • تشغيل n8n عبر: n8n Cloud
  • المثيل: - لن أشارك هنا -
  • نظام التشغيل: n8n Cloud

السياق الإضافي

تم ضبط عقدة webhook على “الرد الفوري”، لذا لا يمتد رد HTTP وقت التنفيذ. لم تكن هناك تنفيذات يدوية قيد التشغيل. لم تُستنفد حصة التنفيذ الشهرية.

2.33 طلب في الثانية معدل تافه. في حد التزامن لأي خطة، يجب أن ينتج طفرة بهذا الحجم شيئاً لا يزيد سوءاً عن تراكم قصير يتم تصريفه في غضون دقيقة تقريباً - وهو بالضبط ما يُتوثق أن قائمة انتظار التزامن تفعله: التنفيذات التي تتجاوز الحد تنتظر في الطابور وتُعالج بترتيب FIFO مع تحرر السعة. بدلاً من ذلك، أنتجت أعطال OOM على مستوى العملية.

المشكلة أ لا تقتصر على مثيلي. إنها تطابق مشاكل GitHub #23675 و #24594 وعدة تقارير من المجتمع، أكد فيها دعم n8n أن هذه الفئة من المشاكل غير قابلة للإصلاح من قبل المستخدم ويجب تصعيدها داخلياً.

ما أحتاجه

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

  2. شرح السبب الجذري للمشكلة أ. هل مسار استعادة قائمة الانتظار عيب معروف؟ هل تم شحن إصلاح أو تخطيط له، وفي أي إصدار؟ التنفيذ الذي لا يمكن بدؤه أو إيقافه أو إزالته من قبل مالك الحساب لمدة شهر ليس حالة مقبولة لمنتج مُدار.

  3. للمشكلة ب: من الواضح أنه لا توجد عزلة ذاكرة لكل تنفيذ على Cloud، لذا يمكن لتنفيذ واحد يتطلب الكثير من الذاكرة أن يسبب OOM للعملية المشتركة ويوقف كل تنفيذ آخر يعمل فيها. يجب أن تكون الخطة المُدارة التي تعلن عن حد تزامن قادرة على تشغيل هذا العدد من التنفيذات المتزامنة فعلاً دون أن تموت العملية. هذه مشكلة تحجيم وعزل على جانب المنصة ويجب إصلاحها هناك.

2

مرحباً @Brandwork_JB، بينما تنتظر الرد، إليك بعض الأشياء التي قد تساعدك:

الموارد المقترحة

تم المطابقة تلقائياً مع سؤالك.

الوثائق:

المنتدى:

@Wilson_Eugenio، @JavierOrjNeq، @Anshul_Namdev - لقد ساعدتم في حل مشاكل مماثلة من قبل، هل يمكنكم الاطلاع على هذا؟

مقترح تلقائياً من قبل روبوت مجتمع n8n. وهي نسخة تجريبية - يرجى مشاركة ملاحظاتك هنا.

3

مرحبا @Brandwork_JB

بما أنك على n8n Cloud​، لا يمكنك إجراء إصلاحات البنية التحتية بنفسك. يجب عليك تقديم الطلبات التقنية المحددة التالية إلى دعم n8n للتغلب على الرد من المستوى الأول:

  1. للمشكلة أ (التنظيف):

    • اطلب تنظيف قاعدة البيانات اليدوي​. تحديداً، اطلب منهم تشغيل استعلام على مثيلك لتعيين status = 'failed' لجميع عمليات التنفيذ في حالة queued التي تم إنشاؤها في 2026-07-01.
    • أرجع المشاكل على GitHub التي ذكرتها (#23675, #24594) للإشارة إلى أنك تعلم أن هذا فشل في آلية الحالة الخلفية.

  2. للمشكلة ب (الاستقرار):

    • التخفيف الفوري: إذا كان سير العمل IJ2lzInmEthm4e22 يعالج كميات كبيرة من البيانات، قم بتنفيذ معالجة دفعية​. بدلاً من معالجة حمولة webhook فوراً، ادفع البيانات إلى طابور (مثل RabbitMQ أو جدول قاعدة بيانات بسيط) واستخدم سير عمل “Worker” منفصل يعالج العناصر واحداً تلو الآخر أو في دفعات صغيرة.
    • طلب المنصة: اطلب من دعم n8n Cloud مراجعة حد الذاكرة لحاويتك المحددة. إذا كنت على خطة بحد تزامن عالي لكن ذاكرة وصول عشوائي منخفضة، فإن الخطة مكونة بشكل خاطئ بشكل أساسي للتزامن المعلن عنه.

اتصل بـ help@n8n.io

4

مرحباً @kjooleng ،

شكراً على نصيحتك! سأتبع تعليماتك.

بخصوص الجزء الثاني من إجابتك: سير العمل الخاص بي الذي تسبب في مشكلة OOM هنا لا يعالج كميات كبيرة من البيانات. إنه ببساطة نقطة نهاية webhook التي تحمل مجموعة بيانات وتحدّث البيانات بناءً على حمولة webhook. كما أنها عادةً ما تستغرق حوالي 1.5 ثانية فقط للاكتمال.

هل لديك خبرة مع حالات مشابهة، لأنك توصي باستخدام نظام قائمة الانتظار؟ إن كان الحال كذلك، فسأكون ممتناً لتوصية بشأن النظام الذي سأستخدمه هنا والموفر المناسب.

شكراً!

5

@Brandwork_JB

أوصيت بقائمة الانتظار لأنه، في بنية العملية المشتركة (مثل n8n)، الطريقة الوحيدة لضمان 100% الاستقرار ضد الارتفاعات المفاجئة هي فصل الاستقبال (Webhook) عن المعالجة (Workflow).

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

6

مرحباً @Brandwork_JB
حد التزامن غير واعٍ بالذاكرة، لذا فإن الارتفاع المفاجئ الذي يقع ضمنه قد يزال يفجر الكومة. ذاكرة السحابة ثابتة لكل خطة: 320 ميجابايت على Trial و Starter، 640 ميجابايت على Pro-1، 1280 ميجابايت على Pro-2، 4096 ميجابايت على Enterprise، و n8n نفسه يستهلك حوالي 180 ميجابايت من ذلك قبل تشغيل أي تنفيذ واحد. 70 تشغيلاً متوازياً لسير عمل يحمل مجموعة بيانات يحتفظ بـ 70 نسخة منفصلة من تلك المجموعة في نفس الكومة، لذا فإن سير عمل مدته 1.5 ثانية بمعدل 2.33 طلب في الثانية قد يؤدي إلى OOM للعملية.
قلل ما يحتفظ به كل تشغيل وليس ما يفعله: استعلم فقط عن السجلات التي يلمسها حمولة webhook الفعلية بدلاً من تحميل المجموعة والتضييق عليها داخل n8n. هذا هو الرافعة الوحيدة التي لديك على السحابة دون تغيير الخطة.

في إدخالات يوليو، أعادت تشغيل OOM في 1 أغسطس بالفعل مسار استرجاع البدء، الذي يستأنف التنفيذات المصفوفة حتى حد التزامن وينقل بقية الصفوف إلى الطابور. لم تتحرك هذه الصفوف عبر عمليات إعادة تشغيل متكررة، لذا فهي في حالة لا يلتقطها الاسترجاع. من المستحسن ذكر ذلك في تذكرتك، فهذا يستبعد إمكانية إصلاح إعادة التشغيل لها.
مزيد من المعلومات حول ما تعطيه كل خطة فعلاً للتزامن والصفوف:

7

احتفظ بالطابور المعلق وذاكرة OOM كحوادث منفصلة حتى يُظهر الدعم أنهما يشتركان في سبب. الصفوف المرتبطة بعمر شهر واحد بالفعل خارج ما يمكنك إصلاحه من سير عمل Cloud. تقول مستندات Cloud أن إلغاء أو حذف تنفيذ مرتبط يزيله، لذا الصفوف التي تبقى بعد كلا الإجراءين تحتاج إلى تنظيف backend.

بالنسبة لـ OOM، الوقت المنقضي هو مؤشر ضعيف للذاكرة. يمكن لسير عمل بمدة 1.5 ثانية أن يجسّد مجموعة بيانات كبيرة لكل تنفيذ، و70 عملية متداخلة تضاعف مجموعة العمل تلك. الرد فوراً يغلق استجابة webhook. تستمر العُقد المتبقية في التشغيل.

قبل إضافة RabbitMQ أو موفر آخر، اصنع نسخة بسيطة بحد أدنى تقبل نفس webhook لكنها تستبدل تحميل البيانات والتحديث بعقدة No Operation. أرسل نفس الاندفاع إلى تلك النسخة في اختبار محكوم. إذا بقيت النسخة البسيطة بحد أدنى سليمة، افحص عدد العناصر وأحجام الحقول حول تحميل البيانات في سير العمل الفعلي. إذا حدثت OOM أيضاً، زود دعم Cloud بمعرّفات التنفيذ والطوابع الزمنية الخاصة بها لأنك عزلت الفشل عن الحمل.

يمكن لطابور أن يسهل الاندفاعات، لكن سيكون تخفيفاً. لن يحذف التنفيذات اليتيمة أو يشرح السبب وراء موت عملية Cloud.

مرجع التزامن في n8n Cloud: Understand concurrency | Deploy | n8n Docs

8

حالة 70-webhooks-in-30-seconds لن يتم حلها بواسطة حدود التزامن، لأن الذاكرة تُستهلك بالفعل قبل أن يرى المحدِّد التنفيذ — يتم تحليل المتن وتحميله في الذاكرة قبل أن يصطف أي شيء. الحل الذي يستحق التوقف عنده: سير عمل واحد وظيفته الوحيدة هي كتابة المتن الخام في مكان متين وإرجاع 200 فوراً، وسير عمل ثانٍ يُشغَّل بواسطة جدولة أو قائمة انتظار يستنزف البيانات بمعدل تتحكم به أنت.

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

9

تخزين الحمولة مؤقتًا وتصريفها لاحقًا خطوة احتواء معقولة. لكن يجب أن أبقي على ادعاءات الآليتين كفرضيات فقط. الأعراض العامة لا تثبت أن n8n يحتفظ بالجسم كاملاً قبل بوابة التزامن الخاصة به في السحابة، أو أن فتحة مسربة تسببت في صفوف يوليو.

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

هذا التمييز مهم. يمكن للمخزن المؤقت أن يقلل ذروة الذاكرة المستقبلية، لكنه لن يصلح حالة النهاية الخلفية القديمة.