CPU Ready: Hypervisor Killer เงียบ

CPU Ready คือสิ่งที่คุณอาจไม่คุ้นเคย ที่ความประทับใจครั้งแรกอาจเป็นเหมือนสิ่งที่ดี แต่น่าเสียดายที่ไม่ใช่ CPU Ready ได้รับสภาพแวดล้อมเสมือนเป็นเวลานานกว่าที่เรารู้ว่าเป็นอย่างไร VMware กำหนดค่านี้เป็นเปอร์เซ็นต์ของเวลาที่เครื่องเสมือนพร้อม แต่ไม่สามารถกำหนดเวลาให้ทำงานบน CPU จริงได้ เวลาที่พร้อมใช้งานของ CPU ขึ้นอยู่กับจำนวนเครื่องเสมือนบนเครื่องโฮสต์และโหลด CPU ของเครื่อง Hyper-V เพิ่งเริ่มให้ตัวนับนี้ (Hyper-V Hypervisor Virtual processor \ CPU รอเวลาต่อการจัดส่ง) และ hypervisors อื่น ๆ อาจไม่สามารถระบุเมตริกนี้ได้

เพื่อให้เข้าใจว่า CPU Ready คืออะไรเราจะต้องเข้าใจว่า hypervisor ตั้งเวลาให้ซีพียูเสมือน (vCPU) ให้กับซีพียูทางกายภาพ (pCPU) เมื่อต้องใช้เวลา vCPU ใน VM ระบบจะกำหนดเวลา vCPU (s) ให้กับ pCPU (s) เพื่อให้คำสั่ง / กระบวนการ / เธรดสามารถทำงานได้กับ pCPU ในโลกแห่งอุดมคติไม่มีความขัดแย้งทางทรัพยากรหรือปัญหาคอขวดเมื่อต้องเกิดขึ้น เมื่อ vCPU VM ตัวเดียวต้องกำหนดเวลากับ pCPU แกนหลักของ pCPU จะพร้อมใช้งานและ CPU Ready ก็น้อยมากในโลกที่เหมาะนี้ เป็นสิ่งสำคัญที่ต้องทราบว่า CPU Ready อยู่เสมอ แต่ในโลกที่เหมาะจะน้อยมากและไม่สังเกตเห็น

ในโลกแห่งความเป็นจริงข้อดีอย่างหนึ่งของการทำเวอร์ช่วลไลซ์เซชั่นคือคุณสามารถเดิมพันได้ว่า VMs จำนวนมากของคุณจะไม่สามารถเพิ่ม vCPU ของพวกเขาทั้งหมดในเวลาเดียวกันและหาก VMs ใช้งานต่ำมากคุณอาจคาดเดาได้ว่าคุณสามารถทำอะไรได้มากเท่าใด โหลดโฮสต์กายภาพของคุณตามการใช้งาน CPU และการใช้ RAM ในอดีตข้อเสนอแนะที่จะมีอัตราส่วน 4 vCPU ถึง 1 pCPU หรือ 10: 1 ขึ้นอยู่กับปริมาณงาน ตัวอย่างเช่นคุณอาจมีโปรเซสเซอร์ Quad-Core เพียงเครื่องเดียว แต่มี VMs 4 ตัวที่มี vCPU แต่ละตัวเพื่อให้คุณมี 16 VCPU ถึง 4 ชิ้นหรือ 4: 1 สิ่งที่วิศวกรกำลังเริ่มมองเห็นคือสภาพแวดล้อมชะมัดชะลอตัวและไม่สามารถเข้าใจได้ว่าทำไม การใช้ RAM เป็นเรื่องที่ดีการใช้งาน CPU บนโฮสต์ทางกายภาพอาจต่ำกว่า 20% ความล่าช้าในการจัดเก็บข้อมูลต่ำมาก แต่ VMs ก็ยังคงซบเซาอยู่มาก

สิ่งที่เกิดขึ้นในสถานการณ์นี้คือ CPU Ready มีคิวที่สร้างขึ้นของ vCPU พร้อมที่จะกำหนด แต่ไม่มี pCPU ที่สามารถจัดตารางเวลาได้ hypervisor จะขัดขวางการตั้งเวลาและทำให้แฝงตัวสำหรับ VM แขก เป็นฆาตกรเงียบที่จนถึงช่วงไม่กี่ปีที่ผ่านมาไม่มีเครื่องมือใดที่จะตรวจจับได้ ใน Windows VM จะใช้เวลานานในการบูตแล้วเมื่อถึงที่สุดแล้วเมื่อคุณคลิกที่เมนูเริ่มต้นระบบจะใช้เวลาแสดงผลตลอดไป คุณอาจคลิกอีกครั้งว่าไม่ยอมรับการคลิกครั้งแรกของคุณและในที่สุดเมื่อคุณจับขึ้นคุณจะได้ดับเบิ้ลคลิก บน linux VM ของคุณอาจบูตขึ้นในโหมดอ่านอย่างเดียวหรือแม้แต่เปลี่ยนระบบไฟล์เพื่ออ่านโหมดเฉพาะในบางจุดในภายหลัง

