ตรวจสอบข้อผิดพลาดเกี่ยวกับหน่วยความจำระหว่างการอัปเกรด SLES ก่อนลองใหม่อีกครั้ง

หาก SLES แจ้งว่า “ไม่สามารถจัดสรรหน่วยความจำได้” ระหว่างการอัปเกรด ให้ตรวจสอบก่อนว่าเคอร์เนลบันทึกเหตุการณ์หน่วยความจำไม่เพียงพอหรือไม่ และ RAM หรือ swap หมดลงหรือไม่ หยุดการทำงานที่ไม่จำเป็นชั่วคราว หรือเพิ่มหน่วยความจำที่จัดสรรให้กับ VM หลังจากตรวจสอบแล้วว่าไม่มีปัญหาเกิดขึ้น จากนั้นตรวจสอบว่า Zypper และ RPM ไม่ทำงานอยู่แล้ว ก่อนที่จะดำเนินการอัปเกรดต่อตามขั้นตอนเดิม

ตัวอย่างสมมติ:ลองนึกภาพเครื่องเสมือน SLES 15 ที่ผู้ดูแลระบบเริ่มการอัปเดตแพ็กเกจตามกำหนดเวลาในขณะที่งานแบตช์ขนาดใหญ่กำลังทำงานอยู่ Zypper หยุดทำงานโดยมีข้อผิดพลาดเกี่ยวกับการจัดสรรหน่วยความจำ ตัวอย่างด้านล่างเป็นเพียงตัวอย่างประกอบ ไม่ใช่รายงานเหตุการณ์จริงหรือการทดสอบ โปรดใช้คำสั่งเพื่อรวบรวมหลักฐานบนเครื่องของคุณเองก่อนที่จะเลือกวิธีแก้ไข

1. ตรวจสอบว่าเซิร์ฟเวอร์ยังอยู่ในระหว่างการอัปเกรดหรือไม่

อย่ารีบูตเครื่อง ปิดกระบวนการติดตั้งแพ็กเกจ หรือเรียกใช้คำสั่งอัปเกรดครั้งที่สองเพียงเพราะเซสชัน SSH แสดงข้อผิดพลาด ให้เชื่อมต่อใหม่ในเซสชันที่สองและตรวจสอบกระบวนการ Zypper หรือ RPM ที่ยังทำงานอยู่:

pgrep -a 'zypper|rpm'

หากกระบวนการติดตั้งแพ็กเกจยังคงทำงานอยู่ ให้รอสักครู่แล้วตรวจสอบผลลัพธ์หรือบันทึกการทำงาน อย่าลบไฟล์ล็อกของ Zypper ในขณะที่การดำเนินการติดตั้งแพ็กเกจอาจกำลังทำงานอยู่ หากไม่มีกระบวนการใดทำงานอยู่ ให้เก็บข้อความแสดงข้อผิดพลาดที่แน่นอนและจดบันทึกเวลาที่เกิดขึ้น การประทับเวลาดังกล่าวจะช่วยในการเชื่อมโยงบันทึกของเคอร์เนลและแพ็กเกจ

2. ยืนยันหรือปฏิเสธภาวะกดดันความจำ

รวบรวมสแนปช็อต RAM และ Swap ปัจจุบัน:

free -h
swapon --show
vmstat 1 5

ในfree -hรายงาน ให้ตรวจสอบavailableคอลัมน์ ไม่ใช่แค่จำนวนที่ระบุไว้เท่านั้นfreeเพราะ Linux ใช้ RAM สำหรับแคชด้วย รายงานว่ามีพื้นที่สวอปหรือไม่ และswapon --showใช้ไปเท่าใด ในรายงาน ค่า 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 record" ที่ระบุชื่อ RPM, Zypper หรือกระบวนการอื่น ๆ สนับสนุนการวินิจฉัยปัญหาหน่วยความจำไม่เพียงพออย่างแท้จริง การมี RAM "ว่าง" น้อยอย่างเดียวไม่เพียงพอ เพราะแคชสามารถเรียกคืนได้ และข้อความดังกล่าวอาจเกิดจากข้อจำกัดด้านหน่วยความจำของกระบวนการหรือบริการ หากไม่มีรายการ OOM ในเคอร์เนลปรากฏขึ้น ให้ตรวจสอบข้อจำกัดของคำสั่งที่ล้มเหลวและข้อจำกัดด้านหน่วยความจำของ systemd หรือคอนเทนเนอร์ก่อนที่จะเพิ่มหน่วยความจำของโฮสต์ ไม่สามารถระบุสาเหตุที่แท้จริงได้จากวลี "ไม่สามารถจัดสรรหน่วยความจำได้" เพียงอย่างเดียว

