كيفية تقليل وقت بدء تشغيل Immich بعد إعادة التشغيل

إيفا وونغ هي كاتبة تقنية و ومهندسة هاوية في ZimaSpace. مهووسة بالتكنولوجيا مدى الحياة ولديها شغف بالمختبرات المنزلية والبرمجيات مفتوحة المصدر، تتخصص في تبسيط المفاهيم التقنية المعقدة إلى أدلة عملية وسهلة الفهم. تؤمن إيفا بأن الاستضافة الذاتية يجب أن تكون ممتعة وليست مخيفة. من خلال دروسها، تمكّن المجتمع من تبسيط إعدادات الأجهزة، بدءًا من بناء أول نظام تخزين شبكي NAS وحتى إتقان حاويات Docker.

إذا كان Immich يصبح قابلاً للاستخدام ببطء فقط بعد إعادة تشغيل الخادم المنزلي، فقِس أي تبعية تصبح جاهزة أخيرًا قبل محاولة «تسريع» التطبيق نفسه.

قد تؤدي إعادة التشغيل إلى جعل وحدات تخزين البيانات، أو PostgreSQL، أو مسارات الشبكة، أو DNS، أو الخدمات الأخرى تعمل بترتيب مختلف عن ترتيبها أثناء إعادة تشغيل Immich العادية. المقياس المفيد ليس وقت قول Docker إن الحاوية بدأت؛ بل الوقت المنقضي من إقلاع المضيف حتى تصبح قاعدة البيانات مستعدة لقبول الطلبات الفعلية، وتُضمّن وحدات التخزين المطلوبة، ويتوقف Immich عن إعادة محاولة الاتصال بالتبعيات، ويستطيع العميل تحميل المخطط الزمني. سجّل هذا التسلسل مرة واحدة، ثم أزل سبب الانتظار أو حلقة إعادة المحاولة الفعلية.

قِس الخط الزمني للإقلاع قبل تغيير أي شيء

أعد التشغيل خلال فترة صيانة، وسجّل وقت أربع نقاط: إمكانية الوصول إلى المضيف، وتضمين وحدات التخزين المرتبطة بـ Immich، وسلامة قاعدة البيانات، وإمكانية استخدام Immich من عميل. وسجّل أيضًا أوقات بدء الحاويات، وحالات السلامة، وعدد مرات إعادة التشغيل، وأول سطر مفيد في سجل كل خدمة. يحوّل ذلك عبارة «يبدو الإقلاع بطيئًا» إلى تأخير محدد.

قارن النتيجة بإعادة تشغيل المكدس بطريقة عادية بعد اكتمال إقلاع المضيف تمامًا. إذا أعاد Immich التشغيل بسرعة لاحقًا لكنه كان بطيئًا عند الإقلاع فقط، فمن المرجح أن يكون عنق الزجاجة تبعية تتعلق بالترتيب أو الجاهزية خارج التطبيق. وإذا كان كلاهما بطيئًا بالقدر نفسه، فتحقق من أعمال قاعدة البيانات، أو زمن استجابة التخزين، أو عمليات الترحيل، أو ضغط وحدة المعالجة المركزية بدلًا من ذلك.

لا تحسّن جميع الطبقات دفعة واحدة. تتمثل نتيجة هذه المرحلة في تحديد أول مكوّن تتأخر جاهزيته عن وقت بدء حاويته، أو يتسبب مرارًا في إعادة محاولة Immich.

تحقق من جاهزية التخزين قبل بدء Immich

تأكد من وجود كل عملية تضمين وكل مسار مدعوم عبر الشبكة، ومن احتوائه على البيانات المتوقعة، قبل بدء خدمات Immich. فقد تكون نقطة التضمين موجودة على شكل مجلد محلي فارغ بينما لا يزال القرص الفعلي أو مشاركة NAS غير متاح، ما قد يجعل التطبيق يبدأ باستخدام عرض نظام ملفات غير صحيح.

إذا كانت قاعدة البيانات أو الوسائط موجودة على وحدة تخزين تظهر متأخرًا أثناء الإقلاع، فأجعل الخدمة تعتمد على عملية التضمين على مستوى المضيف، أو أخّر تشغيل المكدس حتى يتم التحقق فعليًا من وجود عملية التضمين. يجب أن يتحقق الاختبار من نظام الملفات المضمّن فعليًا أو من علامة معروفة، لا من وجود اسم المجلد فقط.

بعد ضبط جاهزية التخزين، أعد التشغيل وقارن الطوابع الزمنية نفسها. يزيل التغيير الناجح عمليات إعادة المحاولة أو سلوك المسار الفارغ من دون تغيير إعداد Immich أثناء التشغيل المستقر. وإذا كان التخزين جاهزًا قبل قاعدة البيانات بوقت كافٍ، فانتقل إلى تسلسل التبعيات بدلًا من إضافة مؤقتات نوم عشوائية.

