Computer >> บทช่วยสอนคอมพิวเตอร์ >  >> ซอฟต์แวร์ >> เครื่องเสมือน

การตรวจจับ Memory Overcommitment ใน Guest OS

เมื่อบริหารจัดการ VMs ที่รันบนโฮสต์เสมือนจริง (VMWare ESXi หรือ Hyper-V) และวิเคราะห์ปัญหาประสิทธิภาพ จะพบบ่อยครั้งที่ขนาดหน่วยความจำที่มีอยู่ใน Guest OS น้อยมากกว่าที่ระบบปฏิบัติการเห็น (หรือที่จัดสรรให้) เช่น จัดสรรหน่วยความจำ 8 GB ให้ VM แต Task Manager แสดงว่าว่าง 1 GB แม้กระบวนการที่รันอยู่ใช้เพียง 3 GB เหลือ 4 GB ไปไหน?

โดยปกติ พฤติกรรมนี้เกิดจากการใช้ฟีเจอร์ Memory Overcommit ในไฮเปอร์ไวเซอร์

Memory overcommit คือฟีเจอร์ของไฮเปอร์ไวเซอร์ที่อนุญาตให้จัดสรรหน่วยความจำให้ VMs มากกว่าที่มีอยู่บนโฮสต์ทางกายภาพ แต่ไม่รับประกันว่าหน่วยความจำที่ขอทั้งหมดจะจัดสรรได้ในเวลานั้น ทำให้สามารถจัดสรร VMs ได้หนาแน่นขึ้น ด้วยการกระจายหน่วยความจำแบบไดนามิกระหว่าง VMs ขึ้นกับโหลดโฮสต์ปัจจุบัน (ทรัพยากรของ VMs ที่ว่างอาจถูกกระจายไปให้ VMs ที่มีโหลดมากกว่า)

หนึ่งในกลไกการใช้ Memory Overcommit ใน VMWare คือ Memory Ballooning ใน Hyper-V ฟีเจอร์เดียวกันถูกนำไปใช้โดย Dynamic Memory

หมายเหตุ: VMWare และ Microsoft ใช้การบีบอัดหน่วยความจำ (Memory Compression) อย่างกว้างขวางและมีประสิทธิภาพเพื่อประหยัดทรัพยากรหน่วยความจำ (นี่ก็เป็นการนำ Memory Overcommit technology ไปใช้อีกอย่างหนึ่ง)

ใน VMWare ESXi Memory Overcommitment (Virtual Memory Ballooning) ถูกนำไปใช้โดยไดรเวอร์ vmmemctl.sys (รวมอยู่ใน VMware Tools) ซึ่งสามารถครอบครองหน่วยความจำทางกายภาพโดยสร้างกระบวนการปลอม (เหมือนเป่าลูกโป่ง) ภายในหากจำเป็น ดังนั้น ปริมาณหน่วยความจำที่ถูกครอบครองจะไม่พร้อมใช้งานสำหรับแอปพลิเคชันอื่นใน Guest OS และไฮเปอร์ไวเซอร์สามารถกระจายหน่วยความจำที่ว่างไปให้ VMs อื่น ใน Hyper-V Dynamic Memory ใช้ไดรเวอร์ dmvsc.sys จาก Integration Services (Dynamic Memory VSC component) การตั้งค่า Memory Overcommitment จัดการโดยผู้ดูแลไฮเปอร์ไวเซอร์

จะตรวจจับจากภายใน Guest VM ได้อย่างไร ว่ามีหน่วยความจำทางกายภาพที่ใช้งานได้จริง น้อยกว่าที่ Guest OS เห็น?

มาพิจารณาวิธีตรวจจับว่ามี Balloon Driver ใน Guest Windows OS หรือไม่ และขนาดของมันคือเท่าไหร่ วิเคราะห์ตัวอย่างนี้

จัดสรรหน่วยความจำ 8 GB ให้ VM รัน Guest Windows Server 2012 R2 Task Manager แสดงว่าใช้หน่วยความจำ 93% (7.4 GB ถูกครอบครอง) แต่หากรวมปริมาณหน่วยความจำที่ใช้โดยกระบวนการที่รันอยู่ทั้งหมด จะสรุปได้อย่างไม่คาดคิดว่าใช้จริงเพียง 2.5 GB เหลือ 5 GB ไปไหน? ไม่ใช่ Task Manager และไม่ใช่ Resource Monitor ที่ตอบคำถามนี้ได้

การตรวจจับ Memory Overcommitment ใน Guest OS

เพื่อเข้าใจว่ากำลังเกิดอะไรกับหน่วยความจำ ต้องใช้เครื่องมือ RamMap ของ Mark Russinovich (ในกรณีก่อนหน้า ผมเคยแสดงวิธีใช้เครื่องมือนี้診斷ปัญหาการใช้หน่วยความจำสูงโดย metafile บน Windows Server) ดาวน์โหลดจากเว็บไซต์ Microsoft (https://technet.microsoft.com/en-us/library/ff700229.aspx) และรันด้วยสิทธิ์ Administrator หลังจากนั้นที่แท็บ Use Counts จะเห็นว่าส่วนใหญ่ของหน่วยความจำ (5.4 GB) ถูกใช้โดยออบเจ็กต์ Driver Locked

การตรวจจับ Memory Overcommitment ใน Guest OS

นี่คือหน่วยความจำที่ไฮเปอร์ไวเซอร์ครอบครองและกระจายไปให้ VMs อื่นผ่าน Balloon Driver ใน Guest OS หมายความว่าโฮสต์ไฮเปอร์ไวเซอร์ไม่มีหน่วยความจำเพียงพอ หรือผู้ดูแลไฮเปอร์ไวเซอร์ใช้นโยบายจำกัดหน่วยความจำสำหรับ VM นี้

สถิติหน่วยความจำ VM ปัจจุบันใน Hyper-V อาจแสดงโดย Performance Counters แยกต่างหากใน Performance Monitor:

  • Hyper-V Dynamic Memory → Guest Visible Memory
  • Hyper-V Dynamic Memory → Physical Memory

เพื่อปิดใช้งานพฤติกรรมนี้ ผู้ดูแลไฮเปอร์ไวเซอร์ต้องปิดตัวเลือก Enable Dynamic Memory ในการตั้งค่า Hyper-V ของ VM (หรือเพิ่มค่าการจองขั้นต่ำ)

การตรวจจับ Memory Overcommitment ใน Guest OS

หากใช้ VMWare ESXi Host สามารถจองหน่วยความจำเพิ่มเติมสำหรับ VM นี้ใน Resource Settings หรือจองหน่วยความจำทั้งหมด – Reserve all guest memory (All locked)

การตรวจจับ Memory Overcommitment ใน Guest OS


No