وصف المشكلة/الخطأ/السؤال
وصلت جداول البيانات الخاصة بي إلى الحد الأقصى للحجم (50 ميجابايت) وبدأت عمليات Get/Update بالفشل. أرى هذه الرسالة في أعلى الصفحة:
تم استخدام 50 / 50 ميجابايت من مساحة تخزين جداول البيانات، قد تفشل العمليات. احذف البيانات لتجنب الأخطاء
لقد حذفت معظم البيانات، لكن الرسالة تستمر في الظهور، وتستمر صفحة جداول البيانات في عرض أحجام جداول البيانات القديمة المكتملة (قبل الحذف)، وتستمر العمليات بالفشل.
ما هي رسالة الخطأ (إن وجدت)؟
تم استخدام 50 / 50 ميجابايت من مساحة تخزين جداول البيانات، قد تفشل العمليات. احذف البيانات لتجنب الأخطاء
خطأ في التحقق من صحة طلب جدول البيانات: تم تجاوز حد حجم جدول البيانات: تم استخدام 50 ميجابايت، والحد هو 50 ميجابايت
معلومات عن إعداد n8n الخاص بك
- إصدار n8n: 2.1.4
- قاعدة البيانات (الإعدادات الافتراضية: SQLite): Postgres
- إعداد n8n للتنفيذ (الافتراضي: own، main): غير متأكد، ربما الإعدادات الافتراضية
- تشغيل n8n عبر (Docker، npm، n8n cloud، تطبيق سطح المكتب): Docker
- نظام التشغيل: Ubuntu
رقم الحجم يمثل التخزين الذي تحتفظ به قاعدة البيانات حالياً، وليس عدد الصفوف المباشر. حذف الصفوف يحرر المساحة المنطقية، لكن SQLite/Postgres لا يعيدان تلك المساحة إلى الملف بشكل تلقائي، وصفحة جداول البيانات تقرأ إجمالي التخزين - لذا يمكن أن يبقى الجدول معلقاً عند 50/50 MB لفترة طويلة بعد حذف الصفوف.
هناك شيئان يستحقان المحاولة: حذف جدول البيانات بالكامل وإعادة إنشاؤه بدلاً من تقليص الصفوف (هذا يسقط الجدول الأساسي ويحرر المساحة على الفور)، وإذا كنت تستخدم self-hosted، توقف n8n وقم بتشغيل VACUUM على ملف قاعدة البيانات (بالنسبة لـ Postgres: VACUUM FULL على ذلك الجدول) حتى يتم استرجاع المساحة فعلياً. الحصة محددة لكل مثيل عبر جميع جداول البيانات، لذا تحقق مما إذا كان جدول آخر لا يزال يحتفظ بمعظمها - وإذا كنت على Cloud، يمكن أن يتأخر هذا الحساب حتى تعمل وظيفة الصيانة الخاصة بهم، وهذا يستحق تذكرة مع اسم مثيلك.
مرحباً @Yaniv_Savir،
كما أشار @HomelabAgent بدقة، هذا هو سلوك تخصيص tuple الميتة في PostgreSQL MVCC (التحكم بالتزامن متعدد الإصدارات) الكلاسيكي، وليس خلل في تخزين مؤقت لعقدة سير عمل n8n.
عندما تقوم بتنفيذ استعلام DELETE قياسي أو تقليص البيانات من خلال واجهة المستخدم، لا يقوم PostgreSQL بتقليل حجم الملف فعلياً على القرص أو إرجاع الكتل إلى نظام التشغيل. بدلاً من ذلك، يقوم فقط بوضع علامة على حدود الصف باعتبارها “tuple ميتة” داخلياً. لأن محرك التحقق من جدول البيانات الخاص بـ n8n يستعلم عن مقياس التخطيط الفعلي للتخزين الكلي بدلاً من تنفيذ عدد صف نشط مباشر، تبقى حالتك محصورة في 50 / 50MB مستخدم، مما يسبب فشل جميع الطفرات اللاحقة في المنطقة الأعلى مع خطأ خروج التحقق.
إليك كيفية استرجاع مساحة التخزين على الفور في إعدادك ذو الاستضافة الذاتية:
بما أنك تقوم بتشغيل n8n عبر Docker على Ubuntu، لديك خيارين مباشران للبنية الأساسية لتنظيف تخصيص الجدول:
الخيار 1: تنفيذ VACUUM FULL (موصى به إذا كنت تريد الاحتفاظ بالجداول الفارغة)
تحتاج إلى فرض PostgreSQL لاسترجاع مساحة tuple الميتة بإعادة كتابة ملف جدول الهدف بالكامل. قم بتشغيل هذا الأمر مباشرة داخل حاوية قاعدة البيانات الخاصة بك أو من خلال عميل طرفي متصل بمثيل Postgres الخاص بك:
VACUUM FULL execution_entity;
VACUUM FULL workflow_entity;
(ملاحظة: إذا كنت تستخدم جداول بيانات n8n مخصصة، استبدل أسماء الكيانات أعلاه بأسماء جداول قاعدة البيانات المحددة الخاصة بك. ضع في الاعتبار أن VACUUM FULL يضع قفل كتابة حصري على ذلك الجدول للحظة، لذا قم بإيقاف خطوط استقبال webhook النشطة لبضع ثوان أثناء التنفيذ).
الخيار 2: الحذف والإعادة (الأسرع إذا كان يمكن حذف مخطط الجدول)
إذا كنت لا تهتم بحدود مخطط البيانات الوصفية التاريخية، قم بـ حذف أو حذف جدول البيانات بالكامل من خلال واجهة مستخدم n8n أو محطة قاعدة البيانات وأعد إنشاء مثيل جديد. يؤدي حذف الجدول إلى إطلاق كتل الملف الفيزيائي الأساسي فوراً إلى النظام، مما يؤدي إلى إسقاط مقياس الحصة مرة أخرى إلى 0 ميجابايت.
إصلاح الإنتاج طويل الأمد:
لمنع قاعدة بيانات n8n ذات الاستضافة الذاتية من الانتفاخ إلى عتبة 50 ميجابايت مرة أخرى تحت webhooks عالية الحجم، يجب عليك تكوين متغيرات التنظيف التلقائي داخل compose.yaml أو ملف .env الخاص بك:
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168 (يحذف التنفيذات الأقدم من 7 أيام)
EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000
أنا أحتفظ بنمط هندسة معقد مفتوح المصدر معدل خصيصاً لإدارة معاملات قاعدة بيانات PostgreSQL، والمثابرة الحكومية، وتحسين webhook بنظافة تحت إعدادات Docker.
لا تتردد في مراجعة منطق الفهرسة والجدول هنا إذا ساعد على تحسين استقرار البنية الأساسية الخاصة بك:
https://github.com
أخبرني إذا قام تشغيل استعلام VACUUM FULL بإسقاط تسمية تحذير التخزين 50 ميجابايت!
تصحيح صغير قبل محاولة تشغيل SQL أعلاه: execution_entity و workflow_entity ليست جداول البيانات التي أنشأتها. لن أقوم بتشغيل VACUUM FULL عليها لإصلاح تحذير الحصة هذا. يقول PostgreSQL أن FULL يحتفظ بقفل حصري لإعادة الكتابة بالكامل، لذلك هذا ليس بالضرورة عملية تستغرق بضع ثوان: PostgreSQL: Documentation: 18: VACUUM
أولاً، قم بعمل نسخة احتياطية من قاعدة البيانات وتأكد من عدد الصفوف المتبقية والأحجام جداول البيانات المتأثرة الفعلية. إذا اختفت الصفوف لكن الحجم المُبلّغ عنه ظل دون تغيير، أرفق أرقام قبل وبعد، إصدار 2.1.4 والعملية الفاشلة في تقرير الخطأ. هذا يساعد في التمييز بين محاسبة التخزين والمساحة المحتفظ بها في الجدول بدلاً من افتراض أي سبب.
توثيق n8n الحالي يوثق أيضاً N8N_DATA_TABLES_MAX_SIZE_BYTES للنسخ المستضافة ذاتياً. تحقق من الدعم في الإصدار المثبت لديك قبل استخدام هذا كمساحة مؤقتة إضافية؛ فهو لا يشرح سبب فشل حذف الصفوف في خفض الرقم. Data tables | Build | n8n Docs
مرحبا يانيف، الرقم الذي يتحقق منه n8n مقابل الحد هو الحجم الفيزيائي لتخزين جدول البيانات في Postgres (بما في ذلك الفهارس)، وليس عدد الصفوف. حذف الصفوف يجعلها مجرد علاماتٍ ميتة فقط، لذا لن ينخفض الرقم حتى يستعيد Postgres تلك المساحة فعليًا. فحص الحجم مخزّن مؤقتًا فقط لمدة ثوان إلى دقيقة واحدة، لذا التخزين المؤقت ليس ما يبقيه عند 50/50.
الطريقة الأسرع لفتح الحظر: نظرًا لأنك تستضيف بنفسك، ارفع الحد باستخدام متغير البيئة N8N_DATA_TABLES_MAX_SIZE_BYTES (بالبايتات) على حاوية n8n، ثم أعد التشغيل. على سبيل المثال، N8N_DATA_TABLES_MAX_SIZE_BYTES=209715200 يعطيك 200 ميبيبايت، وهو الافتراضي في إصدارات n8n الأحدث على أي حال.
للحصول على المساحة بالفعل: VACUUM عادي لن يؤدي إلى تقليل حجم الملفات. تحتاج إلى VACUUM FULL على جداول جدول البيانات نفسه. في psql، يجب أن يسرد \dt \*data_table\* تلك الجداول. VACUUM FULL يقفل كل جدول أثناء تشغيله، لذا قم بعمل نسخة احتياطية أولاً وافعل ذلك في وقت هادئ.
أو: إذا كان الجدول الآن فارغًا في الغالب، فصدّر الصفوف المتبقية إلى CSV، احذف وأعد إنشاء الجدول، وأعد الاستيراد. حذف الجدول يحرر تخزينه على الفور.
أيضًا، 2.1.4 متأخر كثيرًا عن الإصدار المستقر الحالي (2.43)، لذا يستحق الترقية التخطيط بمجرد فتح الحظر.
إضافة صغيرة واحدة إلى خطوات Santosh: قبل وبعد VACUUM FULL، من المفيد التحقق مما يبلغ عنه Postgres فعليًا لتخزين جدول البيانات، حتى تعرف ما إذا كانت المساحة قد عادت فعلاً. شيء مثل:
SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) AS total_sizeFROM pg_catalog.pg_statio_user_tablesWHERE relname LIKE '%data_table%'ORDER BY pg_total_relation_size(relid) DESC;
إذا انخفضت الحجم بعد VACUUM FULL لكن n8n لا يزال يعرض 50/50 لأكثر من دقيقة أو دقيقتين، فإن ذلك يشير إلى فحص الحجم نفسه بدلاً من Postgres، وهذه الأرقام قبل وبعد هي بالضبط ما ستحتاجه تقرير الأخطاء.