السلام عليكم الجميع،
أنا أستخدم n8n Cloud Starter، الإصدار 2.17.5.
سير عمل يعالج حوالي 120-400 عنصر من خلال Loop Over Items و HTTP Requests يواجه خطأ “connection lost / offline” ويتم قطع التنفيذ.
بيانات التنفيذ غير موثوقة أو لم يتم حفظها بشكل صحيح.
يحدث هذا حتى بعد تقليل الحمولة واستخدام Data Tables.
هل يمكنك تأكيد ما إذا كانت هذه مشكلة تتعلق بموارد Cloud / انتهاء المهلة الزمنية، وما إذا كانت خطتي يمكنها دعم هذا الحمل؟
مرحباً @kourG، أهلاً وسهلاً!
أود أن أقول إن هذا الرقم قد يكون قيداً على خطة cloud starter الخاصة بك إذا لم تكن سير العمل الخاص بك محسناً، على الرغم من أن 120-400 لا يزال رقماً كبيراً لوصول compute في خطة starter:
إليك بعض التوجيهات التي يمكنك مراعاتها لتحسين هذا التدفق:
يمكن لترقية خطتك أيضاً أن تحل هذه المشكلة، لكن ذلك يعتمد على حالة الاستخدام الخاصة بك؛ إذا كانت ستنمو، فقد تحتاج للذهاب أعلى من ذلك.
في Cloud Starter، عندما يصل عدد العناصر من 120 إلى 400 من خلال Loop Over Items بالإضافة إلى HTTP Requests وتحصل على خطأ “connection lost”، فعادة ما يكون السبب تجاوز الخطة لحدود الذاكرة أو المهلة الزمنية وليس الإنترنت لديك، خاصة إذا كان كل عنصر يحمل حمولة كبيرة الحجم، لأن n8n تحتفظ ببيانات التنفيذ في الذاكرة طوال التشغيل.
هناك عدة أشياء تساعد. قلل ما يحمله كل عنصر قبل الحلقة، احذف الحقول التي لا تحتاجها حتى تبقى الحمولة المخزنة في الذاكرة صغيرة، الحلقة تحتفظ بكل شيء. عالج في دفعات فرعية أصغر واكتب النتائج أثناء السير (إلى جدول Data Table أو متجر خارجي) بدلاً من تجميع كل شيء في تنفيذ واحد، حتى لا يؤدي الفشل في منتصف الطريق إلى فقدان التشغيل بالكامل. وفكر في تقسيم العمل: سير عمل واحد يرتب العناصر في قائمة انتظار، وآخر يُشغّل لكل دفعة، بحيث لا يضطر تنفيذ واحد إلى الاحتفاظ بحالة 400 عنصر.
جزء “بيانات التنفيذ غير موثوقة أو غير محفوظة” هو الخطر الحقيقي بالنسبة لك، لأن التشغيل الذي يتعطل في منتصف حلقة غالباً ما يكون قد أنجز بالفعل نصف عمليات HTTP الكتابة، ولا يمكنك معرفة أيها من التنفيذ المعطل. اجعل عمليات الكتابة قابلة للتكرار وتتبع العناصر المكتملة في جدول خارجي، حتى يتخطى إعادة التشغيل العناصر المكتملة بالفعل بدلاً من تكرارها. هل يفشل عند عدد عناصر ثابت، أم عشوائياً؟ الثابت يشير إلى حد الذاكرة.
مرحباً بك في مجتمع n8n @kourG
هل يمكنك من فضلك التحديث إلى الإصدار المستقر 2.23.4 والإبلاغ إذا استمرت المشكلة؟
شكراً لكم على الردود.
لقد حاولت بالفعل تقليل حجم البيانات المنقولة وتخزين البيانات المرحلية في جداول البيانات. ومع ذلك، عندما تحدث مشكلة “فقدان الاتصال / وضع عدم الاتصال”، لا يبدو أن أي بيانات تبقى في الجدول، كما لو أن التنفيذ لم يكتمل أبداً أو أن النتائج المرحلية لم تُحفظ.
لهذا السبب، أحاول فهم ما إذا كانت المشكلة مرتبطة بحد موارد Cloud Starter أو انتهاء المهلة الزمنية للتنفيذ.
فيما يتعلق بالاقتراح باستخدام الدفعات، إذا فهمت بشكل صحيح، فأنت توصي بأن أقسم العناصر الـ 120-400 إلى مجموعات أصغر ومعالجتها بشكل تدريجي بدلاً من التنفيذ في عملية كبيرة واحدة. أنا أيضاً أفكر في ما إذا كان من الممكن تحميل دفعة جديدة بعد انتهاء الدفعة الحالية من المعالجة في الحلقة، بحيث يمكن للسير العملي أن يستمر في أجزاء أصغر. سأجرب هذا النهج وأرى ما إذا كان يحسن الاستقرار.
أيضاً، أنا أستخدم n8n Cloud Starter وليس لدي سيطرة مباشرة على ترقية إصدار n8n، لأن الإصدار يُدار بواسطة n8n Cloud. هل يمكنك من فضلك التأكيد على ما إذا كان الإصدار 2.23.4 متاحاً بالفعل على Cloud، أم أن هناك حاجة إلى أي إجراء من فريق n8n؟
نعم، لكن اجعل كل دفعة عملية تنفيذ منفصلة. حلقة التكرار على العناصر التي تحمل الدفعة التالية داخل نفس التشغيل لا تزال تشارك مغلف انتظار/ذاكرة واحد، لذا عندما يتم مقاطعة هذا التشغيل قد تختفي نقطة التفتيش معه.
استخدم تشغيلاً واحداً للمطالبة بدفعة صغيرة، واكتب كل نتيجة/حالة عنصر قبل الانتقال إلى العنصر التالي، ثم اترك جدولة أو تنفيذ سير عمل لبدء الدفعة التالية من الصفوف التي لا تزال محددة بعلامة معلقة. بخصوص أعراض جدول البيانات، حدد موقع عقدة الكتابة: قبل طلب HTTP، بعد كل عنصر، أم فقط بعد انتهاء الحلقة بأكملها؟