تتبع أخطاء الذاكرة في ترقية نظام SLES قبل إعادة المحاولة

إذا أبلغ نظام SLES عن رسالة "لا يمكن تخصيص الذاكرة" أثناء الترقية، فتحقق أولاً مما إذا كانت النواة قد سجلت حدث نفاد الذاكرة، وما إذا كانت ذاكرة الوصول العشوائي (RAM) أو ذاكرة التبديل (swap) قد استُنفدت. أوقف مؤقتًا أي حمل عمل غير أساسي معروف، أو زد الذاكرة المخصصة للجهاز الظاهري فقط بعد التأكد من عدم وجود ضغط، ثم تحقق من أن Zypper وRPM لم يعودا نشطين قبل استئناف إجراء الترقية الأصلي.

مثال افتراضي: تخيل جهازًا افتراضيًا يعمل بنظام SLES 15، حيث يبدأ مسؤول النظام تحديثًا مجدولًا لحزمة برامج أثناء تشغيل مهمة معالجة بيانات ضخمة. يتوقف برنامج Zypper بسبب خطأ في تخصيص الذاكرة. المثال أدناه توضيحي فقط، وليس تقريرًا عن حادثة حقيقية أو اختبارًا؛ استخدم الأوامر لجمع الأدلة على جهازك المضيف قبل اختيار الحل.

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

1. تحقق مما إذا كان الخادم لا يزال قيد التحديث

لا تقم بإعادة تشغيل الجهاز، أو إنهاء عمليات الحزم، أو تشغيل أمر ترقية ثانٍ لمجرد ظهور خطأ في جلسة SSH. أعد الاتصال في جلسة ثانية وتحقق من وجود عمليات Zypper أو RPM نشطة.

pgrep -a 'zypper|rpm'

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

2. تأكيد أو استبعاد ضغط الذاكرة

قم بتجميع لقطة حديثة لذاكرة الوصول العشوائي (RAM) وذاكرة التبديل:

free -h
swapon --show
vmstat 1 5
مثال على طرفية SLES مع إدخال سجل نفاد ذاكرة النواة وسياق فشل تثبيت Zypper
تُعد سجلات نفاد الذاكرة في النواة بالقرب من فشل Zypper دليلاً أقوى من نص الخطأ وحده؛ هذا السجل توضيحي.

في ملف free -h`require`، تحقق من availableالعمود، وليس فقط من القيمة المحددة free؛ إذ يستخدم نظام لينكس ذاكرة الوصول العشوائي (RAM) للتخزين المؤقت. swapon --showيُظهر هذا الملف ما إذا كانت هناك مساحة تبديل (swap) ومقدار المساحة المستخدمة. في ملف `require` ، تشير القيم vmstatغير الصفرية المتكررة في الصفوف الأخيرة إلى وجود تبديل نشط؛ الصف الأول هو متوسط ​​منذ بدء التشغيل، لذا ركز على الصفوف اللاحقة.siso

ثم ابحث عن عملية إنهاء بسبب نفاد الذاكرة (OOM) في النواة حول مكان الفشل واقرأ سجل Zypper:

sudo journalctl -k -b --since "30 minutes ago" | grep -Ei 'oom|out of memory|killed process'
sudo tail -n 80 /var/log/zypper.log

يُعدّ سجلّ إنهاء العملية بسبب نفاد الذاكرة (OOM-kill) الذي يُشير إلى RPM أو Zypper أو أي عملية أخرى دليلاً قاطعاً على وجود ضغط حقيقي على الذاكرة. لا يكفي انخفاض مستوى ذاكرة الوصول العشوائي (RAM) المتاحة وحده لتشخيص المشكلة، إذ يُمكن استعادة الذاكرة المؤقتة، وقد ينتج ظهور الرسالة أيضاً عن حدّ أقصى لذاكرة العملية أو الخدمة. إذا لم يظهر أيّ إدخال لنفاد الذاكرة في النواة، فتحقق من حدود الأمر المُسبّب للمشكلة، ومن أيّ حدّ أقصى لذاكرة systemd أو الحاوية قبل إضافة ذاكرة إلى ذاكرة النظام. لا يُمكن تحديد السبب الدقيق من عبارة "لا يُمكن تخصيص الذاكرة" وحدها.

