حلّ المجتمع

تسرّب ذاكرة النسخ الاحتياطي في ZimaOS وحلقة نفاد الذاكرة: الإصلاح الحالي

ZimaOS 1.7.0 users documented runaway Backup memory use, OOM kills, restart loops, and temporary recovery by masking the service.

إذا نما icewhale-files-backup ليستهلك عدة غيغابايت من ذاكرة الوصول العشوائي (RAM) وتسبب مرارًا في تشغيل قاتل نفاد الذاكرة (OOM) على ZimaOS 1.7.0، فحدّث إلى ZimaOS 1.7.1 أو إصدار أحدث أولًا. توضح ملاحظات إصدار IceWhale 1.7.1 صراحةً أنه تم إصلاح الاستخدام غير الطبيعي للذاكرة في بعض سيناريوهات عمليات الملفات، إضافةً إلى مشكلات فشل النسخ الاحتياطي أو انقطاعه.

وثّق النقاش الأصلي تراجعًا خطيرًا في الإصدار 1.7.0: ارتفع استهلاك الذاكرة من نحو 3.5 غيغابايت إلى أكثر من 10 غيغابايت، فأنهت النواة عملية Backup، ثم أعادها Restart=always، وأدت الدورة إلى زعزعة استقرار الخادم. أوقف إخفاء الخدمة الحلقة، لكنه لم يكن سوى حل طارئ مؤقت.

تعرّف على حلقة نفاد الذاكرة

journalctl -k | grep -i -E 'oom|out of memory|killed process'
ps aux --sort=-%mem | head
free -h

إذا عادت عملية Backup مرارًا لتكون أكثر العمليات استهلاكًا للذاكرة، فقد تؤدي حلقة إعادة التشغيل إلى استنزاف موارد Docker والخدمات الأخرى.

حدّث إلى الإصدار 1.7.1 أو إصدار أحدث

تسرد ملاحظات إصدار ZimaOS 1.7.1 الرسمية إصلاحات للاستخدام غير الطبيعي للذاكرة ولمهام النسخ الاحتياطي التي كان يمكن أن تفشل أو تنقطع.

الاسترداد الطارئ على الإصدار 1.7.0

sudo systemctl stop icewhale-files-backup.service
sudo systemctl disable icewhale-files-backup.service
sudo systemctl mask icewhale-files-backup.service

كان إخفاء الخدمة ضروريًا لأن الإيقاف أو التعطيل العاديين لم يمنعا دائمًا إعادة تشغيلها وفق سياسة إعادة التشغيل الخاصة بها.

افهم ما الذي يتعطل عند إخفاء الخدمة

يؤدي إخفاء الخدمة إلى تعطيل Backup المدمج. استخدمه فقط لتحقيق استقرار مضيف غير قابل للاستخدام لفترة تكفي للتحديث أو استرداد البيانات.

ألغِ إخفاء الخدمة بعد التحديث

sudo systemctl unmask icewhale-files-backup.service
sudo systemctl enable icewhale-files-backup.service
sudo systemctl start icewhale-files-backup.service

بعد ذلك، شغّل نسخة احتياطية صغيرة ومضبوطة مع مراقبة الذاكرة وذاكرة التبديل.

كانت أعباء النسخ الاحتياطي إلى USB من المحفزات الشائعة

أبلغ عدة مستخدمين عن سلوك مشابه عند استخدام وجهات نسخ احتياطي عبر USB. يساعد ذلك في إعادة إنتاج الخلل، لكنه لا يثبت أن العلبة نفسها تسببت فيه.

تحقق من اكتمال النسخ الاحتياطي

قارن عدد الملفات في المصدر والوجهة، وأجرِ اختبار استعادة. يساعد دليل التحقق من النسخ الاحتياطي في تقليل الاعتماد على مهمة واحدة.

تحقق مما إذا كان Docker قد تضرر بسبب استنزاف الذاكرة

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

ابدأ بنسخة احتياطية صغيرة بعد التحديث

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

عدد الملفات لا يقل أهمية عن حجم البيانات

يمكن لمئات الآلاف من الملفات الصغيرة أن تنشئ عملًا أكبر بكثير على مستوى البيانات الوصفية مقارنةً بعدد قليل من ملفات الوسائط الكبيرة. عند إرسال تقرير إلى الدعم، أدرج الحجم الإجمالي بالبايت والعدد التقريبي للملفات.

احتفظ بمسار نسخ احتياطي مستقل أثناء الاختبار

إذا كان Backup المدمج غير مكتمل أو غير مستقر سابقًا، فاحتفظ بنسخة أخرى موثوقة باستخدام أداة أو وجهة منفصلة إلى أن يؤكد اختبار الاستعادة أن مهمة ZimaOS الحالية موثوقة.

احتفظ بالسجلات من قبل الإصلاح وبعده

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

إذا استمر استهلاك الذاكرة في النمو بلا حدود في الإصدار المُصلح، فأوقف المهمة وأرسل قياسات ما قبل التحديث وما بعده إلى الدعم.

الأسئلة الشائعة

هل أكد عدة مستخدمين حدوث تسرب الذاكرة؟

نعم. أبلغ عدة مستخدمين عن السلوك نفسه في الإصدار 1.7.0.

هل عالج الإصدار 1.7.1 هذا النوع من المشكلات؟

نعم. يتضمن سجل التغييرات الرسمي إصلاحات للذاكرة والنسخ الاحتياطي تتطابق مباشرةً مع هذه المشكلة.

هل ينبغي أن أعود إلى الإصدار 1.6.2؟

كان ذلك حلًا مؤقتًا قبل الإصدار 1.7.1. ينبغي للمستخدمين الحاليين تفضيل الإصدار المستقر المُصلح.

كيف أعرف أن الإصلاح نجح؟

شغّل نسخة احتياطية مضبوطة مع مراقبة الذاكرة وذاكرة التبديل والسجلات واكتمال الملفات في الوجهة.