كيفية تحسين اتصالات قاعدة بيانات Immich للحاويات المتزامنة
حسّن اتصالات قاعدة بيانات Immich من خلال قياس إجمالي الطلب على الجلسات عبر كل عمليات Immich وعملاء PostgreSQL الآخرين، بدلًا من زيادة max_connections أولًا. تحتاج قاعدة البيانات إلى عدد كافٍ من الجلسات لتلبية عبء العمل الفعلي، مع هامش احتياطي للإدارة، لكن التزامن المفرط قد يزيد استهلاك الذاكرة والتنافس دون أن يجعل الاستعلامات أسرع.
على خادم منزلي متعدد الحاويات، سجّل الاتصالات النشطة والخاملة والمنتظرة مع زمن استجابة الاستعلامات واستخدام وحدة المعالجة المركزية والذاكرة وزمن استجابة التخزين أثناء الاستخدام العادي وأثناء بدء التشغيل المتزامن. قد ينتج خطأ «عدد كبير جدًا من العملاء» عن إعدادات مجمّعة أو خدمة أخرى أو عاصفة إعادة تشغيل، حتى عندما تبدو حاوية Immich واحدة محدودة الاستهلاك.
احصر كل عملاء PostgreSQL قبل تغيير الحدود
أدرج كل عملية خادم أو نسخة متماثلة من Immich، ومهام الترحيل والصيانة، ووظائف النسخ الاحتياطي، وأدوات المراقبة، وأي تطبيقات غير مرتبطة تتصل بنسخة PostgreSQL نفسها. امنحها مستخدمين منفصلين لقاعدة البيانات حيثما كان ذلك عمليًا، كي يتمكن pg_stat_activity من إظهار الجهة التي تحتفظ بالجلسات. سجّل قيمة max_connections الحالية واحتفظ بمسار إداري واحد للاستجابة للحوادث.
يتضمن نقاش حول «عدد كبير جدًا من العملاء» في Immich تعليقًا من المشروع يفيد بأن Immich استخدم تجمعًا افتراضيًا من 10 في ذلك الإصدار. ويشير نقاش منفصل من عام 2026 إلى أن عدة عمال من Immich يمكن لكل منهم الحفاظ على تجمع. تعامل مع هذه الأرقام باعتبارها سياقًا تنفيذيًا خاصًا بالإصدار، لا رقمًا يُضرب به عشوائيًا عبر الإصدارات المستقبلية. إذا كانت قاعدة البيانات قريبة أصلًا من حد الاتصالات بينما يكون Immich خاملًا، فحدّد مالك تلك الجلسات قبل ضبط Immich. وإذا كانت الجلسات النشطة قليلة لكن الاستعلامات بطيئة، فقد يكون عدد الاتصالات عرضًا لزمن استجابة التخزين أو الاستعلامات، وليس عنق الزجاجة الأساسي.
أنشئ ميزانية اتصالات بناءً على التزامن المقاس
احجز جلسات لإدارة قاعدة البيانات، وأدوات النسخ الاحتياطي والاستعادة، وعمليات الترحيل، والمراقبة.
ثم وزّع الاتصالات المتبقية للتطبيقات على عدد عمليات Immich والتطبيقات الأخرى التي تعمل في الوقت نفسه. الهدف هو إنشاء تجمع كبير بما يكفي كي لا تنتظر الأعمال العادية بلا داعٍ، ولكن ليس أكبر مما تستطيع قاعدة البيانات تنفيذه بكفاءة.
يصف تحليل تحجيم تجمع اتصالات PostgreSQL التجمع المثالي بأنه كبير بما يكفي لتلبية الطلب العادي، مع بقائه صغيرًا قدر الإمكان، لأن تقليل جلسات الواجهة الخلفية يخفف التنافس. طبّق هذا المبدأ على طلب Immich المرصود بدلًا من نسخ حجم تجمع خادم ويب من عبء عمل آخر.
إذا كان إصدار Immich لا يوفّر عنصر تحكم مدعومًا لحجم التجمع، فلا تعدّل المكونات الداخلية لمجرد الوصول إلى رقم مستهدف. تحكّم فيما يمكنك التحكم به: عدد النسخ المتماثلة للتطبيقات، والعملاء غير المرتبطين، وتوقيت إعادة التشغيل، وتداخل النسخ الاحتياطي، وسعة قاعدة البيانات. أعد تقييم الإعدادات المدعومة عند تغيّر الإصدارات.
قلّل تبدّل الاتصالات وانتظار قاعدة البيانات قبل إضافة جلسات أخرى
وزّع بدء تشغيل الحاويات زمنيًا حتى لا تعيد Immich والتحليلات ووظائف النسخ الاحتياطي والتطبيقات الأخرى الاتصال أو تنفّذ عمليات الترحيل في الوقت نفسه. استخدم فحوصات الصحة والجاهزية التي تنتظر حتى تصبح PostgreSQL قابلة للاستخدام، لكن تجنّب حلقات إعادة المحاولة الضيقة التي تنشئ عاصفة اتصالات بينما لا تزال قاعدة البيانات تتعافى.
يضع دليل ZimaSpace حول أمان قاعدة بيانات Immich الخارجية حدًا مهمًا: بمجرد فصل PostgreSQL عن الحزمة الافتراضية، تصبح مسؤوليات الإصدار والامتدادات والصلاحيات والنسخ الاحتياطي والتراجع واضحة. لا ينبغي تقديم وكيل اتصالات أو مضيف قاعدة بيانات إضافي لمجرد إخفاء الاستعلامات البطيئة أو التخزين المشبع.
إذا كانت جلسات كثيرة خاملة وكان ارتفاع عدد التطبيقات مبررًا فعلًا، فقد يقلل مجمّع الاتصالات من جلسات الواجهة الخلفية في بعض معماريات PostgreSQL، ولكن بعد اختبار إصدار Immich المحدد، وعمليات الترحيل، ودلالات المعاملات، وسلوك العبارات المُعدّة. لا يُعد التجميع بديلًا عن إصلاح عميل منفلت أو قاعدة بيانات مثقلة.
تحقّق باستخدام الرفع والبحث والمهام وإعادة التشغيل المتزامنة
أنشئ ذروة قابلة للتكرار: نفّذ عمليات رفع نموذجية من الهاتف، وإجراء بحث أو تصفح قديم، ومزيج المهام المعتاد في الخلفية، بينما تكون الحاويات الأخرى المتوقعة نشطة. سجّل عدد الاتصالات حسب المستخدم والحالة، وأخطاء الحصول على الاتصال أو الطلب، وزمن استجابة الاستعلامات، واستخدام وحدة المعالجة المركزية والذاكرة في قاعدة البيانات، وزمن استجابة القرص. ثم أعد الاختبار بعد إجراء تغيير واحد.
يحافظ الإعداد الناجح على الجلسات دون حد الفشل مع وجود هامش إداري، ويتجنب أخطاء «عدد كبير جدًا من العملاء»، ويحافظ على زمن استجابة الاستعلامات ضمن الهدف المنزلي، ويسمح بتفريغ قوائم الانتظار بعد الذروة. لا تكون الاتصالات الإضافية مبررة إلا عندما تكون الطلبات تنتظر فعلًا الحصول على جلسة، بينما لا تزال لدى قاعدة البيانات سعة متاحة من وحدة المعالجة المركزية والذاكرة والإدخال والإخراج.
أعد تشغيل حزمة التطبيقات ثم المضيف مرة واحدة لاختبار أكبر اندفاع للاتصالات. إذا ظهر الفشل أثناء بدء التشغيل فقط، فأصلح سلوك الترتيب وإعادة المحاولة بدلًا من زيادة الحد الدائم. وإذا تراكمت الجلسات بمرور الوقت، فالتقط المستخدمين والاستعلامات المالكة لها وصعّد نمط التسرب هذا مع الإصدارات وأدلة حالة الاتصالات.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
كيفية منع تكرار المهام أو عمليات الاستيراد في Immich
افصل المهام المتكررة عن الأصول المكررة. استخدم مسارًا أساسيًا واحدًا للإدخال، وتحكّم في عمليات إعادة المحاولة وتغييرات المسارات، ثم اختبر إعادة الإدخال على مجموعة...
كيفية إصلاح Immich بعد امتلاء وحدة تخزين قاعدة البيانات الخاصة به
لا تحذف سجلات WAL الخاصة بـ PostgreSQL لتحرير المساحة مطلقًا. أوقف عمليات الكتابة في Immich، وحافظ على حالة قاعدة البيانات، وأضف سعة تخزين آمنة،...
لماذا يعيد Immich إنشاء الملفات المفقودة بمالك خاطئ؟
يجب ألا يعيد Immich إنشاء الملفات الأصلية المصدرية المفقودة بصمت. حدِّد نوع الملف المُعاد إنشاؤه والكاتب الذي أنشأه، ثم أصلح هوية الإنشاء.
