الرئيسية
» كيف
»
تتبع أخطاء الذاكرة في ترقية نظام SLES قبل إعادة المحاولة
تتبع أخطاء الذاكرة في ترقية نظام SLES قبل إعادة المحاولة
إذا أبلغ نظام SLES عن رسالة "لا يمكن تخصيص الذاكرة" أثناء الترقية، فتحقق أولاً مما إذا كانت النواة قد سجلت حدث نفاد الذاكرة، وما إذا كانت ذاكرة الوصول العشوائي (RAM) أو ذاكرة التبديل (swap) قد استُنفدت. أوقف مؤقتًا أي حمل عمل غير أساسي معروف، أو زد الذاكرة المخصصة للجهاز الظاهري فقط بعد التأكد من عدم وجود ضغط، ثم تحقق من أن Zypper وRPM لم يعودا نشطين قبل استئناف إجراء الترقية الأصلي.
مثال افتراضي: تخيل جهازًا افتراضيًا يعمل بنظام SLES 15، حيث يبدأ مسؤول النظام تحديثًا مجدولًا لحزمة برامج أثناء تشغيل مهمة معالجة بيانات ضخمة. يتوقف برنامج Zypper بسبب خطأ في تخصيص الذاكرة. المثال أدناه توضيحي فقط، وليس تقريرًا عن حادثة حقيقية أو اختبارًا؛ استخدم الأوامر لجمع الأدلة على جهازك المضيف قبل اختيار الحل.
في الحالة الافتراضية، قارن بين ذاكرة الوصول العشوائي المتاحة، ومساحة التبديل المُهيأة، ونشاط التبديل الجاري قبل تغيير الترقية.
1. تحقق مما إذا كان الخادم لا يزال قيد التحديث
لا تقم بإعادة تشغيل الجهاز، أو إنهاء عمليات الحزم، أو تشغيل أمر ترقية ثانٍ لمجرد ظهور خطأ في جلسة SSH. أعد الاتصال في جلسة ثانية وتحقق من وجود عمليات Zypper أو RPM نشطة.
pgrep -a 'zypper|rpm'
إذا كانت عملية حزمة ما لا تزال قيد التشغيل، فامنحها بعض الوقت وافحص مخرجاتها أو سجلاتها. لا تحذف ملفات قفل Zypper أثناء نشاط عملية حزمة ما. إذا لم تكن أي عملية قيد التشغيل، فاحتفظ بنص الخطأ بدقة وسجّل وقت حدوثه؛ إذ يساعد هذا الطابع الزمني في ربط سجلات النواة وسجلات الحزمة.
2. تأكيد أو استبعاد ضغط الذاكرة
قم بتجميع لقطة حديثة لذاكرة الوصول العشوائي (RAM) وذاكرة التبديل:
free -h
swapon --show
vmstat 1 5
تُعد سجلات نفاد الذاكرة في النواة بالقرب من فشل Zypper دليلاً أقوى من نص الخطأ وحده؛ هذا السجل توضيحي.
في ملف free -h`require`، تحقق من availableالعمود، وليس فقط من القيمة المحددة free؛ إذ يستخدم نظام لينكس ذاكرة الوصول العشوائي (RAM) للتخزين المؤقت. swapon --showيُظهر هذا الملف ما إذا كانت هناك مساحة تبديل (swap) ومقدار المساحة المستخدمة. في ملف `require` ، تشير القيم vmstatغير الصفرية المتكررة في الصفوف الأخيرة إلى وجود تبديل نشط؛ الصف الأول هو متوسط منذ بدء التشغيل، لذا ركز على الصفوف اللاحقة.siso
ثم ابحث عن عملية إنهاء بسبب نفاد الذاكرة (OOM) في النواة حول مكان الفشل واقرأ سجل Zypper:
يُعدّ سجلّ إنهاء العملية بسبب نفاد الذاكرة (OOM-kill) الذي يُشير إلى RPM أو Zypper أو أي عملية أخرى دليلاً قاطعاً على وجود ضغط حقيقي على الذاكرة. لا يكفي انخفاض مستوى ذاكرة الوصول العشوائي (RAM) المتاحة وحده لتشخيص المشكلة، إذ يُمكن استعادة الذاكرة المؤقتة، وقد ينتج ظهور الرسالة أيضاً عن حدّ أقصى لذاكرة العملية أو الخدمة. إذا لم يظهر أيّ إدخال لنفاد الذاكرة في النواة، فتحقق من حدود الأمر المُسبّب للمشكلة، ومن أيّ حدّ أقصى لذاكرة systemd أو الحاوية قبل إضافة ذاكرة إلى ذاكرة النظام. لا يُمكن تحديد السبب الدقيق من عبارة "لا يُمكن تخصيص الذاكرة" وحدها.
3. خفف الضغط قبل إعادة المحاولة
ارجع إلى الجهاز الظاهري الافتراضي. إذا كانت مهمة المعالجة الدفعية تستهلك الذاكرة، وكان النظام يُظهر نشاطًا مستمرًا في مساحة التبديل أو خطأ في نواة النظام بسبب نفاد الذاكرة، فاستخدم إجراء الإيقاف المؤقت أو الإيقاف المدعوم من التطبيق. لا تُنهِ قاعدة بيانات أو حمل عمل SAP أو أي خدمة أخرى ذات حالة دون اتباع خطوات إيقاف التشغيل الخاصة بمشغلها. تحقق من ذاكرة الوصول العشوائي ومساحة التبديل مرة أخرى بعد إيقاف حمل العمل مؤقتًا.
حدد عبء العمل باستخدام الذاكرة قبل مطالبة مالكه بإيقافه مؤقتًا؛ بيانات الخدمة والعملية هي أمثلة افتراضية.
إذا استمر نقص الذاكرة المخصصة للجهاز الضيف أثناء الصيانة الدورية، فقم بزيادة ذاكرة الوصول العشوائي (RAM) المخصصة له عبر برنامج إدارة الأجهزة الافتراضية أو لوحة التحكم السحابية المدعومة، ثم تأكد من أن نظام التشغيل يتعرف على المساحة الجديدة. يمكن أن توفر إضافة مساحة تبديل مساحة مؤقتة، لكنها أبطأ من ذاكرة الوصول العشوائي ولا تعالج الطلب المستمر على الذاكرة. يُعد تخطيط التخزين في نظام SLES مهمًا: على سبيل المثال، توثق SUSE قيودًا محددة لملفات التبديل على نظام ملفات Btrfs. تجنب إنشاء أو تغيير حجم مساحة التبديل أثناء الترقية إلا بعد التحقق من متطلبات نظام الملفات واللقطة والمنصة.
في حال عدم وجود سجلات نفاد الذاكرة، تحقق من الحد الذي ينطبق على العملية المعطلة. في نظام SLES 15، افحص الحد الأقصى للذاكرة المُكوّن لحمل العمل المُدار بواسطة systemd، مع استبدال اسم الوحدة النموذجية بالخدمة المتأثرة.
sudo systemctl show example-batch.service -p MemoryMax
قارن هذه القيمة بالذاكرة المتاحة. لن يتم حل مشكلة حد مجموعة التحكم (cgroup) بزيادة ذاكرة الوصول العشوائي (RAM) للجهاز الظاهري إلا إذا تم رفع الحد بشكل مناسب. في حزم الخدمة القديمة، تأكد من اسم الخاصية بالرجوع إلى وثائق systemd الخاصة بذلك الإصدار.
4. استأنف عملية الترقية المدعومة نفسها وتحقق منها
بعد انتهاء عملية تثبيت الحزمة، راجع /var/log/zypper.logآخر إجراء تم تنفيذه وأي حزمة فشلت. إذا أبلغ نظام إدارة الحزم RPM أو Zypper عن معاملة غير مكتملة، فاتبع إرشادات الاسترداد الخاصة بشركة SUSE لهذا الخطأ تحديدًا قبل إعادة المحاولة. لا تقم بإزالة ملفات قاعدة بيانات الحزمة أو الأقفال يدويًا.
استخدم مسار الترقية نفسه الذي بدأت به في الأصل. صيانة الحزم الروتينية وترحيل حزمة الخدمة عمليتان مختلفتان: توفر SUSE وثائق zypper patchلتثبيت التصحيحات المتاحة، بينما ترقيات حزمة الخدمة والإصدارات الرئيسية لها مساراتها المدعومة وإعداداتها الخاصة. لا تقم بالتبديل إلى هذا المسار zypper dupلمجرد حل مؤقت لمشكلة الذاكرة. بالنسبة لتشغيل التصحيح الروتيني، راجع العملية أولاً.
sudo zypper patch --dry-run
قم بمراجعة خطة حزمة تجريبية قبل إعادة تشغيل التحديثات الروتينية؛ استخدم الأمر الموثق لترحيل حزمة الخدمة بدلاً من ذلك.
إذا أظهرت التجربة الأولية خطة معقولة وكانت الذاكرة مستقرة، فحدد موعدًا للصيانة ونفذ الأمر المناسب لمهمتك الأصلية. أبقِ جلسة SSH متاحة، وراقب العملية، وتحقق من النتيجة بعد ذلك.
تعني عملية الاستعادة الناجحة اكتمال تثبيت الحزم أو عملية الترحيل المقصودة، وخروج Zypper بشكل سليم، وعدم ظهور أي حدث نفاد ذاكرة جديد أثناء التشغيل. إذا كان النظام قابلاً للتشغيل ولكن يجب التراجع عن ترحيل حزمة خدمة SLES نفسها، فإن عملية التراجع الموثقة من SUSE Snapper لا تُطبق إلا عند استيفاء متطلباتها، بما في ذلك وجود جذر Btrfs مدعوم ولقطات مُهيأة. لا تتعامل مع التراجع كاستجابة عامة لفشل تصحيح حزمة.
متى يجب التوقف والتصعيد
إذا تكرر الخطأ بعد تخفيف الضغط على الذاكرة، أو إذا ظلت عمليات الحزمة عالقة، أو إذا أبلغت قاعدة بيانات RPM عن تلف، فتوقف عن إعادة المحاولة. احتفظ بسجل Zypper، وسجل نواة النظام، ومستوى المنتج وحزمة الخدمة، والأمر المستخدم بالتحديد. supportconfigيمكن لأنظمة SUSE جمع بيانات تشخيصية لطلب الدعم. تساعد هذه الخطوات في التمييز بين الضغط على الذاكرة وحالات فشل التخصيص الأخرى؛ ولا يمكنها تحديد عيب خاص بالمنتج دون السجلات الكاملة وتكوين النظام.