ในบทความนี้ เราจะพูดถึงตัวนับประสิทธิภาพของหน่วยความจำเข้าถึงโดยสุ่ม (RAM) ใน vSphere
ดูเหมือนว่าด้วยหน่วยความจำ ทุกอย่างจะชัดเจนกว่าโปรเซสเซอร์: หาก VM มีปัญหาด้านประสิทธิภาพ ก็ยากที่จะไม่สังเกตเห็น แต่ถ้าปรากฏขึ้นก็จะยากกว่ามากในการจัดการกับพวกมัน แต่สิ่งแรกก่อน
ทฤษฎีเล็กน้อย
RAM ของเครื่องเสมือนถูกนำมาจากหน่วยความจำของเซิร์ฟเวอร์ที่ VM กำลังทำงานอยู่ มันค่อนข้างชัดเจน :). หาก RAM ของเซิร์ฟเวอร์ไม่เพียงพอสำหรับทุกคน ESXi จะเริ่มใช้เทคนิคการเรียกคืนหน่วยความจำเพื่อเพิ่มประสิทธิภาพการใช้ RAM มิฉะนั้นระบบปฏิบัติการ VM อาจขัดข้องด้วยข้อผิดพลาดในการเข้าถึง RAM
เทคนิคใดที่จะใช้ ESXi ตัดสินใจขึ้นอยู่กับโหลดของ RAM:
สถานะหน่วยความจำ
เส้นขอบ
กิจกรรม
จุดสูง
400% ของนาทีฟรี
หลังจากถึงขีดจำกัดบนแล้ว หน้าหน่วยความจำขนาดใหญ่จะถูกแบ่งออกเป็นหน้าเล็กๆ (TPS ทำงานในโหมดมาตรฐาน)
ทูโทนช็อคชิพ
100% ของนาทีฟรี
หน้าหน่วยความจำขนาดใหญ่แบ่งออกเป็นหน้าเล็ก TPS ถูกบังคับให้ทำงาน
อ่อน
64% ของนาทีฟรี
ทีพีเอส + บอลลูน
ยาก
32% ของนาทีฟรี
TPS + บีบอัด + สลับ
ต่ำ
16% ของนาทีฟรี
บีบอัด + สลับ + บล็อก
minFree คือ RAM ที่จำเป็นสำหรับไฮเปอร์ไวเซอร์ในการทำงาน
ก่อนที่จะรวม ESXi 4.1 นั้น minFree ได้รับการแก้ไขตามค่าเริ่มต้น - 6% ของ RAM ของเซิร์ฟเวอร์ (เปอร์เซ็นต์สามารถเปลี่ยนแปลงได้ผ่านตัวเลือก Mem.MinFreePct บน ESXi) ในเวอร์ชันใหม่กว่า เนื่องจากขนาดหน่วยความจำเพิ่มขึ้นบนเซิร์ฟเวอร์ minFree จึงเริ่มคำนวณตามจำนวนหน่วยความจำโฮสต์ ไม่ใช่เปอร์เซ็นต์คงที่
ค่า minFree (ค่าเริ่มต้น) มีการคำนวณดังนี้:
เปอร์เซ็นต์ของหน่วยความจำที่สงวนไว้สำหรับ minFree
ช่วงหน่วยความจำ
6%
0-4 กิกะไบต์
4%
4-12 กิกะไบต์
2%
12-28 กิกะไบต์
1%
ความทรงจำที่เหลืออยู่
ตัวอย่างเช่น สำหรับเซิร์ฟเวอร์ที่มี RAM 128 GB ค่า MinFree จะเป็น:
ขั้นต่ำฟรี = 245,76 + 327,68 + 327,68 + 1024 = 1925,12MB = 1,88GB
ค่าจริงอาจแตกต่างกันสองสามร้อย MB ขึ้นอยู่กับเซิร์ฟเวอร์และ RAM
เปอร์เซ็นต์ของหน่วยความจำที่สงวนไว้สำหรับ minFree
ช่วงหน่วยความจำ
มูลค่า 128 GB
6%
0-4 กิกะไบต์
245,76 MB
4%
4-12 กิกะไบต์
327,68 MB
2%
12-28 กิกะไบต์
327,68 MB
1%
หน่วยความจำที่เหลืออยู่ (100 GB)
1024 MB
โดยปกติแล้วสำหรับจุดยืนที่มีประสิทธิผลเฉพาะสถานะระดับสูงเท่านั้นที่ถือว่าเป็นเรื่องปกติ สำหรับม้านั่งทดสอบและการพัฒนา สถานะ Clear/Soft อาจยอมรับได้ หาก RAM บนโฮสต์น้อยกว่า 64% MinFree แสดงว่า VM ที่ทำงานบนโฮสต์นั้นมีปัญหาด้านประสิทธิภาพอย่างแน่นอน
ในแต่ละสถานะ จะมีการใช้เทคนิคการเรียกคืนหน่วยความจำบางอย่าง โดยเริ่มจาก TPS ซึ่งในทางปฏิบัติแล้วจะไม่ส่งผลกระทบต่อประสิทธิภาพของ VM และลงท้ายด้วยการสลับ ฉันจะบอกคุณเพิ่มเติมเกี่ยวกับพวกเขา
การแชร์เพจแบบโปร่งใส (TPS) พูดคร่าวๆ แล้ว TPS คือการลดความซ้ำซ้อนของเพจหน่วยความจำเครื่องเสมือนบนเซิร์ฟเวอร์
ESXi ค้นหาหน้าที่เหมือนกันของ RAM เครื่องเสมือนโดยการนับและเปรียบเทียบผลรวมแฮชของหน้า และลบหน้าที่ซ้ำกันออก โดยแทนที่ด้วยลิงก์ไปยังหน้าเดียวกันในหน่วยความจำกายภาพของเซิร์ฟเวอร์ ผลที่ได้คือ การใช้หน่วยความจำกายภาพลดลง และการสมัครสมาชิกหน่วยความจำมากเกินไปสามารถทำได้โดยประสิทธิภาพลดลงเพียงเล็กน้อยหรือไม่มีเลย
กลไกนี้ใช้ได้กับเพจหน่วยความจำ 4 KB เท่านั้น (เพจเล็ก) ไฮเปอร์ไวเซอร์ไม่ได้พยายามลบหน้าที่มีขนาด 2 MB (หน้าใหญ่) ด้วยซ้ำ: โอกาสที่จะค้นหาหน้าที่เหมือนกันขนาดนี้มีไม่มากนัก
ตามค่าเริ่มต้น ESXi จะจัดสรรหน่วยความจำให้กับเพจขนาดใหญ่ การแบ่งหน้าใหญ่เป็นหน้าเล็กจะเริ่มต้นเมื่อถึงเกณฑ์สถานะระดับสูง และถูกบังคับเมื่อถึงสถานะล้าง (ดูตารางสถานะไฮเปอร์ไวเซอร์)
หากคุณต้องการให้ TPS เริ่มทำงานโดยไม่ต้องรอให้ RAM โฮสต์เต็ม ใน Advanced Options ESXi คุณต้องตั้งค่า “Mem.AllocGuestLargePage” เป็น 0 (ค่าเริ่มต้น 1) จากนั้นการจัดสรรเพจหน่วยความจำขนาดใหญ่สำหรับเครื่องเสมือนจะถูกปิดใช้งาน
ตั้งแต่เดือนธันวาคม 2014 ใน ESXi ทุกรุ่น TPS ระหว่าง VM จะถูกปิดใช้งานโดยค่าเริ่มต้น เนื่องจากพบช่องโหว่ที่ในทางทฤษฎีอนุญาตให้เข้าถึงจาก VM หนึ่งไปยัง RAM ของ VM อื่นได้ รายละเอียดที่นี่ ฉันไม่พบข้อมูลเกี่ยวกับการใช้งานจริงของการใช้ประโยชน์จากช่องโหว่ TPS
นโยบาย TPS ควบคุมผ่านตัวเลือกขั้นสูง “Mem.ShareForceSalting” บน ESXi:
0 - TPS ระหว่าง VM TPS ใช้งานได้กับเพจของ VM ที่แตกต่างกัน
1 – TPS สำหรับ VM ที่มีค่า “sched.mem.pshare.salt” เหมือนกันใน VMX
2 (ค่าเริ่มต้น) - TPS ภายใน VM TPS ใช้งานได้กับเพจภายใน VM
การปิดเพจขนาดใหญ่และเปิด Inter-VM TPS บนม้านั่งทดสอบเป็นเรื่องสมเหตุสมผลอย่างแน่นอน นอกจากนี้ยังใช้สำหรับสแตนด์ที่มี VM ประเภทเดียวกันจำนวนมาก ตัวอย่างเช่น บนขาตั้งที่มี VDI การประหยัดหน่วยความจำกายภาพสามารถทำได้ถึงสิบเปอร์เซ็นต์
บอลลูนหน่วยความจำ การบอลลูนไม่ใช่เทคนิคที่ไม่เป็นอันตรายและโปร่งใสอีกต่อไปสำหรับระบบปฏิบัติการ VM เช่น TPS แต่ด้วยการใช้งานที่เหมาะสม คุณสามารถใช้ชีวิตและทำงานกับ Ballooning ได้
เมื่อใช้ร่วมกับ Vmware Tools จะมีการติดตั้งไดรเวอร์พิเศษที่เรียกว่า Balloon Driver (aka vmmemctl) บน VM เมื่อไฮเปอร์ไวเซอร์เริ่มหน่วยความจำกายภาพหมดและเข้าสู่สถานะ Soft ESXi จะขอให้ VM เรียกคืน RAM ที่ไม่ได้ใช้ผ่าน Balloon Driver นี้ ในทางกลับกันไดรเวอร์จะทำงานในระดับระบบปฏิบัติการและขอหน่วยความจำว่างจากนั้น ไฮเปอร์ไวเซอร์จะดูว่าหน้าใดของหน่วยความจำฟิสิคัลที่ Balloon Driver ครอบครองอยู่ จากนั้นนำหน่วยความจำจากเครื่องเสมือนและส่งกลับไปยังโฮสต์ การทำงานของ OS ไม่มีปัญหาเนื่องจากที่ระดับ OS หน่วยความจำจะถูกครอบครองโดย Balloon Driver ตามค่าเริ่มต้น Balloon Driver สามารถใช้หน่วยความจำ VM ได้สูงสุด 65%
หากไม่ได้ติดตั้ง VMware Tools บน VM หรือ Ballooning ถูกปิดใช้งาน (ฉันไม่แนะนำ แต่มี :) ไฮเปอร์ไวเซอร์จะสลับไปใช้เทคนิคการลบหน่วยความจำที่เข้มงวดมากขึ้นทันที สรุป: ตรวจสอบให้แน่ใจว่า VMware Tools อยู่บน VM
สามารถตรวจสอบการทำงานของ Balloon Driver ได้จากระบบปฏิบัติการผ่าน VMware Tools.
การบีบอัดหน่วยความจำ เทคนิคนี้ใช้เมื่อ ESXi เข้าสู่สถานะ Hard ตามชื่อที่สื่อถึง ESXi พยายามที่จะย่อขนาดหน้า 4KB ของ RAM ให้เป็น 2KB และเพิ่มพื้นที่ว่างบนหน่วยความจำกายภาพของเซิร์ฟเวอร์ เทคนิคนี้จะเพิ่มเวลาในการเข้าถึงเนื้อหาของเพจ VM RAM ได้อย่างมาก เนื่องจากเพจจะต้องไม่มีการบีบอัดก่อน บางครั้งไม่สามารถบีบอัดทุกหน้าได้ และกระบวนการเองก็ใช้เวลาพอสมควร ดังนั้นเทคนิคนี้จึงไม่ค่อยมีประสิทธิภาพในทางปฏิบัติ
การสลับหน่วยความจำ หลังจากช่วงการบีบอัดหน่วยความจำสั้นๆ ESXi แทบจะหลีกเลี่ยงไม่ได้ (หาก VM ไม่ได้ออกจากโฮสต์อื่นหรือปิดอยู่) จะเปลี่ยนไปใช้การสลับ และหากมีหน่วยความจำเหลือน้อยมาก (สถานะต่ำ) ไฮเปอร์ไวเซอร์จะหยุดจัดสรรเพจหน่วยความจำให้กับ VM ซึ่งอาจทำให้เกิดปัญหาใน guest OS ของ VM
นี่คือวิธีการทำงานของการสลับ เมื่อคุณเปิดเครื่องเสมือน ไฟล์ที่มีนามสกุล .vswp จะถูกสร้างขึ้น มีขนาดเท่ากันกับ RAM ที่ไม่ได้จองของ VM: มันเป็นความแตกต่างระหว่างหน่วยความจำที่กำหนดค่าและที่สงวนไว้ เมื่อการสลับทำงาน ESXi จะยกเลิกการโหลดหน้าหน่วยความจำเครื่องเสมือนลงในไฟล์นี้ และเริ่มทำงานกับหน้านั้นแทนหน่วยความจำกายภาพของเซิร์ฟเวอร์ แน่นอนว่า หน่วยความจำแบบ "ปฏิบัติการ" ดังกล่าวนั้นช้ากว่าหน่วยความจำจริงหลายเท่า แม้ว่า .vswp จะอยู่บนพื้นที่จัดเก็บข้อมูลที่รวดเร็วก็ตาม
ต่างจาก Ballooning เมื่อเพจที่ไม่ได้ใช้ถูกนำมาจาก VM ด้วยการสลับ เพจที่ระบบปฏิบัติการหรือแอปพลิเคชันภายใน VM ใช้งานอยู่สามารถย้ายไปยังดิสก์ได้ เป็นผลให้ประสิทธิภาพของ VM ลดลงจนถึงจุดค้าง VM ทำงานอย่างเป็นทางการและอย่างน้อยก็สามารถปิดการใช้งานได้อย่างถูกต้องจากระบบปฏิบัติการ ถ้าอดทน😉
หาก VM ไปที่ Swap นี่เป็นสถานการณ์ที่ผิดปกติ ซึ่งควรหลีกเลี่ยงให้ดีที่สุดหากเป็นไปได้
ตัวนับประสิทธิภาพหน่วยความจำ VM หลัก
เราจึงมาถึงประเด็นหลัก ในการตรวจสอบสถานะของหน่วยความจำใน VM มีตัวนับต่อไปนี้:
ใช้งาน — แสดงจำนวน RAM (KB) ที่ VM เข้าถึงได้ในช่วงเวลาการวัดก่อนหน้า
การใช้ - เช่นเดียวกับ Active แต่เป็นเปอร์เซ็นต์ของ RAM ที่กำหนดค่าของ VM คำนวณโดยใช้สูตรต่อไปนี้: ใช้งาน ÷ ขนาดหน่วยความจำที่กำหนดค่าของเครื่องเสมือน
การใช้งานสูงและใช้งานอยู่ตามลำดับไม่ใช่ตัวบ่งชี้ปัญหาประสิทธิภาพของ VM เสมอไป หาก VM ใช้หน่วยความจำอย่างจริงจัง (อย่างน้อยก็เข้าถึงได้) นี่ไม่ได้หมายความว่ามีหน่วยความจำไม่เพียงพอ แต่เป็นโอกาสที่จะได้เห็นว่าเกิดอะไรขึ้นในระบบปฏิบัติการ
มีการแจ้งเตือนการใช้หน่วยความจำมาตรฐานสำหรับ VM:
ที่ใช้ร่วมกัน - จำนวน VM RAM ที่ขจัดข้อมูลซ้ำซ้อนโดยใช้ TPS (ภายใน VM หรือระหว่าง VM)
ที่ได้รับ - จำนวนหน่วยความจำโฮสต์กายภาพ (KB) ที่มอบให้กับ VM รวมถึงการแบ่งปัน
ถูกใช้ (อนุญาต - แชร์) - จำนวนหน่วยความจำกายภาพ (KB) ที่ VM ใช้จากโฮสต์ ไม่รวมการแบ่งปัน
หากส่วนหนึ่งของหน่วยความจำ VM ไม่ได้มาจากหน่วยความจำฟิสิคัลของโฮสต์ แต่มาจากไฟล์สลับ หรือหน่วยความจำถูกนำมาจาก VM ผ่าน Balloon Driver จำนวนนี้จะไม่นำมาพิจารณาใน Granted และ Consumed
ค่าที่ได้รับและปริมาณการใช้ที่สูงถือเป็นเรื่องปกติอย่างสมบูรณ์ ระบบปฏิบัติการจะค่อยๆ รับหน่วยความจำจากไฮเปอร์ไวเซอร์และจะไม่ส่งคืน เมื่อเวลาผ่านไปใน VM ที่ทำงานอย่างแข็งขัน ค่าของตัวนับเหล่านี้จะเข้าใกล้จำนวนหน่วยความจำที่กำหนดค่าไว้ และยังคงอยู่ที่นั่น
ศูนย์ — จำนวน VM RAM (KB) ซึ่งมีศูนย์ หน่วยความจำดังกล่าวถือว่าว่างโดยไฮเปอร์ไวเซอร์ และสามารถมอบให้กับเครื่องเสมือนอื่นๆ ได้ หลังจากที่ guest OS เขียนบางสิ่งลงในหน่วยความจำที่เป็นศูนย์ มันจะเข้าสู่ Consumed และจะไม่ส่งคืน
ค่าโสหุ้ยที่สงวนไว้ — จำนวน VM RAM (KB) ที่ไฮเปอร์ไวเซอร์สงวนไว้สำหรับการดำเนินการ VM นี่เป็นจำนวนเล็กน้อย แต่ต้องมีอยู่บนโฮสต์ มิฉะนั้น VM จะไม่เริ่มทำงาน
ลูกโป่ง — จำนวน RAM (KB) ที่ถูกยึดจาก VM โดยใช้ Balloon Driver
การบีบอัด - จำนวน RAM (KB) ที่ถูกบีบอัด
สลับ - จำนวน RAM (KB) ที่ถูกย้ายไปยังดิสก์เนื่องจากไม่มีหน่วยความจำกายภาพบนเซิร์ฟเวอร์
ตัวนับบอลลูนและเทคนิคการเรียกคืนหน่วยความจำอื่นๆ เป็นศูนย์
นี่คือลักษณะของกราฟที่มีตัวนับหน่วยความจำสำหรับ VM ที่ทำงานตามปกติซึ่งมี RAM ขนาด 150 GB
ในกราฟด้านล่าง VM มีปัญหาที่ชัดเจน ใต้กราฟคุณจะเห็นว่าสำหรับ VM นี้มีการใช้เทคนิคที่อธิบายไว้ทั้งหมดสำหรับการทำงานกับ RAM Balloon สำหรับ VM นี้มีขนาดใหญ่กว่า Consumed มาก ในความเป็นจริง VM นั้นตายมากกว่ามีชีวิตอยู่
เอสเอ็กซ์ท็อป
เช่นเดียวกับ CPU หากเราต้องการประเมินสถานการณ์บนโฮสต์อย่างรวดเร็ว รวมถึงไดนามิกของมันด้วยช่วงเวลาสูงสุด 2 วินาที เราควรใช้ ESXTOP
หน้าจอ ESXTOP โดยหน่วยความจำถูกเรียกด้วยปุ่ม "m" และมีลักษณะดังนี้ (เลือกช่อง B, D, H, J, K, L, O):
พารามิเตอร์ต่อไปนี้จะเป็นที่สนใจของเรา:
Mem มีความมุ่งมั่นเกินโดยเฉลี่ย - ค่าเฉลี่ยของการสมัครสมาชิกหน่วยความจำเกินบนโฮสต์เป็นเวลา 1, 5 และ 15 นาที หากมีค่ามากกว่าศูนย์ แสดงว่านี่คือโอกาสที่จะเห็นว่าเกิดอะไรขึ้น แต่ก็ไม่ได้บ่งชี้ถึงปัญหาเสมอไป
ในบรรทัด PMEM/เมกะไบต์ и VMKMEM/MB - ข้อมูลเกี่ยวกับหน่วยความจำฟิสิคัลของเซิร์ฟเวอร์และหน่วยความจำที่มีให้กับ VMkernel จากสิ่งที่น่าสนใจที่นี่ คุณสามารถดูค่าของ minfree (เป็น MB) สถานะของโฮสต์ในหน่วยความจำ (ในกรณีของเราคือสูง)
ในสาย นูมา/เมกะไบต์ คุณสามารถดูการกระจาย RAM ตามโหนด NUMA (ซ็อกเก็ต) ในตัวอย่างนี้ การกระจายตัวไม่สม่ำเสมอ ซึ่งโดยหลักการแล้วถือว่าไม่ดีนัก
ต่อไปนี้เป็นสถิติเซิร์ฟเวอร์ทั่วไปเกี่ยวกับเทคนิคการเรียกคืนหน่วยความจำ:
พีแชร์/MB เป็นสถิติ TPS
สวอป/เมกะไบต์ — สถิติการใช้งาน Swap;
ไปรษณีย์/เมกะไบต์ — สถิติการบีบอัดหน้าหน่วยความจำ
MEMCTL/MB — สถิติการใช้งานบอลลูนไดร์เวอร์
สำหรับ VM แต่ละรายการ เราอาจสนใจข้อมูลต่อไปนี้ ฉันซ่อนชื่อ VM เพื่อไม่ให้ผู้ชมสับสน :) หากตัวชี้วัด ESXTOP คล้ายกับตัวนับใน vSphere ฉันจะให้ตัวนับที่เกี่ยวข้อง
เมมส์ซ — จำนวนหน่วยความจำที่กำหนดค่าบน VM (MB)
MEMSZ = GRANT + MCTLSZ + SWCUR + ไม่ถูกแตะต้อง
GRANT — มอบให้กับ MB
สคช — ใช้งานเป็น MB
เอ็มซีทีแอล? - มีการติดตั้ง Balloon Driver บน VM หรือไม่
เอ็มซีแอลเอสซ — บอลลูนถึง MB
MCTLGT — จำนวน RAM (MB) ที่ ESXi ต้องการรับจาก VM ผ่าน Balloon Driver (Memctl Target)
เอ็มซีทีแอลแม็กซ์ - จำนวน RAM สูงสุด (MB) ที่ ESXi สามารถรับจาก VM ผ่าน Balloon Driver
สววร — จำนวน RAM ปัจจุบัน (MB) ที่จัดสรรให้กับ VM จากไฟล์ Swap
สวจ - จำนวน RAM (MB) ที่ ESXi ต้องการมอบให้กับ VM จากไฟล์ Swap (Swap Target)
นอกจากนี้ คุณสามารถดูข้อมูลโดยละเอียดเพิ่มเติมเกี่ยวกับโทโพโลยี NUMA ของ VM ผ่าน ESXTOP ได้ หากต้องการทำสิ่งนี้ ให้เลือกฟิลด์ D, G:
เอ็นเอชเอ็น – โหนด NUMA ที่ VM ตั้งอยู่ ที่นี่คุณสามารถสังเกตเห็น wide vm ได้ทันที ซึ่งไม่พอดีกับโหนด NUMA หนึ่งโหนด
นร.ม - หน่วยความจำจำนวนเมกะไบต์ที่ VM ใช้จากโหนด NUMA ระยะไกล
เอ็นแอลเอ็มเอ็ม - หน่วยความจำจำนวนเมกะไบต์ที่ VM ใช้จากโหนด NUMA ในเครื่อง
ยังไม่มี%ลิตร – เปอร์เซ็นต์ของหน่วยความจำ VM บนโหนด NUMA ในเครื่อง (หากน้อยกว่า 80% อาจเกิดปัญหาด้านประสิทธิภาพ)
หน่วยความจำบนไฮเปอร์ไวเซอร์
หากตัวนับ CPU สำหรับไฮเปอร์ไวเซอร์มักจะไม่น่าสนใจเป็นพิเศษ สถานการณ์จะกลับกันโดยใช้หน่วยความจำ การใช้หน่วยความจำสูงบน VM ไม่ได้บ่งบอกถึงปัญหาด้านประสิทธิภาพเสมอไป แต่การใช้หน่วยความจำสูงบนไฮเปอร์ไวเซอร์จะทริกเกอร์เทคนิคการจัดการหน่วยความจำและทำให้เกิดปัญหาประสิทธิภาพใน VM ต้องมีการตรวจสอบการแจ้งเตือนการใช้หน่วยความจำโฮสต์เพื่อป้องกันไม่ให้ VM เข้าสู่ Swap
ยกเลิกการสลับ
หาก VM อยู่ใน Swap ประสิทธิภาพจะลดลงอย่างมาก ร่องรอยของการบอลลูนและการบีบอัดหายไปอย่างรวดเร็วหลังจาก RAM ว่างปรากฏบนโฮสต์ แต่เครื่องเสมือนไม่รีบร้อนที่จะกลับจาก Swap ไปยัง RAM ของเซิร์ฟเวอร์
ก่อน ESXi 6.0 วิธีเดียวที่เชื่อถือได้และรวดเร็วในการนำ VM ออกจาก Swap คือการรีบูต (เพื่อให้แม่นยำยิ่งขึ้น ให้ปิด/เปิดคอนเทนเนอร์) เริ่มต้นด้วย ESXi 6.0 แม้ว่าจะไม่เป็นทางการ แต่วิธีที่ได้ผลและเชื่อถือได้ในการลบ VM ออกจาก Swap ก็ปรากฏขึ้น ในการประชุมครั้งหนึ่ง ฉันสามารถพูดคุยกับวิศวกร VMware คนหนึ่งที่ดูแล CPU Scheduler ได้ เขายืนยันว่าวิธีนี้ค่อนข้างได้ผลและปลอดภัย จากประสบการณ์ของเราก็ไม่มีปัญหาเช่นกัน
คำสั่งจริงสำหรับการลบ VM ออกจาก Swap ดันแคน เอปปิง. ฉันจะไม่ทำซ้ำคำอธิบายโดยละเอียด เพียงยกตัวอย่างการใช้งาน ดังที่คุณเห็นในภาพหน้าจอ บางครั้งหลังจากดำเนินการตามคำสั่งที่ระบุ Swap จะหายไปบน VM
เคล็ดลับการจัดการหน่วยความจำ ESXi
สุดท้ายนี้ ต่อไปนี้เป็นเคล็ดลับบางส่วนที่จะช่วยคุณหลีกเลี่ยงปัญหาเกี่ยวกับประสิทธิภาพของ VM เนื่องจาก RAM:
- หลีกเลี่ยงการสมัครสมาชิกหน่วยความจำมากเกินไปในคลัสเตอร์ที่มีประสิทธิผล ขอแนะนำให้มีหน่วยความจำว่างประมาณ 20-30% ในคลัสเตอร์เสมอ เพื่อให้ DRS (และผู้ดูแลระบบ) มีพื้นที่ว่างในการจัดทำ และ VM จะไม่เข้าสู่ Swap ในระหว่างการย้ายข้อมูล นอกจากนี้อย่าลืมเกี่ยวกับระยะขอบสำหรับความทนทานต่อข้อผิดพลาด เป็นเรื่องที่ไม่พึงประสงค์ เมื่อเซิร์ฟเวอร์ตัวหนึ่งทำงานล้มเหลวและ VM ถูกรีบูตโดยใช้ HA เครื่องบางเครื่องก็จะเข้าสู่ Swap เช่นกัน
- ในโครงสร้างพื้นฐานที่มีการรวมกันสูง พยายามอย่าสร้าง VM ที่มีหน่วยความจำโฮสต์มากกว่าครึ่งหนึ่ง การดำเนินการนี้อีกครั้งจะช่วยให้ DRS กระจายเครื่องเสมือนผ่านเซิร์ฟเวอร์คลัสเตอร์ได้โดยไม่มีปัญหาใดๆ แน่นอนว่ากฎนี้ไม่เป็นสากล :)
- ดูการแจ้งเตือนการใช้หน่วยความจำโฮสต์
- อย่าลืมติดตั้ง VMware Tools บน VM และอย่าปิด Ballooning
- พิจารณาเปิดใช้งาน Inter-VM TPS และปิดใช้งานเพจขนาดใหญ่ใน VDI และสภาพแวดล้อมการทดสอบ
- หาก VM กำลังประสบปัญหาด้านประสิทธิภาพ ให้ตรวจสอบเพื่อดูว่ากำลังใช้หน่วยความจำจากโหนด NUMA ระยะไกลหรือไม่
- นำ VM ของคุณออกจาก Swap โดยเร็วที่สุด! เหนือสิ่งอื่นใด หาก VM อยู่ใน Swap ระบบจัดเก็บข้อมูลจะได้รับผลกระทบด้วยเหตุผลที่ชัดเจน
นั่นคือทั้งหมดสำหรับฉันเกี่ยวกับ RAM ด้านล่างนี้เป็นบทความที่เกี่ยวข้องสำหรับผู้ที่ต้องการเจาะลึกรายละเอียด บทความถัดไปจะกล่าวถึง storadzh
ลิงค์ที่มีประโยชน์
ที่มา: will.com