مرحبا يا أصدقاء
أنا أشغّل n8n مع عمال متعددين، وكلما زادت التزامن، بدأت أفكر في إدارة اتصالات قاعدة بيانات PostgreSQL.
عمارتي تقريباً:
موازن التحميل
↓
عمال n8n متعددون
↓
PostgreSQL
قلقي هو أنه إذا فتح كل عامل اتصالات قاعدة بيانات متعددة، فقد تصل قاعدة البيانات في النهاية إلى حد الاتصال الخاص بها، مما يؤثر على أداء سير العمل والاستقرار.
أنا أفكر في استخدام موازن اتصالات مثل PgBouncer، لكني أود أن أفهم كيف يدير الآخرون هذا في الإنتاج.
بالنسبة لأولئك الذين يشغلون PostgreSQL مع نشرات n8n عالية التزامن:
كيف تقررون الإعداد الصحيح لـ max_connections؟
هل تستخدمون موازن اتصالات مثل PgBouncer، أم أن السلوك الافتراضي لـ PostgreSQL كافٍ؟
كيف تراقبون استنزاف الاتصالات قبل أن تصبح مشكلة؟
هل وجدتم أن زيادة عدد العمال أو تحسين الاستعلامات لها تأثير أكبر على أداء قاعدة البيانات الإجمالية؟
صف المشكلة/الخطأ/السؤال
ما هي رسالة الخطأ (إن وجدت)؟
يرجى مشاركة سير العمل الخاص بك
(حدد العقد على لوحتك واستخدم اختصارات لوحة المفاتيح CMD+C/CTRL+C و CMD+V/CTRL+V لنسخ ولصق سير العمل.)
مرحباً @Keira_Becky إحدى الطرق الجيدة هي تحسين استخدام الاتصالات قبل زيادة حد الاتصالات.
الطريقة الموصى بها
بدلاً من رفع max_connections بشكل مستمر، استخدم مجمع اتصالات مثل PgBouncer لإعادة استخدام الاتصالات الموجودة بكفاءة.
n8n Workers
↓
PgBouncer
↓
PostgreSQL
هذا يقلل من تكلفة الاتصال ويساعد PostgreSQL على التعامل مع التزامن الأعلى بكفاءة أكبر.
أفضل الممارسات
استخدم تجميع الاتصالات للعاملين المتعددين
اضبط max_connections بناءً على معالج الخادم وذاكرته
راقب الاتصالات النشطة والخاملة والمنتظرة
حسّن الاستعلامات البطيئة قبل إضافة المزيد من العاملين
راقب: الاتصالات النشطة
الاتصالات الخاملة
وقت انتظار الاتصال
كمون الاستعلام
استخدام المعالج والذاكرة
في بيئة الإنتاج، عادة ما يوفر تجميع الاتصالات وتحسين الاستعلامات قابلية توسع أفضل من مجرد زيادة حد الاتصال في PostgreSQL.
في نشر n8n القياسي، الصيغة ليست مجرد workers * 1. يمكن لكل عملية عامل الحفاظ على مجموعة من الاتصالات.
منطق الحساب:
المثيل الرئيسي: يحتاج إلى بعض الاتصالات لواجهة المستخدم والواجهة البرمجية والمُجدول.
العمال: عادة ما تحافظ كل عملية عامل على مجموعة صغيرة. إذا كان لديك 10 عمال وكل منها يسمح بمجموعة من 10، فأنت في 100 اتصال فقط للعمال.
الحمل الإضافي: يخصص Postgres ذاكرة لكل اتصال (تقريباً 2-10 ميجابايت حسب work_mem). تعيين max_connections مرتفعاً جداً (على سبيل المثال، 5000) بدون ذاكرة عشوائية كافية سيؤدي إلى قتل نظام التشغيل Postgres عبر قاتل OOM.
التوصية: ابدأ بـ max_connections = 200-500 لنشر متوسط الحجم. إذا تجاوزت هذا الحد، فلا تقم ببساطة بمواصلة زيادة الرقم؛ انتقل إلى مجمع اتصالات.
PgBouncer لبيئات الإنتاج عالية التزامن.
السلوك الافتراضي لـ PostgreSQL هو “عملية واحدة لكل اتصال”، وهو مكلف. يعمل PgBouncer كوكيل خفيف الوزن يدير مجموعة من الاتصالات “الحقيقية” بقاعدة البيانات بينما يسمح بآلاف الاتصالات “الافتراضية” من عمال n8n.
مرحبا @Keira_Becky
رافعة العملية لكل عملية هي DB_POSTGRESDB_POOL_SIZE، والتي تبلغ قيمتها الافتراضية 2، لذا فإن البصمة تقريبًا (العمليات الرئيسية + العمليات العاملة + معالجات webhook) مضروبة في تلك القيمة، وتحجم قاعدة البيانات حول هذا الرقم بدلاً من التقدير من عدد العمليات العاملة. ارفعها لكل عملية فقط عندما تكون العمليات العاملة في انتظار المجموعة.
قم بالتوسع بتشغيل عدد أقل من العمليات العاملة بتزامن أعلى بدلاً من العديد من العمليات العاملة بتزامن منخفض، توصي n8n بـ 5 أو أعلى لكل عملية عاملة لأن عددًا كبيرًا من العمليات العاملة منخفضة التزامن يستنزف مجموعة الاتصالات ويسبب تأخيرات وفشل:
يعتمد الأمر على حمل العمل الخاص بك، لكن بالنسبة لمعظم التطبيقات عالية التزامن، غالباً ما يُفضل تجميع المعاملات لأنه يسمح بإعادة استخدام الاتصالات بكفاءة أكبر ويدعم عدداً أكبر من العملاء المتزامنين.
يمكن أن يكون تجميع الجلسات خياراً أفضل إذا كان تطبيقك يعتمد على ميزات خاصة بالجلسة، مثل الجداول المؤقتة أو متغيرات الجلسة، حيث يحتفظ كل عميل بنفس اتصال قاعدة البيانات طوال الجلسة.
قبل اختيار وضع معين، أنصحك باختباره في بيئة التطوير والتحقق من أن سير العمل n8n الخاص بك لا يعتمد على سلوك خاص بالجلسة. ثم راقب استخدام الاتصال وزمن استجابة الاستعلام والإنتاجية الإجمالية للتأكد من أنه يعمل كما هو متوقع.
بشكل عام، يعتمد الخيار الأفضل على كيفية استخدام تطبيقك لاتصالات قاعدة البيانات، لذا من الجدير التحقق من صحته باستخدام أحمال عمل تشبه الإنتاج قبل النشر.
