CPU Ready เป็นสิ่งที่คุณอาจไม่คุ้นเคย ในความประทับใจแรกอาจฟังดูเหมือนเป็นเรื่องดี แต่น่าเสียดายที่ไม่ใช่ CPU Ready ทำให้สภาพแวดล้อมเสมือนจริงมานานกว่าที่เรารู้ว่ามันคืออะไร VMware กำหนดสิ่งนี้ว่า“ เปอร์เซ็นต์ของเวลาที่เครื่องเสมือนพร้อม แต่ไม่สามารถกำหนดเวลาให้ทำงานบน CPU จริงได้ เวลาที่พร้อมใช้งานของ CPU ขึ้นอยู่กับจำนวนเครื่องเสมือนบนโฮสต์และการโหลดของ CPU” Hyper-V เพิ่งเริ่มให้ตัวนับนี้ (Hyper-V Hypervisor Virtual processor CPU Wait time per dispatch) และไฮเปอร์ไวเซอร์อื่น ๆ อาจยังไม่ให้เมตริกนี้
เพื่อให้เข้าใจว่า CPU Ready คืออะไรเราจะต้องเข้าใจว่า Hypervisors กำหนดเวลา CPU เสมือน (vCPU) ให้กับ CPU ทางกายภาพ (pCPU) อย่างไร เมื่อต้องการเวลา vCPU ใน VM จำเป็นต้องกำหนดเวลา vCPU เทียบกับ pCPU เพื่อให้คำสั่ง / กระบวนการ / เธรดสามารถทำงานกับ pCPU ได้ ในโลกแห่งอุดมคติไม่มีความขัดแย้งด้านทรัพยากรหรือปัญหาคอขวดเมื่อสิ่งนี้จำเป็นต้องเกิดขึ้น เมื่อ vCPU VM ตัวเดียวต้องกำหนดเวลาเทียบกับ pCPU คอร์ pCPU จะพร้อมใช้งานและ CPU Ready มีน้อยมากในโลกแห่งอุดมคตินี้ สิ่งสำคัญคือต้องทราบว่า CPU Ready มีอยู่เสมอ แต่ในโลกอุดมคตินั้นมีน้อยมากและไม่มีใครสังเกตเห็น
ในโลกแห่งความเป็นจริงข้อดีอย่างหนึ่งของการจำลองเสมือนคือคุณสามารถเดิมพันได้ว่า VM จำนวนมากของคุณจะไม่ขัดขวาง vCPU ทั้งหมดในเวลาเดียวกันและหากเป็น VM ที่มีการใช้งานต่ำมากคุณอาจเดาได้ว่าคุณสามารถทำได้มากแค่ไหน โหลดโฮสต์ทางกายภาพของคุณตามการใช้งาน CPU และการใช้ RAM ในอดีตคำแนะนำให้มีอัตราส่วน 4 vCPU ถึง 1 pCPU หรือแม้กระทั่ง 10: 1 ขึ้นอยู่กับปริมาณงาน ตัวอย่างเช่นคุณอาจมีโปรเซสเซอร์ Quad Core ตัวเดียว แต่มี VM 4 ตัวพร้อม vCPU แต่ละตัวเพื่อให้คุณได้ 16 vCPU ถึง 4 pCPU หรือ 4: 1 สิ่งที่วิศวกรเริ่มมองเห็นก็คือสภาพแวดล้อมนั้นช้ามากและพวกเขาไม่สามารถหาสาเหตุได้ การใช้ RAM ดูดีการใช้งาน CPU บนโฮสต์ทางกายภาพอาจต่ำมากถึง 20% เวลาในการตอบสนองในการจัดเก็บต่ำมาก แต่ VMs ก็ซบเซาอย่างมาก
สิ่งที่เกิดขึ้นในสถานการณ์นี้คือ CPU Ready มีการสร้างคิวของ vCPU ที่พร้อมสำหรับการจัดกำหนดการ แต่ไม่มี pCPU ที่สามารถกำหนดเวลาได้ ไฮเปอร์ไวเซอร์จะหยุดการตั้งเวลาและทำให้เกิดเวลาแฝงสำหรับแขก VM มันเป็นฆาตกรเงียบที่จนถึงช่วงไม่กี่ปีที่ผ่านมาไม่มีเครื่องมือมากมายในการตรวจจับ ใน Windows VM จะใช้เวลาบูตตลอดไปจากนั้นเมื่อคุณคลิกที่เมนูเริ่มระบบจะใช้เวลาตลอดไป คุณอาจคลิกอีกครั้งโดยคิดว่ามันไม่ยอมรับคลิกแรกของคุณและในที่สุดคุณก็จะได้รับการคลิกสองครั้ง บน linux VM ของคุณอาจบูตเข้าสู่โหมดอ่านอย่างเดียวหรือแม้กระทั่งเปลี่ยนระบบไฟล์ให้เป็นโหมดอ่านอย่างเดียวในบางจุดในภายหลัง
แล้วเราจะต่อสู้กับ CPU Ready ได้อย่างไร? มีสองสามวิธีที่สามารถช่วยได้ อันดับแรกคือการตรวจสอบเมตริกที่รองรับ CPU ใน VMware ไม่แนะนำให้สูงกว่า 10% แต่จากประสบการณ์ส่วนตัวผู้ใช้เริ่มสังเกตเห็นสูงกว่า 5-7% ขึ้นอยู่กับประเภทของ VM และสิ่งที่กำลังทำงานอยู่
ด้านล่างนี้ฉันจะใช้ตัวอย่างบางส่วนจาก VMware ESXi 5.5 เพื่อแสดง CPU Ready ใช้บรรทัดคำสั่งเรียกใช้“ esxtop” กด 'c' เพื่อดู CPU และคุณจะเห็นคอลัมน์ ' % RDY ” สำหรับ CPU Ready คุณสามารถกดทุน ' V ” สำหรับมุมมอง VM เท่านั้น
ที่นี่คุณจะเห็นว่า% RDY ค่อนข้างสูงสำหรับสภาพแวดล้อมที่ไม่ได้ใช้งาน ในกรณีนี้ ESXi 5.5 ของฉันกำลังเรียกใช้ VM ทดสอบที่ด้านบนของ VMware Fusion (Mac hypervisor) ดังนั้นจึงคาดว่าจะอยู่ในระดับไฮเอนด์เล็กน้อยเนื่องจากเราใช้งาน VM บนไฮเปอร์ไวเซอร์บนไฮเปอร์ไวเซอร์อื่น
ในไคลเอ็นต์ vSphere คุณสามารถดึง VM เฉพาะขึ้นมาและคลิกที่แท็บประสิทธิภาพ จากนั้นคลิกที่ 'ตัวเลือกแผนภูมิ'
ภายในตัวเลือกแผนภูมิให้เลือก CPU แบบเรียลไทม์ (หากคุณมี vCenter คุณอาจมีตัวเลือกเวลาอื่นที่ไม่ใช่เรียลไทม์) จากนั้นในเคาน์เตอร์ให้เลือก“ พร้อม” คุณอาจต้องยกเลิกการเลือกตัวนับอื่นเนื่องจากข้อมูลพร็อพเพอร์ตี้อนุญาตให้ใช้ข้อมูลสองประเภทในช่วงเวลาใดเวลาหนึ่งเท่านั้น
คุณจะสังเกตได้ว่าค่านี้เป็นการสรุปพร้อมเทียบกับเปอร์เซ็นต์ นี่คือลิงก์ไปยังบทความ VMware KB เกี่ยวกับวิธีการแปลงเมตริกสรุปเป็นเปอร์เซ็นต์ - https://kb.vmware.com/kb/2002181
เมื่อซื้อฮาร์ดแวร์คอร์ที่มากขึ้นจะช่วยลดผลกระทบของ CPU Ready Hyperthreading ก็ช่วยได้เช่นกัน แม้ว่า Hyperthreading จะไม่ได้จัดเตรียมคอร์หลักที่สองเต็มรูปแบบสำหรับคอร์หลักแต่ละคอร์ แต่ก็เพียงพอที่จะอนุญาตให้กำหนดเวลา vCPU ไปยัง pCPU และช่วยบรรเทาปัญหาได้ แม้ว่าไฮเปอร์ไวเซอร์จะเริ่มย้ายออกจากข้อเสนอแนะอัตราส่วน vCPU เป็น pCPU แต่โดยปกติคุณสามารถทำได้ดีในสภาพแวดล้อมที่ใช้งานปานกลางด้วย 4: 1 และไปจากที่นั่น เมื่อคุณเริ่มโหลด VM ให้ดูที่เวลาแฝงของ CPU CPU Ready และความรู้สึกและประสิทธิภาพโดยรวม หากคุณมี VM ที่มีการกดปุ่มมากคุณอาจต้องการแยกพวกมันไปยังคลัสเตอร์อื่น ๆ และใช้อัตราส่วนที่ต่ำกว่าและทำให้เบา ในทางกลับกันสำหรับ VM ที่ประสิทธิภาพไม่ใช่สิ่งสำคัญและมันก็โอเคสำหรับพวกเขาที่จะทำงานเฉื่อยชาคุณสามารถสมัครสมาชิกได้สูงกว่ามาก
การปรับขนาด VM ให้เหมาะสมเป็นเครื่องมือสำคัญในการต่อสู้กับ CPU Ready ผู้ขายหลายรายแนะนำข้อกำหนดเฉพาะเกี่ยวกับสิ่งที่ VM อาจต้องการจริงๆ ซีพียูตามเนื้อผ้าและคอร์ที่มากขึ้น = พลังที่มากขึ้น ปัญหาในสภาพแวดล้อมเสมือนคือไฮเปอร์ไวเซอร์ต้องกำหนดเวลา vCPU ทั้งหมดไปยัง pCPU ในเวลาเดียวกันโดยประมาณและการล็อก pCPU อาจเป็นปัญหาได้ หากคุณมี 8 vCPU VM คุณต้องล็อก 8 pCPU เพื่อให้สามารถกำหนดเวลาได้ในเวลาเดียวกัน หาก vCPU VM ของคุณใช้เพียง 10% ของ vCPU ทั้งหมดในช่วงเวลาใดเวลาหนึ่งคุณควรนำ vCPU นับถอยหลังเป็น 2 หรือ 4 จะดีกว่าถ้ารัน VM ที่ CPU 50-80% โดยมี vCPU น้อยกว่า 10% ที่ vCPU เพิ่มเติม ปัญหานี้ส่วนหนึ่งเป็นเพราะตัวกำหนดตารางเวลา CPU ของระบบปฏิบัติการได้รับการออกแบบมาเพื่อใช้คอร์ให้มากที่สุดเท่าที่จะเป็นไปได้ในขณะที่หากได้รับการฝึกฝนให้ใช้คอร์สูงสุดก่อนที่จะใช้งานมากขึ้นอาจเป็นปัญหาน้อยกว่า VM ที่มีขนาดใหญ่เกินไปอาจทำงานได้ดี แต่อาจเป็น 'เพื่อนบ้านที่มีเสียงดัง' สำหรับ VM อื่น ๆ ดังนั้นจึงเป็นกระบวนการที่คุณต้องดำเนินการผ่าน VM ทั้งหมดในคลัสเตอร์ให้มี 'ขนาดที่เหมาะสม' เพื่อดูประสิทธิภาพที่เพิ่มขึ้น
หลายครั้งที่คุณใช้ CPU Ready และเป็นเรื่องยากที่จะเริ่มปรับขนาด VMs ให้ถูกต้องหรืออัปเกรดเป็นโปรเซสเซอร์ที่มีคอร์มากขึ้น หากคุณอยู่ในสถานการณ์นี้การเพิ่มโฮสต์ในคลัสเตอร์ของคุณสามารถช่วยได้เพื่อกระจายโหลดไปยังโฮสต์อื่น ๆ หากคุณมีโฮสต์ที่มีคอร์ / ตัวประมวลผลมากกว่าโฮสต์อื่น ๆ การตรึง vCPU VM ที่สูงไว้กับโฮสต์หลักที่สูงกว่าเหล่านี้ก็สามารถช่วยได้เช่นกัน คุณต้องการตรวจสอบให้แน่ใจว่าโฮสต์ทางกายภาพของคุณมีจำนวนคอร์อย่างน้อยเท่ากันหากไม่เกิน VM มิฉะนั้นจะช้า / ยากมากที่จะกำหนดเวลา vCPU ส่วนเกินไปยัง pCPU เนื่องจากต้องล็อกในเวลาเดียวกันโดยประมาณ .
สุดท้ายไฮเปอร์ไวเซอร์ของคุณอาจรองรับการจองและขีด จำกัด บน VM บางครั้งวิทยานิพนธ์ก็เกิดขึ้นโดยบังเอิญ การตั้งค่าที่ก้าวร้าวในสิ่งเหล่านี้อาจทำให้ CPU พร้อมเมื่อในความเป็นจริงทรัพยากรพื้นฐานพร้อมใช้งาน โดยปกติควรใช้การจองและ จำกัด เท่าที่จำเป็นและเมื่อจำเป็นจริงๆเท่านั้น โดยส่วนใหญ่คลัสเตอร์ที่มีขนาดเหมาะสมจะทำให้ทรัพยากรสมดุลอย่างเหมาะสมและโดยทั่วไปแล้วไม่จำเป็น
โดยสรุปการป้องกัน CPU Ready ที่ดีที่สุดคือการรู้ว่ามีอยู่จริงและจะตรวจสอบได้อย่างไร จากนั้นคุณสามารถกำหนดขั้นตอนการลดผลกระทบที่ดีที่สุดสำหรับสภาพแวดล้อมของคุณอย่างเป็นระบบตามที่ระบุข้างต้น โดยส่วนใหญ่ข้อมูลในบทความนี้จะนำไปใช้กับไฮเปอร์ไวเซอร์ทุกประเภทแม้ว่าภาพหน้าจอและแผนภูมิจะใช้กับ VMware โดยเฉพาะ
อ่าน 5 นาที