เราจะต่อสู้กับ CPU Ready ได้อย่างไร? มีวิธีการบางอย่างที่สามารถช่วยได้ อันดับแรกคือการตรวจสอบเมตริก CPU Ready ใน VMware ไม่แนะนำให้ไปเกินกว่า 10% แต่ในประสบการณ์ส่วนตัวผู้ใช้จะเริ่มสังเกตเห็นว่ามีค่าใช้จ่ายสูงกว่า 5-7% ขึ้นอยู่กับชนิดของ VM และสิ่งที่กำลังทำงานอยู่

ด้านล่างผมจะใช้ตัวอย่างจาก VMware ESXi 5.5 เพื่อแสดง CPU Ready ใช้บรรทัดคำสั่ง esxtop ทำงาน กด c เพื่อดู CPU และคุณจะเห็นคอลัมน์ % RDY สำหรับ CPU Ready คุณสามารถกดทุน V สำหรับ VM View เท่านั้น

ที่นี่คุณจะเห็นว่า% RDY ค่อนข้างสูงสำหรับสภาพแวดล้อมที่ไม่ได้ใช้อย่างเป็นธรรม ในกรณีนี้ ESXi 5.5 ของฉันใช้ VM ทดสอบที่ด้านบนของ VMware Fusion (Mac hypervisor) ดังนั้นจึงคาดว่าจะเป็นบิตที่ระดับไฮเอนด์เนื่องจากเราใช้งาน VM บน Hypervisor บน Hypervisor อื่น

ในไคลเอ็นต์ vSphere คุณสามารถดึง VM เฉพาะขึ้นและคลิกที่แท็บประสิทธิภาพ จากนั้นคลิกที่ตัวเลือกแผนภูมิ

ภายในตัวเลือกแผนภูมิเลือกซีพียูเรียลไทม์ (หากคุณมี vCenter คุณอาจมีตัวเลือกการจับเวลาอื่นนอกเหนือจากเรียลไทม์) จากที่นั่นใน Counters เลือก Ready คุณอาจต้องยกเลิกการเลือกตัวนับอื่นเนื่องจากมุมมองจะอนุญาตเฉพาะสองประเภทข้อมูลในช่วงเวลาใดก็ได้

คุณจะทราบว่าค่านี้เป็นสรุปพร้อมกับเปอร์เซ็นต์ นี่เป็นลิงก์ไปยังบทความ VMware KB เกี่ยวกับวิธีแปลงเมตริกสรุปเป็นเปอร์เซ็นต์ - https://kb.vmware.com/kb/2002181

เมื่อซื้อฮาร์ดแวร์แกนอื่น ๆ จะช่วยลดผลกระทบของ CPU Ready Hyperthreading ช่วยด้วยเช่นกัน แม้ว่า Hyperthreading จะไม่มีแกนที่สองเต็มรูปแบบสำหรับแต่ละแกนหลัก แต่ก็มักจะเพียงพอที่จะกำหนดเวลา vCPU ให้กับ pCPU และช่วยบรรเทาปัญหาได้ แม้ว่า hypervisors กำลังจะย้ายออกจาก vCPU ไปเป็น pCPU ratio คำแนะนำคุณสามารถทำได้ดีในสภาพแวดล้อมที่ใช้ปานกลางด้วยอัตราส่วน 4: 1 และไปจากที่นั่น ขณะที่คุณเริ่มโหลด VM ให้ดูที่เวลาแฝงของ CPU, CPU Ready และความรู้สึกโดยรวมและประสิทธิภาพ หากคุณมี VMs การกดทับที่หนักหน่วงคุณอาจต้องการแยกพวกเขาลงในกลุ่มอื่น ๆ และใช้อัตราส่วนที่ต่ำกว่าและให้แสงสว่าง ในทางกลับกันสำหรับ VMs ที่ประสิทธิภาพไม่สำคัญและเป็นไรสำหรับพวกเขาทำงานอืดคุณสามารถสมัครสมาชิกได้มากขึ้น

