หากคุณดูแลโครงสร้างพื้นฐานเสมือนโดยใช้ VMware vSphere (หรือกลุ่มเทคโนโลยีอื่นๆ) คุณมักจะได้ยินคำร้องเรียนจากผู้ใช้: “เครื่องเสมือนช้า!” ในบทความชุดนี้ ผมจะวิเคราะห์ตัวชี้วัดประสิทธิภาพ และบอกคุณว่าอะไรที่ทำให้ช้าลง และเพราะเหตุใด และอย่างไรเพื่อให้แน่ใจว่าจะไม่ช้าลง
ฉันจะพิจารณาประสิทธิภาพของเครื่องเสมือนในด้านต่อไปนี้:
- ซีพียู
- แกะ,
- ดิสก์,
- เครือข่าย
ฉันจะเริ่มต้นด้วยซีพียู
เพื่อวิเคราะห์ประสิทธิภาพเราจะต้อง:
- ตัวนับประสิทธิภาพ vCenter – ตัวนับประสิทธิภาพ กราฟสามารถดูได้ผ่าน vSphere Client ข้อมูลเกี่ยวกับตัวนับเหล่านี้มีอยู่ในไคลเอนต์ทุกเวอร์ชัน (“thick” ไคลเอนต์ใน C#, เว็บไคลเอนต์ใน Flex และเว็บไคลเอนต์ใน HTML5) ในบทความเหล่านี้ เราจะใช้ภาพหน้าจอจากไคลเอนต์ C# เพียงเพราะมันดูดีกว่าในขนาดจิ๋ว :)
- เอสเอ็กซ์ท็อป – ยูทิลิตี้ที่รันจากบรรทัดคำสั่ง ESXi ด้วยความช่วยเหลือนี้ คุณสามารถรับค่าของตัวนับประสิทธิภาพแบบเรียลไทม์หรืออัปโหลดค่าเหล่านี้ในช่วงระยะเวลาหนึ่งลงในไฟล์ .csv เพื่อการวิเคราะห์เพิ่มเติม ต่อไป ฉันจะบอกคุณเพิ่มเติมเกี่ยวกับเครื่องมือนี้และให้ลิงก์ที่เป็นประโยชน์มากมายไปยังเอกสารประกอบและบทความในหัวข้อนี้
ทฤษฎีเล็กน้อย
ใน ESXi กระบวนการที่แยกจากกัน – โลกในคำศัพท์เฉพาะของ VMware – มีหน้าที่รับผิดชอบในการทำงานของ vCPU แต่ละตัว (แกนเครื่องเสมือน) นอกจากนี้ยังมีกระบวนการบริการ แต่จากมุมมองของการวิเคราะห์ประสิทธิภาพของ VM นั้นน่าสนใจน้อยกว่า
กระบวนการใน ESXi สามารถอยู่ในสถานะใดสถานะหนึ่งจากสี่สถานะ:
- วิ่ง – กระบวนการนี้ทำงานที่มีประโยชน์บางอย่าง
- รอ – กระบวนการไม่ทำงานใดๆ (ไม่ได้ใช้งาน) หรือกำลังรออินพุต/เอาท์พุต
- คอสต็อป – เงื่อนไขที่เกิดขึ้นในเครื่องเสมือนแบบมัลติคอร์ เกิดขึ้นเมื่อตัวกำหนดเวลา CPU ของไฮเปอร์ไวเซอร์ (ESXi CPU Scheduler) ไม่สามารถกำหนดเวลาการดำเนินการพร้อมกันของแกนเครื่องเสมือนที่ใช้งานอยู่ทั้งหมดบนแกนเซิร์ฟเวอร์จริงได้ ในโลกทางกายภาพ แกนประมวลผลทั้งหมดทำงานแบบคู่ขนาน ระบบปฏิบัติการเกสต์ภายใน VM คาดว่าจะมีพฤติกรรมที่คล้ายกัน ดังนั้นไฮเปอร์ไวเซอร์จึงต้องชะลอแกน VM ซึ่งสามารถทำให้รอบสัญญาณนาฬิกาเสร็จสิ้นเร็วขึ้น ใน ESXi เวอร์ชันใหม่ ตัวกำหนดเวลา CPU จะใช้กลไกที่เรียกว่าการกำหนดเวลาร่วมแบบผ่อนคลาย: ไฮเปอร์ไวเซอร์จะพิจารณาช่องว่างระหว่างแกนเครื่องเสมือนที่ "เร็วที่สุด" และ "ช้าที่สุด" (เอียง) หากช่องว่างเกินเกณฑ์ที่กำหนด แกนประมวลผลที่รวดเร็วจะเข้าสู่สถานะต้นทุน หากแกน VM ใช้เวลามากในสถานะนี้ ก็อาจทำให้เกิดปัญหาด้านประสิทธิภาพได้
- พร้อม – กระบวนการเข้าสู่สถานะนี้เมื่อไฮเปอร์ไวเซอร์ไม่สามารถจัดสรรทรัพยากรสำหรับการดำเนินการได้ ค่าความพร้อมสูงอาจทำให้เกิดปัญหาประสิทธิภาพการทำงานของ VM
ตัวนับประสิทธิภาพ CPU ของเครื่องเสมือนขั้นพื้นฐาน
การใช้งาน CPU, % แสดงเปอร์เซ็นต์การใช้งาน CPU ในช่วงเวลาที่กำหนด
จะวิเคราะห์อย่างไร? หาก VM ใช้ CPU อย่างต่อเนื่องที่ 90% หรือมีจุดสูงสุดถึง 100% แสดงว่าเรามีปัญหา ปัญหาสามารถแสดงได้ไม่เพียงแต่ในการดำเนินการ "ช้า" ของแอปพลิเคชันภายใน VM เท่านั้น แต่ยังรวมถึงความไม่สามารถเข้าถึงได้ของ VM ผ่านเครือข่ายด้วย หากระบบตรวจสอบแสดงว่า VM หยุดทำงานเป็นระยะๆ ให้ใส่ใจกับจุดสูงสุดในกราฟการใช้งาน CPU
มีสัญญาณเตือนมาตรฐานที่แสดงโหลด CPU ของเครื่องเสมือน:
จะทำอย่างไร? หากการใช้งาน CPU ของ VM ทำงานหนักอย่างต่อเนื่อง คุณสามารถพิจารณาเพิ่มจำนวน vCPU ได้ (น่าเสียดายที่วิธีนี้ไม่ได้ช่วยเสมอไป) หรือย้าย VM ไปยังเซิร์ฟเวอร์ที่มีโปรเซสเซอร์ที่ทรงพลังกว่า
การใช้งาน CPU ในหน่วย MHz
ในกราฟบนการใช้งาน vCenter เป็น % คุณสามารถดูเฉพาะเครื่องเสมือนทั้งหมดเท่านั้น ไม่มีกราฟสำหรับแต่ละคอร์ (ใน Esxtop มีค่า % สำหรับคอร์) สำหรับแต่ละคอร์ คุณสามารถดูการใช้งานเป็น MHz
จะวิเคราะห์อย่างไร? มันเกิดขึ้นที่แอปพลิเคชันไม่ได้รับการปรับให้เหมาะสมสำหรับสถาปัตยกรรมแบบมัลติคอร์: ใช้เพียงคอร์เดียว 100% และส่วนที่เหลือไม่ได้ใช้งานโดยไม่มีการโหลด ตัวอย่างเช่น ด้วยการตั้งค่าการสำรองข้อมูลเริ่มต้น MS SQL จะเริ่มกระบวนการบนคอร์เดียวเท่านั้น เป็นผลให้การสำรองข้อมูลช้าลงไม่ใช่เพราะความเร็วของดิสก์ที่ช้า (นี่คือสิ่งที่ผู้ใช้บ่นในตอนแรก) แต่เนื่องจากโปรเซสเซอร์ไม่สามารถรับมือได้ ปัญหาได้รับการแก้ไขโดยการเปลี่ยนพารามิเตอร์: การสำรองข้อมูลเริ่มทำงานพร้อมกันในหลายไฟล์ (ตามลำดับในหลายกระบวนการ)
ตัวอย่างของการโหลดที่ไม่สม่ำเสมอบนคอร์
นอกจากนี้ยังมีสถานการณ์ (ตามกราฟด้านบน) เมื่อแกนโหลดไม่สม่ำเสมอและบางแกนมีจุดสูงสุดที่ 100% เช่นเดียวกับการโหลดแกนเดียวเท่านั้น การแจ้งเตือนสำหรับการใช้งาน CPU จะไม่ทำงาน (สำหรับ VM ทั้งหมด) แต่จะมีปัญหาด้านประสิทธิภาพ
จะทำอย่างไร? หากซอฟต์แวร์ในเครื่องเสมือนโหลดแกนประมวลผลไม่สม่ำเสมอ (ใช้แกนประมวลผลเพียงแกนเดียวหรือบางส่วน) ก็ไม่มีประโยชน์ที่จะเพิ่มจำนวนแกนประมวลผล ในกรณีนี้ ควรย้าย VM ไปยังเซิร์ฟเวอร์ที่มีโปรเซสเซอร์ที่ทรงพลังกว่าจะดีกว่า
คุณยังสามารถลองตรวจสอบการตั้งค่าการใช้พลังงานใน BIOS ของเซิร์ฟเวอร์ได้ ผู้ดูแลระบบหลายรายเปิดใช้งานโหมดประสิทธิภาพสูงใน BIOS และปิดการใช้งานเทคโนโลยีประหยัดพลังงานสถานะ C และสถานะ P โปรเซสเซอร์ Intel สมัยใหม่ใช้เทคโนโลยี Turbo Boost ซึ่งเพิ่มความถี่ของคอร์โปรเซสเซอร์แต่ละตัวโดยเสียค่าใช้จ่ายของคอร์อื่น แต่จะใช้งานได้เฉพาะเมื่อเปิดเทคโนโลยีประหยัดพลังงานเท่านั้น หากเราปิดการใช้งาน โปรเซสเซอร์จะไม่สามารถลดการใช้พลังงานของคอร์ที่ไม่ได้โหลดได้
VMware ไม่แนะนำให้ปิดการใช้งานเทคโนโลยีประหยัดพลังงานบนเซิร์ฟเวอร์ แต่ให้เลือกโหมดที่ปล่อยให้การจัดการพลังงานเป็นหน้าที่ของไฮเปอร์ไวเซอร์มากที่สุด ในกรณีนี้ ในการตั้งค่าการใช้พลังงานของไฮเปอร์ไวเซอร์ คุณต้องเลือกประสิทธิภาพสูง
หากคุณมี VM แต่ละตัว (หรือแกน VM) ในโครงสร้างพื้นฐานของคุณที่ต้องการความถี่ CPU เพิ่มขึ้น การปรับการใช้พลังงานอย่างถูกต้องสามารถปรับปรุงประสิทธิภาพได้อย่างมาก
ซีพียูพร้อม
หากแกน VM (vCPU) อยู่ในสถานะพร้อม ระบบจะไม่ทำงานที่เป็นประโยชน์ เงื่อนไขนี้เกิดขึ้นเมื่อไฮเปอร์ไวเซอร์ไม่พบแกนทางกายภาพที่ว่างซึ่งสามารถกำหนดกระบวนการ vCPU ของเครื่องเสมือนได้
จะวิเคราะห์อย่างไร? โดยทั่วไป หากคอร์ของเครื่องเสมือนอยู่ในสถานะพร้อมมากกว่า 10% คุณจะสังเกตเห็นปัญหาด้านประสิทธิภาพ พูดง่ายๆ ก็คือมากกว่า 10% ของเวลาที่ VM รอให้ทรัพยากรทางกายภาพพร้อมใช้งาน
ใน vCenter คุณสามารถดู 2 ตัวนับที่เกี่ยวข้องกับ CPU Ready:
- ความพร้อม
- พร้อมแล้ว
ค่าของตัวนับทั้งสองสามารถดูได้ทั้งสำหรับ VM ทั้งหมดและสำหรับแต่ละคอร์
ความพร้อมจะแสดงค่าทันทีเป็นเปอร์เซ็นต์แต่เฉพาะแบบเรียลไทม์เท่านั้น (ข้อมูลชั่วโมงที่ผ่านมา ช่วงเวลาการวัด 20 วินาที) ควรใช้ตัวนับนี้เพื่อค้นหาปัญหา "ร้อนที่ส้นเท้า" เท่านั้น
สามารถดูค่าตัวนับพร้อมได้จากมุมมองทางประวัติศาสตร์ สิ่งนี้มีประโยชน์สำหรับการสร้างรูปแบบและสำหรับการวิเคราะห์ปัญหาในเชิงลึก ตัวอย่างเช่น หากเครื่องเสมือนเริ่มประสบปัญหาด้านประสิทธิภาพในช่วงเวลาหนึ่ง คุณสามารถเปรียบเทียบช่วงเวลาของค่า CPU Ready กับโหลดทั้งหมดบนเซิร์ฟเวอร์ที่ VM นี้ทำงานอยู่ และใช้มาตรการเพื่อลดโหลด (หาก DRS ล้มเหลว)
พร้อม ซึ่งแตกต่างจากความพร้อม ที่ไม่ได้แสดงเป็นเปอร์เซ็นต์ แต่เป็นมิลลิวินาที นี่คือตัวนับประเภทการรวม กล่าวคือ จะแสดงระยะเวลาการวัดที่คอร์ VM อยู่ในสถานะพร้อม คุณสามารถแปลงค่านี้เป็นเปอร์เซ็นต์ได้โดยใช้สูตรง่ายๆ:
(ค่าผลรวม CPU พร้อม / (ช่วงเวลาการอัพเดตเริ่มต้นของแผนภูมิเป็นวินาที * 1000)) * 100 = CPU พร้อม %
ตัวอย่างเช่น สำหรับ VM ในกราฟด้านล่าง ค่าความพร้อมสูงสุดสำหรับเครื่องเสมือนทั้งหมดจะเป็นดังนี้:
เมื่อคำนวณเปอร์เซ็นต์ความพร้อม คุณควรคำนึงถึงสองประเด็น:
- ค่า Ready สำหรับ VM ทั้งหมดคือผลรวมของ Ready ข้ามคอร์
- ช่วงการวัด สำหรับเรียลไทม์คือ 20 วินาที และตัวอย่างเช่น ในกราฟรายวันคือ 300 วินาที
ด้วยการแก้ไขปัญหาเบื้องต้น จุดง่ายๆ เหล่านี้อาจพลาดได้ง่าย และเสียเวลาอันมีค่าไปกับการแก้ปัญหาที่ไม่มีอยู่จริง
มาคำนวณความพร้อมตามข้อมูลจากกราฟด้านล่างกัน (324474/(20*1000))*100 = 1622% สำหรับ VM ทั้งหมด ถ้าดูที่แกนก็ไม่น่ากลัวเท่าไหร่: 1622/64 = 25% ต่อคอร์ ในกรณีนี้ การตรวจจับนั้นค่อนข้างง่าย: ค่า Ready นั้นไม่สมจริง แต่หากเรากำลังพูดถึงประมาณ 10–20% สำหรับ VM ทั้งหมดที่มีหลายคอร์ ค่าของแต่ละคอร์อาจอยู่ในช่วงปกติ
จะทำอย่างไร? ค่าพร้อมที่สูงบ่งชี้ว่าเซิร์ฟเวอร์มีทรัพยากรตัวประมวลผลไม่เพียงพอสำหรับการทำงานปกติของเครื่องเสมือน ในสถานการณ์เช่นนี้ สิ่งที่เหลืออยู่คือการลดการสมัครใช้งานเกินโดยโปรเซสเซอร์ (vCPU:pCPU) แน่นอนว่าสามารถทำได้โดยการลดพารามิเตอร์ของ VM ที่มีอยู่หรือโดยการย้ายส่วนหนึ่งของ VM ไปยังเซิร์ฟเวอร์อื่น
ร่วมหยุด
จะวิเคราะห์อย่างไร? ตัวนับนี้เป็นประเภทการรวมเช่นกัน และถูกแปลงเป็นเปอร์เซ็นต์ในลักษณะเดียวกับพร้อม:
(ค่าผลรวม CPU co-stop / (ช่วงเวลาการอัปเดตเริ่มต้นของแผนภูมิเป็นวินาที * 1000)) * 100 = CPU co-stop %
ที่นี่คุณต้องใส่ใจกับจำนวนคอร์บน VM และช่วงเวลาการวัดด้วย
ในสถานะ costop เคอร์เนลไม่ทำงานที่เป็นประโยชน์ ด้วยการเลือกขนาด VM และโหลดปกติบนเซิร์ฟเวอร์ที่ถูกต้อง ตัวนับร่วมควรอยู่ใกล้กับศูนย์
ในกรณีนี้โหลดผิดปกติอย่างเห็นได้ชัด :)
จะทำอย่างไร? หาก VM หลายตัวที่มีคอร์จำนวนมากทำงานบนไฮเปอร์ไวเซอร์ตัวเดียวและมีการสมัครใช้งานมากเกินไปบน CPU ตัวนับ co-stop อาจเพิ่มขึ้นซึ่งจะทำให้เกิดปัญหากับประสิทธิภาพของ VM เหล่านี้
นอกจากนี้ co-stop จะเพิ่มขึ้นหากแกนประมวลผลที่ใช้งานอยู่ของ VM หนึ่งตัวใช้เธรดบนแกนเซิร์ฟเวอร์จริงตัวเดียวที่เปิดใช้งาน Hyper-treading สถานการณ์นี้อาจเกิดขึ้น เช่น ถ้า VM มีคอร์มากกว่าที่มีอยู่จริงบนเซิร์ฟเวอร์ที่กำลังทำงานอยู่ หรือหากเปิดใช้งานการตั้งค่า "preferHT" สำหรับ VM คุณสามารถอ่านเกี่ยวกับการตั้งค่านี้ได้ .
เพื่อหลีกเลี่ยงปัญหาเกี่ยวกับประสิทธิภาพของ VM เนื่องจากมี co-stop สูง ให้เลือกขนาด VM ตามคำแนะนำของผู้ผลิตซอฟต์แวร์ที่ทำงานบน VM นี้และความสามารถของเซิร์ฟเวอร์จริงที่ VM ทำงาน
อย่าเพิ่มคอร์สำรอง เพราะอาจทำให้เกิดปัญหาด้านประสิทธิภาพไม่เพียงแต่สำหรับ VM เองเท่านั้น แต่ยังรวมถึงเพื่อนบ้านบนเซิร์ฟเวอร์ด้วย
ตัวชี้วัด CPU ที่มีประโยชน์อื่นๆ
วิ่ง – ระยะเวลา (มิลลิวินาที) ในระหว่างระยะเวลาการวัดที่ vCPU อยู่ในสถานะ RUN กล่าวคือ vCPU กำลังทำงานที่มีประโยชน์จริง ๆ
Idle – ระยะเวลา (มิลลิวินาที) ในระหว่างระยะเวลาการวัด vCPU อยู่ในสถานะไม่มีการใช้งาน ค่าว่างสูงไม่ใช่ปัญหา vCPU แค่ "ไม่มีอะไรให้ทำ"
รอ – ระยะเวลา (มิลลิวินาที) ในระหว่างระยะเวลาการวัด vCPU อยู่ในสถานะรอ เนื่องจาก IDLE รวมอยู่ในตัวนับนี้ ค่ารอที่สูงจึงไม่บ่งบอกถึงปัญหาเช่นกัน แต่หาก Wait IDLE ต่ำเมื่อ Wait สูง หมายความว่า VM กำลังรอให้การดำเนินการ I/O เสร็จสิ้น และอาจบ่งบอกถึงปัญหากับประสิทธิภาพของฮาร์ดไดรฟ์หรืออุปกรณ์เสมือนใดๆ ของ VM
แม็กซ์จำกัด – ระยะเวลา (มิลลิวินาที) ในระหว่างระยะเวลาการวัด vCPU อยู่ในสถานะพร้อม เนื่องจากขีดจำกัดทรัพยากรที่ตั้งไว้ หากประสิทธิภาพต่ำอย่างอธิบายไม่ได้ จะมีประโยชน์ในการตรวจสอบค่าของตัวนับนี้และขีดจำกัดของ CPU ในการตั้งค่า VM VM อาจมีข้อจำกัดที่คุณไม่ทราบจริงๆ ตัวอย่างเช่น สิ่งนี้เกิดขึ้นเมื่อ VM ถูกโคลนจากเทมเพลตที่มีการตั้งค่าขีดจำกัดของ CPU
สลับรอครับ. – ระยะเวลาการวัดที่ vCPU รอการดำเนินการด้วย VMkernel Swap หากค่าของตัวนับนี้สูงกว่าศูนย์ แสดงว่า VM มีปัญหาด้านประสิทธิภาพอย่างแน่นอน เราจะพูดถึง SWAP เพิ่มเติมในบทความเกี่ยวกับตัวนับ RAM
เอสเอ็กซ์ท็อป
หากตัวนับประสิทธิภาพใน vCenter นั้นดีสำหรับการวิเคราะห์ข้อมูลในอดีต การวิเคราะห์การปฏิบัติงานของปัญหาจะดีกว่าใน ESXTOP ที่นี่ค่าทั้งหมดจะแสดงในรูปแบบสำเร็จรูป (ไม่จำเป็นต้องแปลอะไรเลย) และระยะเวลาการวัดขั้นต่ำคือ 2 วินาที
หน้าจอ ESXTOP สำหรับ CPU ถูกเรียกด้วยปุ่ม "c" และมีลักษณะดังนี้:
เพื่อความสะดวก คุณสามารถเหลือเฉพาะกระบวนการของเครื่องเสมือนได้โดยการกด Shift-V
หากต้องการดูเกณฑ์ชี้วัดสำหรับคอร์ VM แต่ละคอร์ ให้กด “e” และป้อน GID ของ VM ที่สนใจ (30919 ในภาพหน้าจอด้านล่าง):
ให้ฉันอธิบายสั้น ๆ เกี่ยวกับคอลัมน์ที่แสดงโดยค่าเริ่มต้น สามารถเพิ่มคอลัมน์เพิ่มเติมได้โดยการกด "f"
NWLD (จำนวนโลก) – จำนวนกระบวนการในกลุ่ม หากต้องการขยายกลุ่มและดูเกณฑ์ชี้วัดสำหรับแต่ละกระบวนการ (เช่น สำหรับแต่ละคอร์ใน VM แบบมัลติคอร์) ให้กด “e” หากมีมากกว่าหนึ่งกระบวนการในกลุ่ม ค่าเมตริกสำหรับกลุ่มจะเท่ากับผลรวมของเมตริกสำหรับแต่ละกระบวนการ
%ใช้แล้ว – จำนวนรอบ CPU ของเซิร์ฟเวอร์ที่ใช้โดยกระบวนการหรือกลุ่มของกระบวนการ
%วิ่ง – ระยะเวลาการวัดที่กระบวนการอยู่ในสถานะ RUN นานเท่าใด เช่น ได้ทำงานที่เป็นประโยชน์ แตกต่างจาก %USED ตรงที่ไม่คำนึงถึงไฮเปอร์เธรด การปรับความถี่ และเวลาที่ใช้ในงานระบบ (%SYS)
%SYS – เวลาที่ใช้ในงานระบบ เช่น การประมวลผลแบบขัดจังหวะ, I/O, การทำงานของเครือข่าย ฯลฯ ค่าอาจสูงได้หาก VM มี I/O ขนาดใหญ่
%OVRLP – ระยะเวลาที่ฟิสิคัลคอร์ที่กระบวนการ VM กำลังทำงานอยู่กับงานของกระบวนการอื่น
ตัวชี้วัดเหล่านี้เกี่ยวข้องกันดังนี้:
% ใช้แล้ว = % รัน + % SYS - % OVRLP
โดยทั่วไปแล้ว %USED ตัวชี้วัดจะมีข้อมูลมากกว่า
%รอ – ระยะเวลาการวัดกระบวนการอยู่ในสถานะรอนานเท่าใด เปิดใช้งาน IDLE
%ไม่ได้ใช้งาน – ระยะเวลาการวัดกระบวนการอยู่ในสถานะ IDLE นานเท่าใด
% SWPWT – ระยะเวลาการวัดที่ vCPU รอการดำเนินการด้วย VMkernel Swap
%VMWAIT – ระยะเวลาการวัด vCPU อยู่ในสถานะรอเหตุการณ์ (โดยปกติคือ I/O) ไม่มีตัวนับที่คล้ายกันใน vCenter ค่าที่สูงบ่งบอกถึงปัญหาเกี่ยวกับ I/O บน VM
% รอ = % VMWAIT + % IDLE + % SWPWT
หาก VM ไม่ได้ใช้ VMkernel Swap ดังนั้นเมื่อวิเคราะห์ปัญหาด้านประสิทธิภาพ แนะนำให้ดูที่ %VMWAIT เนื่องจากการวัดนี้ไม่ได้คำนึงถึงเวลาที่ VM ไม่ได้ทำอะไรเลย (%IDLE)
%อาร์ดีวาย – ระยะเวลาการวัดกระบวนการอยู่ในสถานะพร้อม
%CSTP – ระยะเวลาการวัดที่กระบวนการอยู่ในสถานะ costop
%MLMTD – ระยะเวลาการวัด vCPU อยู่ในสถานะพร้อมเนื่องจากขีดจำกัดทรัพยากรที่ตั้งไว้
%WAIT + %RDY + %CSTP + %RUN = 100% – แกน VM อยู่ในสถานะใดสถานะหนึ่งจากสี่สถานะนี้เสมอ
CPU บนไฮเปอร์ไวเซอร์
vCenter ยังมีตัวนับประสิทธิภาพของ CPU สำหรับไฮเปอร์ไวเซอร์ด้วย แต่ไม่มีอะไรน่าสนใจ - เป็นเพียงผลรวมของตัวนับสำหรับ VM ทั้งหมดบนเซิร์ฟเวอร์
วิธีที่สะดวกที่สุดในการดูสถานะ CPU บนเซิร์ฟเวอร์คือบนแท็บสรุป:
สำหรับเซิร์ฟเวอร์ เช่นเดียวกับเครื่องเสมือน จะมีสัญญาณเตือนมาตรฐาน:
เมื่อเซิร์ฟเวอร์ CPU โหลดสูง VMs ที่ทำงานอยู่จะเริ่มประสบปัญหาด้านประสิทธิภาพ
ใน ESXTOP ข้อมูลการโหลด CPU ของเซิร์ฟเวอร์จะแสดงที่ด้านบนของหน้าจอ นอกเหนือจากโหลด CPU มาตรฐานซึ่งไม่ได้ให้ข้อมูลมากนักสำหรับไฮเปอร์ไวเซอร์แล้ว ยังมีตัวชี้วัดอีกสามตัว:
ประโยชน์หลัก(%) – กำลังโหลดแกนเซิร์ฟเวอร์ฟิสิคัล ตัวนับนี้แสดงระยะเวลาที่แกนทำงานในระหว่างช่วงการวัด
PCPU ยูทิลิตี้(%) – หากเปิดใช้งานไฮเปอร์เธรด จะมีสองเธรด (PCPU) ต่อฟิสิคัลคอร์ ตัวชี้วัดนี้แสดงให้เห็นว่าแต่ละเธรดใช้เวลานานเท่าใดในการทำงานให้เสร็จสมบูรณ์
PCPU ที่ใช้(%) – เช่นเดียวกับ PCPU UTIL(%) แต่คำนึงถึงการปรับขนาดความถี่ (ไม่ว่าจะลดความถี่คอร์เพื่อวัตถุประสงค์ในการประหยัดพลังงาน หรือเพิ่มความถี่คอร์เนื่องจากเทคโนโลยี Turbo Boost) และไฮเปอร์เธรด
PCPU_USED% = PCPU_UTIL% * ความถี่คอร์ที่มีประสิทธิภาพ / ความถี่คอร์ที่ระบุ
ในภาพหน้าจอนี้ สำหรับบางคอร์ เนื่องจาก Turbo Boost ค่า USED จะมากกว่า 100% เนื่องจากความถี่คอร์สูงกว่าความถี่ที่ระบุ
คำสองสามคำเกี่ยวกับวิธีการคำนึงถึงไฮเปอร์เธรด หากกระบวนการดำเนินการ 100% ของเวลาทั้งสองเธรดของฟิสิคัลคอร์ของเซิร์ฟเวอร์ ในขณะที่คอร์ทำงานที่ความถี่ที่กำหนด ดังนั้น:
- CORE UTIL สำหรับคอร์จะเป็น 100%
- PCPU UTIL สำหรับทั้งสองเธรดจะเป็น 100%
- PCPU ที่ใช้สำหรับทั้งสองเธรดจะเป็น 50%
หากเธรดทั้งสองไม่ทำงาน 100% ของเวลาในช่วงเวลาการวัด จากนั้นในช่วงเวลาดังกล่าวเมื่อเธรดทำงานแบบขนาน PCPU ที่ใช้สำหรับคอร์จะถูกแบ่งครึ่ง
ESXTOP ยังมีหน้าจอพร้อมพารามิเตอร์การใช้พลังงาน CPU ของเซิร์ฟเวอร์ ที่นี่คุณสามารถดูได้ว่าเซิร์ฟเวอร์ใช้เทคโนโลยีประหยัดพลังงานหรือไม่: สถานะ C และสถานะ P เรียกว่าด้วยปุ่ม "p":
ปัญหาประสิทธิภาพ CPU ทั่วไป
สุดท้ายนี้ ฉันจะพูดถึงสาเหตุทั่วไปของปัญหาเกี่ยวกับประสิทธิภาพของ VM CPU และให้คำแนะนำสั้นๆ ในการแก้ไขปัญหาเหล่านี้:
ความเร็วสัญญาณนาฬิกาหลักไม่เพียงพอ หากไม่สามารถอัปเกรด VM ของคุณเป็นคอร์ที่ทรงพลังกว่านี้ได้ คุณสามารถลองเปลี่ยนการตั้งค่าพลังงานเพื่อให้ Turbo Boost ทำงานได้อย่างมีประสิทธิภาพมากขึ้น
การกำหนดขนาด VM ไม่ถูกต้อง (มีแกนประมวลผลมากเกินไป/น้อยเกินไป) หากคุณติดตั้งคอร์ไม่กี่คอร์ VM จะมีภาระ CPU สูง หากมีมากให้จับ co-stop สูง
การสมัครสมาชิก CPU มากเกินไปบนเซิร์ฟเวอร์ หาก VM มีความพร้อมใช้งานสูง ให้ลดการสมัครสมาชิก CPU มากเกินไป
โทโพโลยี NUMA ไม่ถูกต้องบน VM ขนาดใหญ่ โทโพโลยี NUMA ที่ VM เห็น (vNUMA) ต้องตรงกับโทโพโลยี NUMA ของเซิร์ฟเวอร์ (pNUMA) ตัวอย่างเช่นการวินิจฉัยและแนวทางแก้ไขที่เป็นไปได้สำหรับปัญหานี้เขียนไว้ในหนังสือ . หากคุณไม่ต้องการเจาะลึกและไม่มีข้อจำกัดด้านสิทธิ์การใช้งานบนระบบปฏิบัติการที่ติดตั้งบน VM ให้สร้างซ็อกเก็ตเสมือนจำนวนมากบน VM ทีละคอร์ คุณจะไม่สูญเสียอะไรมาก :)
นั่นคือทั้งหมดสำหรับฉันเกี่ยวกับ CPU ถามคำถาม. ในส่วนถัดไปฉันจะพูดถึง RAM
ลิงค์ที่มีประโยชน์
ที่มา: will.com