3. خفف الضغط قبل إعادة المحاولة

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

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

إذا استمر نقص الذاكرة المخصصة للجهاز الضيف أثناء الصيانة الدورية، فقم بزيادة ذاكرة الوصول العشوائي (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
مثال على طرفية SLES لمراجعة تشغيل تجريبي لتصحيح Zypper قبل تحديث الحزمة المخطط له
قم بمراجعة خطة حزمة تجريبية قبل إعادة تشغيل التحديثات الروتينية؛ استخدم الأمر الموثق لترحيل حزمة الخدمة بدلاً من ذلك.

إذا أظهرت التجربة الأولية خطة معقولة وكانت الذاكرة مستقرة، فحدد موعدًا للصيانة ونفذ الأمر المناسب لمهمتك الأصلية. أبقِ جلسة SSH متاحة، وراقب العملية، وتحقق من النتيجة بعد ذلك.

sudo tail -n 80 /var/log/zypper.log
sudo journalctl -k -b --since "30 minutes ago" | grep -Ei 'oom|out of memory|killed process'

تعني عملية الاستعادة الناجحة اكتمال تثبيت الحزم أو عملية الترحيل المقصودة، وخروج Zypper بشكل سليم، وعدم ظهور أي حدث نفاد ذاكرة جديد أثناء التشغيل. إذا كان النظام قابلاً للتشغيل ولكن يجب التراجع عن ترحيل حزمة خدمة SLES نفسها، فإن عملية التراجع الموثقة من SUSE Snapper لا تُطبق إلا عند استيفاء متطلباتها، بما في ذلك وجود جذر Btrfs مدعوم ولقطات مُهيأة. لا تتعامل مع التراجع كاستجابة عامة لفشل تصحيح حزمة.

متى يجب التوقف والتصعيد

إذا تكرر الخطأ بعد تخفيف الضغط على الذاكرة، أو إذا ظلت عمليات الحزمة عالقة، أو إذا أبلغت قاعدة بيانات RPM عن تلف، فتوقف عن إعادة المحاولة. احتفظ بسجل Zypper، وسجل نواة النظام، ومستوى المنتج وحزمة الخدمة، والأمر المستخدم بالتحديد. supportconfigيمكن لأنظمة SUSE جمع بيانات تشخيصية لطلب الدعم. تساعد هذه الخطوات في التمييز بين الضغط على الذاكرة وحالات فشل التخصيص الأخرى؛ ولا يمكنها تحديد عيب خاص بالمنتج دون السجلات الكاملة وتكوين النظام.

للحصول على تفاصيل SLES 15 SP7 الحالية، يُرجى مراجعة أدوات مراقبة النظام من SUSE ، ومرجع ملفات السجل ، وإرشادات إدارة Zypper ، ومتطلبات swap وBtrfs ، وتعليمات الترقية والتراجع عبر الإنترنت . قد تختلف الأوامر ومسارات الاسترداد باختلاف حزمة خدمة SLES، والبنية، ونظام الملفات، وما إذا كانت المهمة عبارة عن ترقيع أو ترحيل إصدار.

اترك تعليقاً

إعادة توجيه سجلات النظام الآمنة في SLES باستخدام rsyslog وبروتوكول TLS المتبادل

إعادة توجيه سجلات النظام الآمنة في SLES باستخدام rsyslog وبروتوكول TLS المتبادل

إرسال سجلات نظام SLES إلى جامع rsyslog عن بعد عبر TLS مصادق عليه، مع عمليات التحقق من الشهادات، وتخزين الانقطاعات مؤقتًا، واختبارات التسليم.

تتبع أخطاء الذاكرة في ترقية نظام SLES قبل إعادة المحاولة

تتبع أخطاء الذاكرة في ترقية نظام SLES قبل إعادة المحاولة

استخدم سجلات ذاكرة الوصول العشوائي (RAM) والمبادلة والنواة وZypper لتحديد ضغط الذاكرة الحقيقي وحماية حالة الحزمة واختيار محاولة إعادة ترقية SLES أكثر أمانًا.

حافظ على تشغيل تحديثات الأمان الخاصة بنظام Debian 12 على خادم بدون واجهة رسومية

حافظ على تشغيل تحديثات الأمان الخاصة بنظام Debian 12 على خادم بدون واجهة رسومية

قم بتمكين تحديثات الأمان التلقائية لنظام Debian عبر SSH، واحتفظ بمصادر الحزم الافتراضية، وتحقق من عمليات التشغيل المجدولة من خلال سجلات systemd و APT.

احصل على تحذيرات قرص أوبونتو الذكية عبر البريد الإلكتروني باستخدام smartd

احصل على تحذيرات قرص أوبونتو الذكية عبر البريد الإلكتروني باستخدام smartd

قارن خيارات تسليم البريد، وقم بتكوين smartd على Ubuntu، وتحقق من وصول تحذيرات حالة القرص إلى صندوق الوارد الخاص بك.

فشل البحث عن نظام أسماء النطاقات (DNS) في دبيان 12: إصلاح systemd-resolved

فشل البحث عن نظام أسماء النطاقات (DNS) في دبيان 12: إصلاح systemd-resolved

استعادة عمليات البحث عن نظام أسماء النطاقات (DNS) على Debian 12 عن طريق التحقق من systemd-resolved، وإصلاح resolv.conf عند الحاجة، والتحقق من نظام أسماء النطاقات (DNS) الخاص بالمصدر وحل التطبيقات.

هل تواجه مشكلة في عرض صوت HDMI في نظام أوبونتو 24.04؟ استعد الإخراج

هل تواجه مشكلة في عرض صوت HDMI في نظام أوبونتو 24.04؟ استعد الإخراج

قم بجعل نظام Ubuntu يتعرف على شاشتك أو تلفزيونك كمخرج صوت، وحدده في إعدادات الصوت، وتحقق من قائمة أجهزة الاتصال أو PipeWire إذا كان HDMI مفقودًا.

إصلاح أخطاء توقيع APT عن طريق إصلاح مفتاح المستودع

إصلاح أخطاء توقيع APT عن طريق إصلاح مفتاح المستودع

قم بحل تحذيرات توقيع Ubuntu APT بأمان عن طريق تحديد المصدر الفاشل، وتحديث مفتاحه الذي تم التحقق منه، والتحقق من النتيجة دون تعطيل الأمان.

كيفية تحويل الجهد والتيار ثلاثي الأطوار، و kW، و kVA، ومعامل القدرة

كيفية تحويل الجهد والتيار ثلاثي الأطوار، و kW، و kVA، ومعامل القدرة

تعلم صيغ التيار ثلاثي الأطوار المتوازنة وقم بتحويل جهد الخط والتيار و kW و kVA ومعامل القدرة خطوة بخطوة، مع مثال عملي وحدود للتحقق منها.

تحديد استخدام وحدة المعالجة المركزية والذاكرة لأمر ما باستخدام مجموعات التحكم (cgroups) في أوبونتو

تحديد استخدام وحدة المعالجة المركزية والذاكرة لأمر ما باستخدام مجموعات التحكم (cgroups) في أوبونتو

قم بتشغيل حمل عمل داخل نطاق systemd مع CPUQuota و MemoryMax، ثم تحقق من الحدود من خلال cgroup v2.

تشفير نظام أسماء النطاقات (DNS) الخاص بـ Pi-hole على خادم Ubuntu 24.04

تشفير نظام أسماء النطاقات (DNS) الخاص بـ Pi-hole على خادم Ubuntu 24.04

قم بإعداد dnscrypt-proxy كجسر DoH محلي لـ Pi-hole على Ubuntu 24.04، مع مستمع محلي فقط، واختيار محلل، وعمليات فحص قبل تبديل DNS.