คู่มือเกมแลค › L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
OOM killer Out-of-memory killer
ID สาเหตุ so-oom · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
เมื่อหน่วยความจำหมด Linux จะเลือกโปรเซสที่ใช้หน่วยความจำมากที่สุดแล้วบังคับปิด ซึ่งส่วนใหญ่คือเซิร์ฟเวอร์เกม
ทำไม หน่วยความจำหมดเพราะรั่วหรือใช้พุ่ง หรือคอนเทนเนอร์แตะขีดจำกัดหน่วยความจำ → ผลคือ เคอร์เนลบังคับปิดโปรเซสเซิร์ฟเวอร์เกม → บนหน้าจอ ทุกคนในเซิร์ฟเวอร์นั้นหลุดพร้อมกัน ความคืบหน้าล่าสุดอาจโดนโรลแบ็ค
- อาการ
- หลุด, กดไม่ติด/โรลแบ็ค
- ปัจจัย
- การหยุดชะงัก
- ใครเจอ
- ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- ยิ่งเปิดไว้นานยิ่งเป็น, ตอนคนแห่มารวมกัน
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
- งานฝั่งทีมพัฒนาเกม
- แก้หน่วยความจำรั่ว, กำหนดเพดานการใช้หน่วยความจำและมีขั้นตอนบันทึกข้อมูลแล้วปิดอย่างปกติเมื่อใกล้เพดาน
- งานฝั่งทีมอินฟรา
- ตั้ง alert หน่วยความจำ, ตั้งขีดจำกัดหน่วยความจำของคอนเทนเนอร์ให้เหมาะกับการใช้งานจริง, ปรับลำดับโปรเซสที่จะถูกปิดก่อน (oom_score_adj)
- ตัวเลขที่ควรรู้
- log ของเคอร์เนล (dmesg) จะมี “Out of memory: Killed process” และใน Kubernetes จะเห็นเป็น OOMKilled ส่วน Windows ไม่มี OOM killer และเซิร์ฟเวอร์มักล่มด้วยข้อผิดพลาดเมื่อจัดสรรหน่วยความจำไม่สำเร็จ
- บนกราฟ
- การเชื่อมต่อหลุดพร้อมกัน · จำนวนการเชื่อมต่อ, ปริมาณการใช้หน่วยความจำ
- จุดที่ต้องดู
- บันทึก “Out of memory: Killed process” ใน dmesg, OOMKilled ในสถานะพ็อด (Kubernetes) หรือ oom_kill ใน memory.events ที่เพิ่มขึ้น (cgroup v2) เทียบกับเวลาที่ผู้เล่นหลุด
- สัญญาณว่าใช่
- ตอนที่การเชื่อมต่อหลุดพร้อมกัน มีบันทึกว่าโปรเซสเซิร์ฟเวอร์เกมถูกปิด และก่อนหน้านั้นการใช้หน่วยความจำไต่ขึ้นไปถึงขีดจำกัด
- สัญญาณว่าไม่ใช่
- ไม่มีบันทึก OOM แต่โปรเซสตาย: ให้ดู crash log และ core dump ตาม “เซิร์ฟเวอร์แครช”
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง
- mm/oom_kill.c (Linux v6.12) Linux kernel
คำนวณให้โปรเซสที่ใช้หน่วยความจำมากที่สุดได้คะแนนสูงสุด (รวม oom_score_adj), เมื่อปิดจะบันทึก “Out of memory: Killed process …” - Assign Memory Resources to Containers and Pods Kubernetes
ถ้าคอนเทนเนอร์ยังใช้หน่วยความจำเกิน limit ต่อไป จะถูกปิดและสถานะแสดงเป็น OOMKilled - Pushing the Limits of Windows: Virtual Memory Microsoft
บน Windows เมื่อถึง commit limit การจัดสรรที่ต้อง commit หน่วยความจำจะล้มเหลว และอาจนำไปสู่ข้อผิดพลาดของแอปหรือระบบขัดข้อง - Control Group v2 Linux kernel
oom_kill ของ memory.events: จำนวนโปรเซสใน cgroup นี้ที่ถูก OOM killer ปิด
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (หลุด)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง