لا تضع حدًا لذاكرة Immich استنادًا إلى رقم عام بالغيغابايت. فهدف ذاكرة الوصول العشوائي على مستوى المضيف وسقف الذاكرة لكل حاوية يحلان مشكلتين مختلفتين: يجب أن يدعم المضيف المكدس بأكمله، بينما ينبغي أن يحمي حد الحاوية المضيف من دون إيقاف حمل عمل مشروع لـ Immich.
قد يبدو تصفح مكتبة تمت معالجتها خفيفًا، بينما تستهلك عملية بدء باردة للتعلّم الآلي، أو استيراد كبير، أو إنشاء الصور المصغرة، أو تحليل الوجوه، أو معالجة الفيديو ذاكرة أكبر بكثير. قِس أثقل حمل عمل تحتاج إليه فعليًا، واترك مساحة احتياطية لـ PostgreSQL ونظام التشغيل، واعتبر تكرار عمليات الإنهاء بسبب نفاد الذاكرة (OOM) دليلًا على فشل الحد، لا على حدوث خنق طبيعي.
قِس ضغط الذاكرة قبل اختيار الحد
سجّل الذاكرة في ثلاث حالات: التصفح الهادئ، ورفع يومي نموذجي، وأثقل حمل عمل مخطط له في الخلفية. التقط استخدام الحاوية، والذاكرة المتاحة على المضيف، ونشاط التبديل، وأحداث OOM، وما إذا كانت المهام تواصل إحراز التقدم. لا تكفي ذروة واحدة من docker stats، لأن احتساب ذاكرة Linux يشمل أنواعًا متعددة من الذاكرة تختلف في سلوك استردادها.
يوضح تفصيل ذاكرة Docker cgroup المفيد الذاكرة المجهولة، وذاكرة التخزين المؤقت المدعومة بالملفات، وذاكرة slab، بدلًا من التعامل مع الإجمالي الخام على أنه خطر بالدرجة نفسها. فالتخزين المؤقت المستقر للملفات مع وجود مساحة كافية على المضيف يختلف عن الذاكرة المجهولة التي ترتفع باستمرار، أو ضغط التبديل، أو ازدياد عداد OOM الخاص بـ cgroup أثناء مهمة Immich نفسها.
تجاوز هذه المرحلة عندما تتمكن من تحديد علامة مرتفعة قابلة للتكرار وشرح ما إذا كانت تتكوّن أساسًا من ذاكرة مؤقتة قابلة للاسترداد أم من ذاكرة عمل نشطة. إذا استمر الاستخدام في الارتفاع عبر حمل عمل لم يتغير، أو تكررت عمليات إنهاء الحاوية بسبب OOM، أو بدأ المضيف في التبديل بكثافة، فتوقف عن تحديد الحجم استنادًا إلى ذلك التشغيل وشخّص النمو غير الطبيعي أولًا.
حدّد السقف وفقًا لأثقل حمل عمل صالح في Immich
اختر حمل العمل الذي يجب أن يظل مدعومًا بعد تطبيق الحد. قد يعني ذلك في منزل ما رفع الصور من أربعة هواتف بينما تلحق مهام البحث الذكي والتعرّف على الوجوه بالركب؛ وقد يعني في منزل آخر استيرادًا أوليًا كبيرًا يتبعه تصفح عادي. ثبّت مجموعة البيانات، وإعدادات النماذج، وإعدادات التزامن، والحاويات الأخرى أثناء القياس، حتى يعكس الحد وعد خدمة محددًا.
ضع السقف الصارم أعلى من ذروة الذاكرة غير القابلة للاسترداد التي رصدتها، مع هامش قابل للقياس يكفي للارتفاعات القصيرة، مع الحفاظ على ذاكرة المضيف لـ PostgreSQL، وذاكرة التخزين المؤقت لنظام الملفات، وبيئة تشغيل الحاويات، والخدمات غير المرتبطة. وتُعد قائمة التحقق ذات الصلة من ZimaSpace حول علامات التحذير الخاصة بموارد الذكاء الاصطناعي المحلي مفيدة، لأن الحرارة والتبديل وإعادة التشغيل المفاجئة تكشف إجهادًا على مستوى المضيف قد يفوّتَه مخطط Immich وحده. لا تفسّر وصول الحاوية إلى الحد مرة واحدة على أنه دليل على الحاجة إلى مزيد من الذاكرة. الحد الفاصل المهم للفشل هو ما إذا كان حمل العمل الصالح نفسه يتباطأ بشدة، أو يفقد مهام، أو يواصل التبديل، أو يُنهى بسبب OOM. وعلى العكس، يكون الحد متساهلًا أكثر من اللازم إذا كان بإمكان Immich حرمان قاعدة البيانات أو المضيف من الموارد قبل أن يصبح cgroup الخاص به هو الحد الفاصل.
خفّض حمل العمل قبل رفع الحد بسبب نمو غير طبيعي
إذا فشل السقف المقترح أثناء نوع واحد فقط من العمل في الخلفية، فخفّض تزامن تلك المهمة أو اعزل المرحلة قبل رفع السقف. قد تختلف أنماط استهلاك الذاكرة بين التعلّم الآلي، وإنشاء الصور المصغرة، ومعالجة الفيديو، وأعمال قاعدة البيانات. قد تنجز الدفعة النشطة الأصغر العمل ببطء أكبر، لكنها تحافظ على استجابة واجهة المنزل وقابلية المضيف للتعافي.
كما تهم الأعطال الخاصة بالإصدارات. فقد وصف تقرير عن ذاكرة Immich v3.0.3 نمو عامل التعلّم الآلي إلى أن تسبب حد cgroup في حدوث OOM بعد حالة غير سليمة مرتبطة بالإعدادات المحلية. لا تحدد هذه الحالة الاستخدام الطبيعي لذاكرة Immich؛ بل توضح سبب وجوب التعامل مع النمو غير المفسر باعتباره فرعًا برمجيًا أو تكوينيًا قبل زيادة ميزانية المضيف بشكل دائم.
بعد تغيير متغير واحد يتعلق بالتزامن أو النموذج أو الإصدار، أعد تشغيل حمل العمل نفسه. احتفظ بالتغيير فقط إذا تحسّن كل من نمط الذاكرة والمهمة الأصلية في الاتجاه المتوقع. وإذا استمرت الذاكرة في الارتفاع دون الاقتراب من مستوى ثابت، فاحتفظ بالسجلات وتفاصيل الإصدار وصعّد المشكلة بدل تحويل الحد الصارم إلى رقم أكبر باستمرار.
تحقق من الحد بعد إعادة تشغيل باردة ودورة تشغيل مزدحمة
أعد تشغيل المضيف حتى تبدأ ذاكرة التخزين المؤقت وإقامة النماذج في الذاكرة من حالة باردة معروفة. نفّذ اختبارات تسجيل الدخول والتصفح المعتادة، ثم عملية الرفع النموذجية وحمل العمل في الخلفية. سجّل ذروة الذاكرة المجهولة، والتخزين المؤقت، والتبديل، وعدادات OOM، واستجابة قاعدة البيانات، ومدة تصريف قائمة الانتظار، وما إذا ظلت حاوية مهمة أخرى مستجيبة.
ينجح الحد إذا صمد أمام كل من البدء البارد وأشد دورة تشغيل طبيعية من دون عمليات إنهاء بسبب OOM، أو تبديل مستمر ومفرط، أو إعادة تشغيل متكررة للحاوية، أو توقف قائمة الانتظار عن التصريف. وينبغي أيضًا أن يترك مساحة كافية على المضيف لمهام التعافي، مثل تفريغ قاعدة البيانات أو تسجيل الدخول الإداري، أثناء انشغال Immich.
إذا فشل اختبار إجهاد اصطناعي فقط بينما ينجح كل حمل عمل منزلي محدد، فوثّق الحد المقبول بدل شراء ذاكرة لسيناريو لا تحتاج إليه.
إذا تعذر على حمل عمل حقيقي النجاح من دون استنزاف المضيف، فخفّض التزامن، أو اعزل التعلّم الآلي، أو أضف ذاكرة، أو انقل الخدمات المتنافسة؛ ثم كرر عملية التحقق نفسها قبل إعلان أمان الحد الجديد.
الدعم والنصائح
المزيد للقراءة

كيفية مواءمة سياسات إعادة تشغيل Docker مع قواعد البيانات والعاملين وتطبيقات الويب
طابِق سياسة إعادة التشغيل مع دورة حياة الخدمة ودلالات الخروج. اقرنها بفحوصات الصحة والجاهزية؛ ولا تستخدم حلقات إعادة التشغيل لإخفاء حالات فشل التبعيات.

كيفية تهيئة معرّفات مستخدمي الحاويات عبر مشاركات NAS متعددة
اربط معرّف المستخدم/معرّف المجموعة (UID/GID) لكل حاوية بالمجلدات المشتركة على جهاز NAS لديك، واستخدم المجموعات المشتركة أو قوائم التحكم بالوصول (ACLs) عند الحاجة، وتعامل...

كيفية إعداد ملفات تعريف Docker Compose لخدمات الخادم المنزلي الاختيارية
اترك الخدمات المطلوبة دون ملفات تعريف، واستخدم ملفات التعريف للأدوات الاختيارية. اختبر الأهداف والتبعيات المباشرة بدلًا من افتراض أن ملف تعريف واحدًا يشغّل حزمة...