انتظر حتى تصبح قاعدة البيانات سليمة، لا حتى تعمل فحسب

قد تحتوي PostgreSQL على حاوية قيد التشغيل قبل أن تصبح مستعدة لقبول عبء عمل التطبيق، ولا سيما بعد توقف غير سليم، أو تأخر في التخزين، أو التهيئة، أو الاسترداد. قارن انتقال قاعدة البيانات إلى حالة السلامة مع أول أخطاء اتصال Immich في سجلات الإقلاع.

قد يؤدي ترتيب البدء البسيط إلى تشغيل حاوية تابعة قبل أن تصبح الخدمة التي تحتاج إليها جاهزة فعليًا. عندما يدعم إصدار Compose وتعريفات الخدمات لديك ذلك، يمكن أن تميّز فحوصات التبعيات المعتمدة على السلامة بين «بدأت الحاوية» و«أصبحت التبعية جاهزة». استخدمها لإزالة دورات إعادة الاتصال التي يمكن تجنبها، بدلًا من إخفاء تبعية بطيئة أو غير سليمة.

اجعل فحص الجاهزية ضيق النطاق وذا معنى. يجب أن يثبت فحص قاعدة البيانات قدرتها على قبول الاتصال الذي يحتاج إليه Immich؛ ولا ينبغي أن ينفذ استعلامًا مكلفًا يضيف تأخيرًا من جانبه. بعد أن تسبق جاهزية قاعدة البيانات بدء Immich باستمرار، كرر اختبار إعادة تشغيل المضيف قبل تغيير أي شيء آخر.

-15% OFF

ميّز بين حلقات إعادة المحاولة وأعمال الإقلاع المشروعة

إذا كان التخزين وPostgreSQL جاهزين، لكن Immich لا يزال يستغرق وقتًا أطول بكثير بعد إعادة التشغيل، فافحص سجلات التطبيق والعامل بحثًا عن حالات فشل اتصال متكررة، أو فحوصات سلامة فاشلة، أو عمليات ترحيل، أو تهيئة للمهام، أو ضغط على الموارد. تشير الأخطاء المتكررة على فواصل زمنية ثابتة غالبًا إلى الانتظار، بينما يشير استمرار عمل وحدة المعالجة المركزية أو القرص مع إحراز تقدم إلى أعمال إقلاع فعلية.

يعمل ترتيب التبعيات بأفضل شكل عند اقترانه بفحوصات سلامة ذات معنى بدلًا من التأخيرات الثابتة القصيرة. يمكن أن يساعد نمط فحص السلامة في Compose على منع التطبيق من التسابق مع قاعدة بيانات أو ذاكرة تخزين مؤقت لا تزال قيد التهيئة. اجعل الفحوصات واقعية؛ فتقصير الفواصل الزمنية حتى تبدو خدمة مريضة سليمة لا يحسّن الإقلاع.

إذا ارتفع عدد مرات إعادة التشغيل أثناء الإقلاع، فأوقف العاصفة وحدد أول تبعية غير متاحة قبل ضبط وحدة المعالجة المركزية أو الذاكرة أو معلمات بدء الصورة. يساعد فحص تبعية حلقة إعادة تشغيل الحاوية على التمييز بين متطلب سابق بطيء ومشكلة داخل Immich نفسه.

أعد التشغيل وتحقق من زمن الوصول إلى قابلية الاستخدام الفعلية

بعد إجراء تغيير واحد محدد، نفّذ إعادة تشغيل كاملة للمضيف وسجّل الطوابع الزمنية نفسها. يجب أن يؤدي التحسن الحقيقي إلى تقصير الفاصل بين جاهزية التبعيات وإمكانية استخدام عميل Immich، من دون إدخال حلقات إعادة تشغيل جديدة أو عمليات تضمين مفقودة أو أخطاء في الخلفية.

اختبر أكثر من صفحة تسجيل الدخول إلى الويب. افتح عدة صور قديمة، وأجرِ بحثًا، وحمّل مقطع فيديو تمثيليًا، وتأكد من اتصال عميل الهاتف المحمول، وارفع أصلًا واحدًا غير مهم حتى تختبر مساري القراءة والكتابة. لا يُعد الخادم «قد بدأ» لأغراض المنزل حتى تعمل هذه العمليات المعتادة.

نفّذ إعادة تشغيل ثانية بعد أول اختبار ناجح للتأكد من أن النتيجة ليست حظًا متعلقًا بالذاكرة المؤقتة أو حدثًا عابرًا في توقيت الشبكة. وإذا ظل الإقلاع غير متسق، فاحتفظ بآثار الإقلاع وركّز على المكوّن الذي تتغير جاهزيته بين التشغيلات. لا تخفِ التباين بتأخير ثابت أطول ما لم تكن تملك إشارة جاهزية أفضل.

الدعم والنصائح

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.