3. ลดแรงดันก่อนลองใหม่อีกครั้ง

กลับไปที่ VM สมมุติ หากงานแบตช์ใช้หน่วยความจำมาก และระบบแสดงกิจกรรมสวอปอย่างต่อเนื่อง หรือเคอร์เนล OOM kill ให้ใช้ขั้นตอนการหยุดชั่วคราวหรือหยุดการทำงานของแอปพลิเคชันนั้น ๆ อย่าปิดฐานข้อมูล เวิร์กโหลด SAP หรือบริการที่มีสถานะอื่น ๆ โดยไม่ได้รับขั้นตอนการปิดระบบจากผู้ดูแลระบบ ตรวจสอบ RAM และสวอปอีกครั้งหลังจากหยุดเวิร์กโหลดชั่วคราวแล้ว

หากระบบปฏิบัติการของเครื่องเสมือนยังคงมีหน่วยความจำไม่เพียงพอในระหว่างการบำรุงรักษาตามปกติ ให้เพิ่ม RAM ที่จัดสรรให้ผ่านทางไฮเปอร์ไวเซอร์หรือระบบควบคุมคลาวด์ที่รองรับ จากนั้นตรวจสอบให้แน่ใจว่าระบบปฏิบัติการมองเห็นปริมาณหน่วยความจำใหม่แล้ว การเพิ่มพื้นที่สวอปอาจช่วยเพิ่มพื้นที่ว่างชั่วคราวได้ แต่จะช้ากว่าการเพิ่ม RAM และไม่สามารถแก้ไขปัญหาความต้องการหน่วยความจำอย่างต่อเนื่องได้ โครงสร้างการจัดเก็บข้อมูลของ SLES มีความสำคัญ ตัวอย่างเช่น เอกสารของ SUSE ระบุข้อจำกัดเฉพาะสำหรับไฟล์สวอปบน Btrfs หลีกเลี่ยงการสร้างหรือปรับขนาดไฟล์สวอปในระหว่างการอัปเกรด เว้นแต่คุณได้ตรวจสอบข้อกำหนดของระบบไฟล์ สแนปช็อต และแพลตฟอร์มแล้ว

หากไม่มีบันทึก OOM ให้ตรวจสอบขีดจำกัดที่ใช้กับกระบวนการที่ล้มเหลวแทน ใน SLES 15 ให้ตรวจสอบขีดจำกัดหน่วยความจำที่กำหนดค่าไว้ของเวิร์กโหลดที่จัดการโดย systemd โดยแทนที่ชื่อหน่วยตัวอย่างด้วยชื่อบริการที่ได้รับผลกระทบ:

sudo systemctl show example-batch.service -p MemoryMax

เปรียบเทียบค่าดังกล่าวกับหน่วยความจำที่มีอยู่ การเพิ่ม RAM ของ VM จะไม่ช่วยแก้ไขข้อจำกัดของ cgroup เว้นแต่จะมีการเพิ่มขีดจำกัดนั้นให้เหมาะสมด้วย สำหรับ Service Pack รุ่นเก่า ให้ตรวจสอบชื่อคุณสมบัติกับเอกสาร systemd ของเวอร์ชันนั้นๆ

4. ดำเนินการอัปเกรดต่อตามขั้นตอนที่รองรับ และตรวจสอบความถูกต้อง

เมื่อกระบวนการติดตั้งแพ็กเกจเสร็จสิ้นแล้ว ให้ตรวจสอบ/var/log/zypper.logการดำเนินการที่เสร็จสมบูรณ์ครั้งล่าสุดและแพ็กเกจที่ล้มเหลว หาก RPM หรือ Zypper รายงานว่าธุรกรรมไม่สมบูรณ์ ให้ปฏิบัติตามคำแนะนำในการกู้คืนของ SUSE สำหรับข้อผิดพลาดนั้นโดยเฉพาะก่อนที่จะลองใหม่อีกครั้ง ห้ามลบไฟล์ฐานข้อมูลแพ็กเกจหรือล็อกด้วยตนเอง

ใช้เส้นทางการอัปเกรดเดียวกับที่คุณเริ่มต้นไว้แต่แรก การบำรุงรักษาแพ็กเกจตามปกติและการย้ายเซอร์วิสแพ็คเป็นขั้นตอนที่แตกต่างกัน: เอกสารของ SUSE zypper patchเกี่ยวกับวิธีการติดตั้งแพตช์ที่เผยแพร่แล้วที่เกี่ยวข้อง ในขณะที่การอัปเกรดเซอร์วิสแพ็คและเวอร์ชันหลักมีเส้นทางและการเตรียมการที่ได้รับการสนับสนุนของตนเอง อย่าเปลี่ยนไปใช้zypper dupเพียงเพื่อแก้ปัญหาเฉพาะหน้า สำหรับการเรียกใช้แพตช์ตามปกติ โปรดตรวจสอบธุรกรรมก่อน:

sudo zypper patch --dry-run

หากการทดสอบแบบจำลองแสดงให้เห็นว่าแผนมีความเหมาะสมและหน่วยความจำมีความเสถียร ให้กำหนดช่วงเวลาสำหรับการบำรุงรักษาและเรียกใช้คำสั่งที่เหมาะสมสำหรับงานเดิมของคุณ รักษาการเชื่อมต่อ 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 ปิดตัวลงอย่างราบรื่น และไม่มีเหตุการณ์ OOM ใหม่เกิดขึ้นระหว่างการทำงาน หากระบบสามารถบูตได้ แต่ต้องย้อนกลับการย้ายข้อมูลเซอร์วิสแพ็ค SLES เอง การย้อนกลับ Snapper ที่ระบุไว้ในเอกสารของ SUSE จะใช้ได้เฉพาะเมื่อตรงตามข้อกำหนด รวมถึงรูท Btrfs ที่รองรับและสแนปช็อตที่กำหนดค่าไว้ อย่าถือว่าการย้อนกลับเป็นการตอบสนองทั่วไปต่อแพตช์แพ็กเกจที่ล้มเหลว

เมื่อใดควรหยุดและเมื่อใดควรยกระดับการดำเนินการ

หากข้อผิดพลาดเกิดขึ้นซ้ำหลังจากแก้ไขปัญหาแรงดันหน่วยความจำแล้ว กระบวนการติดตั้งแพ็กเกจยังคงค้างอยู่ หรือฐานข้อมูล RPM รายงานว่าเกิดความเสียหาย ให้หยุดการลองใหม่ บันทึกข้อมูล Zypper log, kernel journal, ระดับผลิตภัณฑ์และ service-pack รวมถึงคำสั่งที่ใช้ทั้งหมด SUSE supportconfigสามารถรวบรวมข้อมูลการวินิจฉัยเพื่อใช้ในกรณีการสนับสนุนได้ ขั้นตอนเหล่านี้ช่วยแยกแยะปัญหาแรงดันหน่วยความจำออกจากความล้มเหลวในการจัดสรรอื่นๆ แต่ไม่สามารถระบุข้อบกพร่องเฉพาะของผลิตภัณฑ์ได้หากไม่มีบันทึกและข้อมูลการกำหนดค่าระบบทั้งหมด

สำหรับรายละเอียด SLES 15 SP7 ปัจจุบัน โปรดดูที่ยูทิลิตี้การตรวจสอบระบบ ของ SUSE , ข้อมูลอ้างอิงไฟล์บันทึก , คำแนะนำการดูแลระบบ Zypper , ข้อกำหนด swap และ Btrfsและคำแนะนำการอัปเกรดและการย้อนกลับออนไลน์คำสั่งและเส้นทางการกู้คืนอาจแตกต่างกันไปตาม Service Pack ของ SLES, สถาปัตยกรรม, ระบบไฟล์ และไม่ว่างานนั้นจะเป็นการแพตช์หรือการย้ายรุ่น