5 สิ่งที่ต้องเช็กทันทีเมื่อ Linux Server ล่มหรือหยุดตอบสนอง
เรียนรู้วิธีการแก้ปัญหา Linux Server ล่มอย่างเป็นระบบตั้งแต่การเช็กเครือข่าย ทรัพยากรหมด และการหลีกเลี่ยงการรีบูตเครื่องแบบสุ่มสี่สุ่มห้า
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ห้ามรีบูตเซิร์ฟเวอร์ทันทีเพื่อป้องกันการทำลายหลักฐานการดีบักสำคัญ
- ตรวจสอบการเชื่อมต่อเครือข่ายและสแต็ก IP ก่อนดำเนินการส่วนอื่น
- วิเคราะห์โหลดของระบบเปรียบเทียบกับจำนวนคอร์ซีพียูทั้งหมด
- ใช้คำสั่งตรวจสอบหน่วยความจำและพื้นที่สวอปเพื่อดูอาการขัดข้อง
เมื่อเครื่องโปรดักชันออฟไลน์หรือหยุดตอบสนอง การเดาสุ่มจะทำให้เสียเวลาอันมีค่า นี่คือลำดับขั้นตอนการตรวจสอบ 5 ขั้นตอนที่ผู้ดูแลระบบใช้เพื่อค้นหาต้นตอและกู้คืนระบบ
เหตุการณ์เกิดขึ้นตอนตี 3:15 น. ของวันเสาร์ เมื่อโทรศัพท์สั่นเตือนจาก Prometheus แอปพลิเคชันเซิร์ฟเวอร์หลักหยุดตอบสนองต่อการตรวจสุขภาพ คำขอ HTTP หมดเวลา และไคลเอนต์ API หลุดการเชื่อมต่อ
ความรู้สึกแรกคือความตื่นตระหนกและอยากกดปุ่มรีบูตหรือรีสตาร์ททุกบริการที่เห็น แต่นั่นคือข้อผิดพลาดที่ใหญ่ที่สุด
"Rebooting an unresponsive server without looking at its state destroys vital debugging evidence."System Administrator
การรีบูตโดยไม่ดูสถานะจะทำลายหลักฐานสำคัญ ทั้งบัฟเฟอร์เคอร์เนล คอร์ดัมพ์ของกระบวนการ และหน่วยความจำระเหย การแก้ปัญหาชั่วคราวดังกล่าวอาจทำให้ระบบกลับมาทำงาน 10 นาที แต่จะเกิดปัญหาซ้ำในช่วงเวลาเร่งด่วน
จากการดูแลระบบ Linux มาหลายปี ผู้เขียนได้พัฒนาขั้นตอนการตรวจสอบที่ใช้เวลาไม่ถึง 5 นาที ทำงานได้บนลินุกซ์เกือบทุกรุ่น และชี้เป้าปัญหาได้อย่างแม่นยำ
นี่คือ 5 สิ่งแรกที่ต้องตรวจสอบเมื่อเซิร์ฟเวอร์ Linux ล่มหรือหยุดตอบสนอง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ก่อนทำสิ่งอื่นต้องตรวจสอบว่าระบบปฏิบัติการล่มจริงหรือไม่ หรือเครื่องแค่ขาดการเชื่อมต่อเครือข่าย เกตเวย์อาจจะหลุด กฎไฟร์วอลล์บล็อกทราฟฟิก หรืออินเทอร์เฟซสูญเสียไอพี
เริ่มต้นจากเวิร์กสเตชันด้วยการส่งแพ็กเก็ต ICMP ไปยังเซิร์ฟเวอร์:
- ใช้คำสั่ง ping เพื่อทดสอบการตอบสนองของเครือข่าย
- ตรวจสอบการเชื่อมต่อ SSH แบบละเอียดเพื่อดูว่าพอร์ตเปิดหรือปิด
- เปิดคอนโซลเว็บของคลาวด์เพื่อเข้าสู่ระบบผ่านเทอร์มินัลเสมือน
ขั้นต่อไปคือการตรวจสอบความอดอยากของทรัพยากร โหลดของระบบ และ OOM Killer เมื่อซีพียู หน่วยความจำ หรือตารางกระบวนการเต็ม 100% ระบบจะทำงานช้าลงอย่างมาก
การวิเคราะห์เพิ่มเติม: ค่า Load Average บน Linux ไม่ได้นับเฉพาะกระบวนการที่ใช้ซีพียูเท่านั้น แต่รวมถึงกระบวนการที่รอคิวซีพียูและถูกบล็อกรอ Disk I/O ด้วย ดังนั้นค่าที่สูงกว่าจำนวนคอร์จึงบ่งบอกถึงปัญหาคอขวดที่ชัดเจน
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น