عقدة كود JavaScript تفشل بعد 60 ثانية مع حمل CPU مرتفع – Python يعمل بشكل صحيح

أسئلة
1

مرحبا بك في مجتمع n8n،

أقوم بتشغيل n8n في إصدارات Enterprise (Kubernetes/Linux) وCommunity (Docker Desktop/Windows 11)، مع تفعيل Queue Mode (عاملين 2) وTask Runners خارجية لتنفيذ JavaScript و Python.

أثناء اختبار الحمل، أنشأت عقدتي Code:

  • JavaScript: تولد حملاً عالياً على المعالج لمدة محددة (مثلاً 70 ثانية).
  • Python: تفعل الشيء ذاته.

الملاحظة:

  • JavaScript: بعد حوالي 60 ثانية، يتم إنهاء العامل مع:

    2026/09/14 14:00:20 WARN [launcher:js] Found runner unresponsive (n/6)

    …

    2026/09/14 14:00:40 WARN [launcher:js] Found runner unresponsive too many times, terminating runner…

    يفشل سير العمل برسالة خطأ: تم إيقاف تنفيذ المهمة لأن العامل أصبح غير مستجيب.

  • Python: يعمل بسلاسة لمدة 70 ثانية كاملة، مع نجاح فحوصات الصحة كل 10 ثوانٍ:

    2026/09/16 07:55:20 DEBUG [launcher:py] Found runner healthy

الإعدادات:

  • N8N_RUNNERS_TASK_TIMEOUT=300 (حد أقصى للمهمة 5 دقائق)
  • N8N_RUNNERS_TASK_REQUEST_TIMEOUT=300 (حد أقصى للبدء 5 دقائق)
  • N8N_RUNNERS_HEARTBEAT_INTERVAL=120 (نبضة القلب 2 دقيقة، بلا تأثير)

الفرضية:
عملية Node.js للعامل JavaScript مقفولة بعمليات متزامنة وكثيفة على المعالج (مثلاً حلقات ضيقة)، مما يمنعها من الاستجابة لفحوصات الصحة. Python، الذي يعمل في بيئة تشغيل منفصلة، لا يقفل Node.js، لذا تنجح فحوصات الصحة.

السؤال:
هل هناك طريقة لتشغيل كود JavaScript عالي الحمل لأكثر من 60 ثانية دون إنهاء العامل؟ على سبيل المثال:

  • طريقة للاستجابة لفحوصات الصحة رغم حمل المعالج العالي مع JS؟
  • تعديل إعدادات لتمديد تسامح “عدم الاستجابة”؟
  • أم أن هذا قيد أساسي من تصميم عامل JS؟

شكراً على أي معلومات!

2

@alatten

تنبع المشكلة من طبيعة Node.js أحادية الخيط في Event Loop التي يستخدمها معالج مهام JavaScript. عندما تقوم بتنفيذ JavaScript ثقيل أو متزامن أو كثيف الاستهلاك للموارد (مثل حلقة for محكمة)، فإنك تحجب بفعالية Event Loop من معالجة أي مهام أخرى. نظراً لأن المعالج يعتمد على نفس الحلقة للاستجابة لفحوصات صحة n8n وإشارات نبضات القلب، تصبح العملية غير قادرة على الاعتراف بمجسات المشغّل، مما يؤدي إلى خطأ “عدم الاستجابة” والإنهاء اللاحق.

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

لمنع ذلك في JavaScript، يجب عليك تجنب الكتل المتزامنة طويلة المدى من خلال تنفيذ “المعالجة المتعددة التعاونية”. يمكن تحقيق ذلك بتقسيم المهام الكبيرة إلى أجزاء أصغر واستخدام await new Promise(resolve => setImmediate(resolve)) للتنازل بشكل دوري عن التحكم إلى Event Loop، مما يسمح بمعالجة فحوصات الصحة. بدلاً من ذلك، بالنسبة لأعباء العمل الحسابية البحتة، من الأفضل نقل المنطق إلى معالج Python أو خدمة خارجية حيث لن يؤدي استخدام CPU العالي إلى إنهاء المعالج.

3

مرحبًا @alatten
التفاصيل الناقصة هي أن السجل الخاص بك يأتي من فحوصات صحة HTTP في المشغّل. N8N_RUNNERS_HEARTBEAT_INTERVAL يتحكم في نبضات القلب بين المشغّل والوسيط، لذا فإن زيادته لا تمدد هذا الفحص المنفصل.

في المشغّل 1.4.7، فترة الاستشعار مشفرة بقيمة ثابتة وهي 10 ثوان، وانتظار الاستجابة هو 5 ثوان، والإنهاء يحدث بعد ستة أخطاء متتالية. لا توجد متغيرة بيئة لهذا الحد في هذا الإصدار.

4

شكراً لإعلامك بهذا الأمر، لقد أنشأنا CAT-4556 كتذكرة تطوير داخلية للنظر فيها.

5

الحل الموصى به هو تسليم حلقة الأحداث

قسّم العمل الثقيل إلى أجزاء صغيرة وأرجع السيطرة بشكل دوري:

const start = Date.now();
const duration = 70_000; // 70 seconds

while (Date.now() - start < duration) {
// قم بجزء من العمل الثقيل هنا
for (let i = 0; i < 100000; i++) {
// عملك على وحدة المعالجة المركزية
}

// سلّم السيطرة لكي تتمكن فحوصات الصحة من العمل
await new Promise(resolve => setImmediate(resolve));
}

يمكنك أيضاً استخدام await new Promise(r => setTimeout(r, 0)).