การปรับขนาด VM ให้เหมาะสมเป็นอีกเครื่องมือหนึ่งที่เหมาะสำหรับการต่อสู้กับ CPU Ready ผู้ขายหลายรายแนะนำข้อกำหนดที่ดีกว่าสิ่งที่ VM อาจต้องการจริง ซีพียูและคอร์ตามเนื้อผ้ามากขึ้น = มีกำลังมากขึ้น ปัญหาในสภาพแวดล้อมเสมือนคือ hypervisor ต้องกำหนดเวลา vCPU ทั้งหมดให้กับ pCPU ที่คร่าวคราวเดียวกันและการล็อก pCPU อาจเป็นปัญหาได้ หากคุณมี vCPU VM 8 เครื่องคุณต้องล็อก 8 pCPU เพื่อให้สามารถกำหนดเวลาได้พร้อม ๆ กัน หาก vCPU VM ของคุณใช้เวลาเพียง 10% ของ vCPUs ทั้งหมดในช่วงเวลาใด ๆ คุณจะสามารถนำ vCPU ไปนับจาก 2 หรือ 4 ได้ดีกว่าโดยใช้ VM ที่ 50-80% CPU ที่มี vCPUs น้อยกว่า 10% ที่ vCPU เพิ่มเติม ปัญหานี้เป็นส่วนหนึ่งเนื่องจากระบบจัดตารางเวลาของซีพียูของระบบปฏิบัติการได้รับการออกแบบเพื่อใช้แกนให้มากที่สุดเท่าที่จะเป็นไปได้ในขณะที่หากได้รับการฝึกอบรมเพื่อให้มีแกนสูงสุดก่อนที่จะใช้งานมากขึ้นอาจเป็นปัญหาที่น้อยลง VM ที่มีขนาดใหญ่อาจทำงานได้ดี แต่อาจเป็นเพื่อนบ้านที่มีเสียงดังสำหรับเครื่องอื่น ๆ ดังนั้นจึงมักเป็นกระบวนการที่คุณต้องใช้ VM ทั้งหมดในคลัสเตอร์เพื่อให้มีขนาดเหมาะสมเพื่อให้ได้ผลการปฏิบัติงานที่ดีขึ้น

หลายครั้งที่คุณใช้ CPU Ready และเริ่มต้นการปรับขนาดของ VMs ได้ง่ายหรืออัพเกรดเป็นโปรเซสเซอร์ที่มีแกนมากขึ้น ถ้าคุณอยู่ในสถานการณ์เช่นนี้การเพิ่มโฮสต์มากขึ้นในคลัสเตอร์ของคุณจะช่วยในการกระจายโหลดข้ามโฮสต์ได้มากขึ้น ถ้าคุณมีโฮสต์ที่มีแกนประมวลผลมากกว่าโปรเซสเซอร์อื่น ๆ การช่วยให้ VMs vCPU สูงถึงโฮสต์หลักเหล่านี้สามารถช่วยได้เช่นกัน คุณต้องการตรวจสอบให้แน่ใจว่าโฮสต์ทางกายภาพของคุณมีจำนวนแกนเท่ากันถ้ามีจำนวนไม่น้อยกว่า VM มิฉะนั้นจะช้ามาก / ยากที่จะกำหนดเวลาส่วนที่เกินจาก vCPU ให้เป็น pCPU เนื่องจากต้องมีการล็อคที่คร่าวๆในเวลาเดียวกัน .

ในที่สุด hypervisor ของคุณอาจสนับสนุนการจองและข้อ จำกัด ใน VM บางครั้งวิทยานิพนธ์ได้รับการตั้งค่าโดยบังเอิญ การตั้งค่าที่ก้าวร้าวเหล่านี้อาจทำให้ซีพียูพร้อมใช้งานได้หากทรัพยากรพื้นฐานมีพร้อมใช้งาน โดยปกติจะเป็นการดีที่สุดที่จะใช้การจองและขีด จำกัด เท่าที่จำเป็นและเฉพาะเมื่อจำเป็นอย่างยิ่งเท่านั้น ส่วนใหญ่กลุ่มที่มีขนาดเหมาะสมจะปรับสมดุลทรัพยากรได้อย่างเหมาะสมและสิ่งเหล่านี้มักไม่จำเป็น

สรุปได้ว่าการป้องกันที่ดีที่สุดจาก CPU Ready คือการรู้ว่ามันมีอยู่แล้วและจะตรวจสอบได้อย่างไร จากนั้นคุณสามารถกำหนดขั้นตอนการลดผลกระทบที่ดีที่สุดสำหรับสภาพแวดล้อมของคุณได้ตามขั้นตอนข้างต้น ส่วนใหญ่ข้อมูลในบทความนี้ใช้กับ hypervisor ใด ๆ แม้ว่าภาพหน้าจอและแผนภูมิจะใช้เฉพาะกับ VMware

PRO TIP: หากปัญหาเกิดขึ้นกับคอมพิวเตอร์หรือแล็ปท็อป / โน้ตบุ๊คคุณควรลองใช้ซอฟต์แวร์ Reimage Plus ซึ่งสามารถสแกนที่เก็บข้อมูลและแทนที่ไฟล์ที่เสียหายได้ วิธีนี้ใช้ได้ผลในกรณีส่วนใหญ่เนื่องจากปัญหาเกิดจากความเสียหายของระบบ คุณสามารถดาวน์โหลด Reimage Plus โดยคลิกที่นี่