สวัสดี! ฉันอยากจะบอกคุณด้วยคำพูดง่ายๆ เกี่ยวกับกลไกของการขโมยภายในเครื่องเสมือน และสิ่งประดิษฐ์ที่ไม่ชัดเจนบางอย่างที่เราพบในระหว่างการค้นคว้า ซึ่งฉันต้องเจาะลึกในฐานะผู้อำนวยการด้านเทคนิคของแพลตฟอร์มคลาวด์ . แพลตฟอร์มทำงานบน KVM
เวลาขโมย CPU คือช่วงเวลาที่เครื่องเสมือนไม่ได้รับทรัพยากรตัวประมวลผลสำหรับการดำเนินการ เวลานี้นับเฉพาะในระบบปฏิบัติการของแขกในสภาพแวดล้อมการจำลองเสมือนเท่านั้น เหตุผลที่ทรัพยากรที่ได้รับการจัดสรรมากที่สุดเหล่านี้ไปในชีวิตนั้นมีความคลุมเครือมาก แต่เราตัดสินใจที่จะคิดออก และได้ทำการทดลองหลายครั้งด้วย ไม่ใช่ว่าตอนนี้เรารู้ทุกอย่างเกี่ยวกับการขโมยแล้ว แต่เราจะบอกสิ่งที่น่าสนใจให้คุณฟังตอนนี้
1. ขโมยคืออะไร
ดังนั้นการขโมยจึงเป็นตัวชี้วัดที่บ่งชี้ว่าไม่มีเวลาประมวลผลสำหรับกระบวนการภายในเครื่องเสมือน ตามที่อธิบายไว้ Stealth คือช่วงเวลาที่ไฮเปอร์ไวเซอร์ดำเนินการกระบวนการอื่นๆ บนระบบปฏิบัติการโฮสต์ แม้ว่าไฮเปอร์ไวเซอร์จะจัดคิวกระบวนการเครื่องเสมือนเพื่อดำเนินการก็ตาม นั่นคือ การขโมยจะถูกคำนวณเป็นผลต่างระหว่างเวลาที่กระบวนการพร้อมที่จะดำเนินการกับเวลาที่กระบวนการได้รับการจัดสรรเวลาของตัวประมวลผล
เคอร์เนลเครื่องเสมือนได้รับเมตริกการขโมยจากไฮเปอร์ไวเซอร์ ในเวลาเดียวกัน ไฮเปอร์ไวเซอร์ไม่ได้ระบุอย่างชัดเจนว่ากระบวนการอื่นใดที่กำลังทำงานอยู่ เพียงแต่บอกว่า “ในขณะที่ฉันยุ่ง ฉันไม่สามารถให้เวลาคุณได้” บน KVM มีการเพิ่มการรองรับการคำนวณการขโมยเข้าไปแล้ว . มีสองประเด็นสำคัญที่นี่:
- เครื่องเสมือนเรียนรู้เกี่ยวกับการขโมยจากไฮเปอร์ไวเซอร์ นั่นคือจากมุมมองของการสูญเสียสำหรับกระบวนการบนเครื่องเสมือนนี่เป็นการวัดทางอ้อมที่อาจเกิดการบิดเบือนต่างๆ
- ไฮเปอร์ไวเซอร์ไม่แชร์ข้อมูลกับเครื่องเสมือนว่ากำลังทำอะไรอยู่ - สิ่งสำคัญคือมันไม่ทุ่มเทเวลาให้กับมัน ด้วยเหตุนี้ เครื่องเสมือนจึงไม่สามารถตรวจจับการบิดเบือนในตัวบ่งชี้การขโมยได้ ซึ่งสามารถประเมินได้ตามลักษณะของกระบวนการที่แข่งขันกัน
2. สิ่งที่ส่งผลต่อการขโมย
2.1. การคำนวณการขโมย
โดยพื้นฐานแล้ว การขโมยจะถูกคำนวณโดยประมาณเท่ากับเวลาการใช้งาน CPU ปกติ ไม่มีข้อมูลมากนักเกี่ยวกับวิธีการพิจารณาการรีไซเคิล อาจเป็นเพราะคนส่วนใหญ่มองว่าคำถามนี้ชัดเจน แต่ก็มีข้อผิดพลาดอยู่ที่นี่เช่นกัน คุณสามารถอ่านเพื่อทำความคุ้นเคยกับกระบวนการนี้ : คุณจะได้เรียนรู้เกี่ยวกับความแตกต่างมากมายเมื่อคำนวณการใช้งานและเกี่ยวกับสถานการณ์ที่การคำนวณนี้จะผิดพลาดด้วยเหตุผลดังต่อไปนี้:
- โปรเซสเซอร์ร้อนเกินไป ส่งผลให้รอบการข้ามไป
- เปิด/ปิดการใช้งาน Turbo Boost ซึ่งจะเปลี่ยนความถี่สัญญาณนาฬิกาของโปรเซสเซอร์
- การเปลี่ยนแปลงความยาวของส่วนแบ่งเวลาที่เกิดขึ้นเมื่อใช้เทคโนโลยีประหยัดพลังงานของโปรเซสเซอร์ เช่น SpeedStep
- ปัญหาในการคำนวณค่าเฉลี่ย: การประมาณการใช้งานหนึ่งนาทีที่ 80% สามารถซ่อนการเพิ่มขึ้นในระยะสั้นที่ 100%
- การหมุนล็อคทำให้โปรเซสเซอร์ถูกเรียกคืน แต่กระบวนการของผู้ใช้ไม่เห็นความคืบหน้าใดๆ ในการดำเนินการ ผลที่ได้คือ การใช้งานตัวประมวลผลที่คำนวณได้โดยกระบวนการจะเป็นหนึ่งร้อยเปอร์เซ็นต์ แม้ว่ากระบวนการจะไม่ใช้เวลาตัวประมวลผลทางกายภาพก็ตาม
ฉันไม่พบบทความที่อธิบายการคำนวณการขโมยที่คล้ายกัน (ถ้าคุณรู้ แบ่งปันในความคิดเห็น) แต่เมื่อพิจารณาจากซอร์สโค้ดแล้ว กลไกการคำนวณก็เหมือนกับการรีไซเคิล เพียงเพิ่มตัวนับอื่นในเคอร์เนลโดยตรงสำหรับกระบวนการ KVM (กระบวนการเครื่องเสมือน) ซึ่งจะนับระยะเวลาของกระบวนการ KVM ที่รอเวลา CPU ตัวนับใช้ข้อมูลเกี่ยวกับโปรเซสเซอร์จากข้อกำหนดและตรวจสอบว่าเห็บทั้งหมดถูกใช้โดยกระบวนการเครื่องเสมือนหรือไม่ หากเป็นเช่นนั้น เราจะถือว่าโปรเซสเซอร์นั้นใช้งานเฉพาะกับกระบวนการเครื่องเสมือนเท่านั้น มิฉะนั้น เราจะแจ้งว่าโปรเซสเซอร์กำลังทำอย่างอื่น ขโมยปรากฏขึ้น
กระบวนการนับขโมยอาจประสบปัญหาเช่นเดียวกับการนับการรีไซเคิลตามปกติ ไม่ต้องบอกว่าปัญหาดังกล่าวเกิดขึ้นบ่อยแต่กลับดูท้อใจ
2.2. ประเภทของการจำลองเสมือนบน KVM
พูดอย่างกว้าง ๆ มีการจำลองเสมือนสามประเภท ซึ่ง KVM รองรับทั้งหมด กลไกของการขโมยอาจขึ้นอยู่กับประเภทของการจำลองเสมือน
ออกอากาศ. ในกรณีนี้ การทำงานของระบบปฏิบัติการเครื่องเสมือนกับอุปกรณ์ไฮเปอร์ไวเซอร์ทางกายภาพจะเกิดขึ้นดังนี้:
- ระบบปฏิบัติการเกสต์ส่งคำสั่งไปยังอุปกรณ์เกสต์
- ไดรเวอร์อุปกรณ์เกสต์ได้รับคำสั่ง สร้างคำขอสำหรับ BIOS ของอุปกรณ์ และส่งไปยังไฮเปอร์ไวเซอร์
- กระบวนการไฮเปอร์ไวเซอร์จะแปลคำสั่งเป็นคำสั่งสำหรับอุปกรณ์ฟิสิคัล ทำให้มีความปลอดภัยมากขึ้นเหนือสิ่งอื่นใด
- ไดรเวอร์อุปกรณ์ฟิสิคัลยอมรับคำสั่งที่แก้ไขแล้วส่งไปยังอุปกรณ์ฟิสิคัลนั้นเอง
- ผลลัพธ์ของการดำเนินการคำสั่งจะกลับไปในเส้นทางเดียวกัน
ข้อดีของการแปลคือช่วยให้คุณสามารถจำลองอุปกรณ์ใด ๆ และไม่จำเป็นต้องเตรียมเคอร์เนลระบบปฏิบัติการเป็นพิเศษ แต่ก่อนอื่นคุณต้องจ่ายเงินอย่างรวดเร็ว
การจำลองเสมือนของฮาร์ดแวร์. ในกรณีนี้ อุปกรณ์ในระดับฮาร์ดแวร์จะเข้าใจคำสั่งจากระบบปฏิบัติการ นี่เป็นวิธีที่เร็วและดีที่สุด แต่น่าเสียดายที่อุปกรณ์ทางกายภาพ ไฮเปอร์ไวเซอร์ และระบบปฏิบัติการของแขกไม่รองรับทั้งหมด ปัจจุบันอุปกรณ์หลักที่รองรับการจำลองเสมือนสำหรับฮาร์ดแวร์คือโปรเซสเซอร์
พาราเวอร์ชวลไลเซชัน. ตัวเลือกที่พบบ่อยที่สุดสำหรับการจำลองเสมือนของอุปกรณ์บน KVM และโดยทั่วไปคือโหมดการจำลองเสมือนที่พบมากที่สุดสำหรับระบบปฏิบัติการของแขก ลักษณะเฉพาะของมันคือการทำงานกับระบบย่อยไฮเปอร์ไวเซอร์บางระบบ (เช่นกับเครือข่ายหรือดิสก์สแต็ก) หรือการจัดสรรเพจหน่วยความจำเกิดขึ้นโดยใช้ไฮเปอร์ไวเซอร์ API โดยไม่ต้องแปลคำสั่งระดับต่ำ ข้อเสียของวิธีการจำลองเสมือนนี้คือต้องแก้ไขเคอร์เนลของระบบปฏิบัติการเกสต์เพื่อให้สามารถสื่อสารกับไฮเปอร์ไวเซอร์โดยใช้ API นี้ แต่โดยปกติจะแก้ไขได้โดยการติดตั้งไดรเวอร์พิเศษบนระบบปฏิบัติการของแขก ใน KVM API นี้เรียกว่า .
เมื่อเปรียบเทียบกับการแพร่ภาพ Paravirtualization เส้นทางไปยังอุปกรณ์ทางกายภาพจะลดลงอย่างมากโดยการส่งคำสั่งโดยตรงจากเครื่องเสมือนไปยังกระบวนการไฮเปอร์ไวเซอร์บนโฮสต์ สิ่งนี้ช่วยให้คุณเร่งความเร็วการดำเนินการตามคำสั่งทั้งหมดภายในเครื่องเสมือนได้ ใน KVM สิ่งนี้ทำได้โดย virtio API ซึ่งใช้งานได้กับอุปกรณ์บางชนิดเท่านั้น เช่น เครือข่ายหรือดิสก์อะแดปเตอร์ นี่คือสาเหตุว่าทำไมจึงมีการติดตั้งไดรเวอร์ virtio ภายในเครื่องเสมือน
ข้อเสียของการเร่งความเร็วนี้คือ กระบวนการทั้งหมดที่ทำงานภายในเครื่องเสมือนนั้นอาจยังคงอยู่ภายในนั้นไม่ได้ สิ่งนี้จะสร้างเอฟเฟกต์พิเศษบางอย่างที่อาจส่งผลให้เกิดการวางไข่เมื่อขโมยได้ ฉันแนะนำให้เริ่มศึกษารายละเอียดของปัญหานี้ด้วย .
2.3. กำหนดการ "ยุติธรรม"
เครื่องเสมือนบนไฮเปอร์ไวเซอร์นั้นเป็นกระบวนการปกติที่ปฏิบัติตามกฎการกำหนดตารางเวลา (การกระจายทรัพยากรระหว่างกระบวนการ) ในเคอร์เนล Linux ดังนั้นเรามาดูกันดีกว่า
Linux ใช้สิ่งที่เรียกว่า CFS หรือ Completely Fair Scheduler ซึ่งกลายเป็นตัวกำหนดตารางเวลาเริ่มต้นตั้งแต่เคอร์เนล 2.6.23 เพื่อทำความเข้าใจอัลกอริธึมนี้ คุณสามารถอ่านสถาปัตยกรรมเคอร์เนล Linux หรือซอร์สโค้ดได้ สาระสำคัญของ CFS คือการกระจายเวลาของโปรเซสเซอร์ระหว่างกระบวนการต่างๆ ขึ้นอยู่กับระยะเวลาของการดำเนินการ ยิ่งกระบวนการต้องการเวลา CPU มากเท่าใด เวลา CPU ก็จะยิ่งได้รับน้อยลงเท่านั้น สิ่งนี้ทำให้แน่ใจได้ว่ากระบวนการทั้งหมดได้รับการดำเนินการ "อย่างยุติธรรม" เพื่อให้กระบวนการหนึ่งไม่ครอบครองโปรเซสเซอร์ทั้งหมดตลอดเวลา และกระบวนการอื่นๆ ก็สามารถดำเนินการได้เช่นกัน
บางครั้งกระบวนทัศน์นี้นำไปสู่สิ่งประดิษฐ์ที่น่าสนใจ ผู้ใช้ Linux เป็นเวลานานอาจจำการค้างของโปรแกรมแก้ไขข้อความทั่วไปบนเดสก์ท็อปได้ในขณะที่ใช้งานแอปพลิเคชันที่ใช้ทรัพยากรจำนวนมาก เช่น คอมไพเลอร์ สิ่งนี้เกิดขึ้นเนื่องจากงานที่ไม่ใช้ทรัพยากรมากในแอปพลิเคชันเดสก์ท็อปต้องแข่งขันกับงานที่ต้องใช้ทรัพยากรมาก เช่น คอมไพเลอร์ CFS คิดว่าสิ่งนี้ไม่ยุติธรรม ดังนั้นจึงหยุดโปรแกรมแก้ไขข้อความเป็นระยะๆ และปล่อยให้ตัวประมวลผลจัดการงานของคอมไพเลอร์ สิ่งนี้ได้รับการแก้ไขโดยใช้กลไก แต่คุณสมบัติอื่น ๆ มากมายของการกระจายเวลาประมวลผลระหว่างงานยังคงอยู่ จริงๆแล้วนี่ไม่ใช่เรื่องราวเกี่ยวกับความเลวร้ายของ CFS แต่เป็นความพยายามที่จะดึงความสนใจไปที่ความจริงที่ว่าการกระจายเวลาโปรเซสเซอร์ที่ "ยุติธรรม" ไม่ใช่งานที่ไม่สำคัญที่สุด
จุดสำคัญอีกประการหนึ่งในตัวกำหนดตารางเวลาคือการขอใบจอง นี่เป็นสิ่งจำเป็นเพื่อขจัดกระบวนการหัวเราะเยาะออกจากโปรเซสเซอร์และปล่อยให้ผู้อื่นทำงาน กระบวนการดีดออกเรียกว่าการสลับบริบท ในกรณีนี้ บริบททั้งหมดของงานจะถูกรักษาไว้: สถานะของสแต็ก การลงทะเบียน ฯลฯ หลังจากนั้นกระบวนการจะถูกส่งไปรอ และอีกกระบวนการหนึ่งจะเข้ามาแทนที่ นี่เป็นการดำเนินการที่มีราคาแพงสำหรับระบบปฏิบัติการและไม่ค่อยมีใครใช้ แต่ก็ไม่มีอะไรผิดปกติโดยเนื้อแท้ การสลับบริบทบ่อยครั้งอาจบ่งบอกถึงปัญหาในระบบปฏิบัติการ แต่โดยปกติแล้วจะเกิดขึ้นอย่างต่อเนื่องและไม่ได้ระบุถึงสิ่งใดโดยเฉพาะ
จำเป็นต้องมีเรื่องราวยาวเช่นนี้เพื่ออธิบายข้อเท็จจริงข้อหนึ่ง: ยิ่งกระบวนการพยายามใช้ทรัพยากรตัวประมวลผลในตัวกำหนดเวลา Linux ที่ซื่อสัตย์มากเท่าใด กระบวนการจะหยุดเร็วขึ้นเพื่อให้กระบวนการอื่นสามารถทำงานได้เช่นกัน ไม่ว่าสิ่งนี้จะถูกหรือไม่นั้นเป็นคำถามที่ซับซ้อนซึ่งสามารถแก้ไขได้แตกต่างกันภายใต้ภาระงานที่แตกต่างกัน จนกระทั่งเมื่อไม่นานมานี้ ใน Windows ตัวกำหนดตารางเวลามุ่งเน้นไปที่การประมวลผลลำดับความสำคัญของแอปพลิเคชันเดสก์ท็อป ซึ่งอาจทำให้กระบวนการในเบื้องหลังหยุดทำงาน Sun Solaris มีตัวกำหนดตารางเวลาที่แตกต่างกันห้าคลาส เมื่อเราเปิดตัวระบบเสมือนจริง เราได้เพิ่มอันที่หก เนื่องจากห้ารายการก่อนหน้านี้ทำงานได้ไม่เพียงพอกับการจำลองเสมือนของ Solaris Zones ฉันขอแนะนำให้เริ่มศึกษาปัญหานี้อย่างละเอียดด้วยหนังสือเช่น หรือ .
2.4. จะติดตามการขโมยได้อย่างไร?
การตรวจสอบการขโมยภายในเครื่องเสมือน เช่นเดียวกับตัววัดตัวประมวลผลอื่นๆ นั้นทำได้ง่าย: คุณสามารถใช้เครื่องมือตัววัดตัวประมวลผลใดก็ได้ สิ่งสำคัญคือเครื่องเสมือนอยู่บน Linux ด้วยเหตุผลบางประการ Windows จึงไม่ให้ข้อมูลนี้แก่ผู้ใช้ 🙁
ผลลัพธ์ของคำสั่งด้านบน: รายละเอียดของโหลดตัวประมวลผลในคอลัมน์ขวาสุด - ขโมย
ปัญหาเกิดขึ้นเมื่อพยายามรับข้อมูลนี้จากไฮเปอร์ไวเซอร์ คุณสามารถลองทำนายการขโมยบนเครื่องโฮสต์ได้ เช่น การใช้พารามิเตอร์ Load Average (LA) - ค่าเฉลี่ยของจำนวนกระบวนการที่รออยู่ในคิวการดำเนินการ วิธีการคำนวณพารามิเตอร์นี้ไม่ใช่เรื่องง่าย แต่โดยทั่วไปหาก LA ที่ทำให้เป็นมาตรฐานด้วยจำนวนเธรดตัวประมวลผลมากกว่า 1 แสดงว่าเซิร์ฟเวอร์ Linux มีบางสิ่งมากเกินไป
กระบวนการทั้งหมดนี้กำลังรออะไรอยู่? คำตอบที่ชัดเจนคือโปรเซสเซอร์ แต่คำตอบนั้นไม่ถูกต้องทั้งหมด เพราะบางครั้งโปรเซสเซอร์ก็ว่าง แต่ LA ก็ลดขนาดลง จดจำ . สิ่งเดียวกันนี้สามารถเกิดขึ้นได้กับดิสก์และอุปกรณ์อินพุต/เอาท์พุตอื่นๆ แต่ในความเป็นจริง กระบวนการสามารถรอการสิ้นสุดของการล็อกใดๆ ทั้งแบบฟิสิคัลที่เชื่อมโยงกับอุปกรณ์ I/O หรือแบบลอจิคัล เช่น mutex นอกจากนี้ยังรวมถึงการล็อกที่ระดับของฮาร์ดแวร์ (การตอบสนองเดียวกันจากดิสก์) หรือลอจิก (ที่เรียกว่าการล็อคแบบดั้งเดิมซึ่งรวมถึงเอนทิตีจำนวนมาก mutex Adaptive และ Spin เซมาฟอร์ ตัวแปรเงื่อนไข ล็อค rw ล็อค ipc ...)
คุณสมบัติอีกประการหนึ่งของ LA คือถือเป็นค่าเฉลี่ยของระบบปฏิบัติการ ตัวอย่างเช่น 100 กระบวนการแข่งขันกันสำหรับไฟล์เดียว จากนั้น LA=50 ค่าที่มากเช่นนี้ดูเหมือนจะบ่งชี้ว่าระบบปฏิบัติการไม่ดี แต่สำหรับโค้ดที่เขียนคดเคี้ยวอื่น ๆ นี่อาจเป็นสถานะปกติแม้ว่าจะมีเพียงข้อผิดพลาดเท่านั้นและกระบวนการอื่น ๆ ในระบบปฏิบัติการก็ไม่ได้รับผลกระทบ
เนื่องจากการเฉลี่ยนี้ (และภายในเวลาไม่น้อยกว่าหนึ่งนาที) การพิจารณาสิ่งใดสิ่งหนึ่งด้วยตัวบ่งชี้ LA จึงไม่ใช่งานที่คุ้มค่าที่สุด โดยให้ผลลัพธ์ที่ไม่แน่นอนในบางกรณี หากคุณพยายามคิดออก คุณจะพบว่าบทความในวิกิพีเดียและแหล่งข้อมูลอื่นๆ ที่มีอยู่อธิบายเฉพาะกรณีที่ง่ายที่สุด โดยไม่มีคำอธิบายที่ลึกซึ้งเกี่ยวกับกระบวนการ ฉันส่งทุกคนที่สนใจอีกครั้ง - ตามลิงค์ด้านล่าง ใครขี้เกียจเกินกว่าจะพูดภาษาอังกฤษ - .
3. เทคนิคพิเศษ
มาดูกรณีหลักๆ ของการขโมยที่เราพบกันดีกว่า ฉันจะบอกคุณว่าพวกเขาติดตามจากที่กล่าวมาทั้งหมดอย่างไร และเกี่ยวข้องกับตัวบ่งชี้บนไฮเปอร์ไวเซอร์อย่างไร
การรีไซเคิล. วิธีที่ง่ายที่สุดและพบบ่อยที่สุด: ไฮเปอร์ไวเซอร์ถูกนำมาใช้ซ้ำแล้ว แท้จริงแล้ว มีเครื่องเสมือนที่ทำงานอยู่จำนวนมาก การใช้โปรเซสเซอร์สูงภายในเครื่อง มีการแข่งขันสูง การใช้งาน LA มีมากกว่า 1 เครื่อง (ทำให้เป็นมาตรฐานโดยเธรดโปรเซสเซอร์) ทุกสิ่งภายในเครื่องเสมือนทั้งหมดช้าลง การขโมยที่ส่งจากไฮเปอร์ไวเซอร์ก็เพิ่มขึ้นเช่นกัน จำเป็นต้องกระจายโหลดใหม่หรือปิดใครบางคน โดยทั่วไปแล้วทุกอย่างมีเหตุผลและเข้าใจได้
Paravirtualization กับอินสแตนซ์เดี่ยว. มีเครื่องเสมือนเพียงเครื่องเดียวบนไฮเปอร์ไวเซอร์ โดยจะใช้ส่วนเล็ก ๆ แต่สร้างโหลด I/O ขนาดใหญ่ เช่น บนดิสก์ และจากที่ไหนสักแห่งที่มีขโมยเล็ก ๆ ปรากฏขึ้นมากถึง 10% (ดังแสดงจากการทดลองหลายครั้ง)
กรณีนี้น่าสนใจ การขโมยปรากฏขึ้นที่นี่อย่างแม่นยำเนื่องจากการบล็อกที่ระดับไดรเวอร์พาราเวอร์ชวลไลซ์ การขัดจังหวะจะถูกสร้างขึ้นภายในเครื่องเสมือน ประมวลผลโดยไดรเวอร์ และส่งไปยังไฮเปอร์ไวเซอร์ เนื่องจากการจัดการขัดจังหวะบนไฮเปอร์ไวเซอร์ สำหรับเครื่องเสมือน ดูเหมือนว่าคำขอที่ส่งไป จึงพร้อมสำหรับการดำเนินการและกำลังรอโปรเซสเซอร์ แต่จะไม่ได้รับเวลาของโปรเซสเซอร์ สาวเสมือนคิดว่าครั้งนี้ถูกขโมยไป
สิ่งนี้จะเกิดขึ้นในขณะที่บัฟเฟอร์ถูกส่งไป มันจะเข้าไปในพื้นที่เคอร์เนลของไฮเปอร์ไวเซอร์ และเราเริ่มรอมัน แม้ว่าจากมุมมองของเครื่องเสมือน เขาควรกลับมาทันที ดังนั้นตามอัลกอริธึมการคำนวณการขโมยครั้งนี้ถือว่าถูกขโมย เป็นไปได้มากว่าในสถานการณ์นี้ อาจมีกลไกอื่นๆ (เช่น การประมวลผลการเรียกระบบอื่นๆ) แต่กลไกเหล่านี้ไม่ควรแตกต่างกันมากนัก
ตัวกำหนดเวลาเทียบกับเครื่องเสมือนที่มีการโหลดสูง. เมื่อเครื่องเสมือนเครื่องหนึ่งประสบปัญหาการขโมยมากกว่าเครื่องอื่น นี่เป็นเพราะตัวกำหนดตารางเวลา ยิ่งกระบวนการโหลดโปรเซสเซอร์มากเท่าใด ตัวกำหนดเวลาก็จะเริ่มทำงานเร็วขึ้นเท่านั้น เพื่อให้กระบวนการอื่นๆ สามารถทำงานได้เช่นกัน หากเครื่องเสมือนกินน้อย ก็แทบจะมองไม่เห็นการขโมยเลย กระบวนการของมันนั่งและรอโดยสุจริต เราต้องให้เวลามันมากขึ้น หากเครื่องเสมือนสร้างภาระสูงสุดบนคอร์ทั้งหมด ก็มักจะถูกไล่ออกจากโปรเซสเซอร์ และพวกเขาพยายามไม่ให้เวลากับเครื่องมากนัก
จะแย่ยิ่งกว่านั้นอีกเมื่อกระบวนการภายในเครื่องเสมือนพยายามรับโปรเซสเซอร์มากขึ้น เนื่องจากไม่สามารถรับมือกับการประมวลผลข้อมูลได้ จากนั้นระบบปฏิบัติการบนไฮเปอร์ไวเซอร์จะให้เวลาโปรเซสเซอร์น้อยลงเนื่องจากการเพิ่มประสิทธิภาพโดยสุจริต กระบวนการนี้เกิดขึ้นเหมือนกับหิมะถล่ม และขโมยการกระโดดขึ้นไปบนท้องฟ้า แม้ว่าเครื่องเสมือนอื่นๆ แทบจะไม่สังเกตเห็นเลยก็ตาม และยิ่งมีคอร์มากเท่าไร เครื่องก็จะยิ่งแย่ลงเท่านั้น กล่าวโดยสรุป เครื่องเสมือนที่มีการโหลดสูงซึ่งมีคอร์จำนวนมากได้รับผลกระทบมากที่สุด
LA ต่ำแต่ก็มีขโมย. หาก LA มีค่าประมาณ 0,7 (นั่นคือ ไฮเปอร์ไวเซอร์ดูเหมือนว่าจะมีภาระงานน้อยเกินไป) แต่มีการตรวจพบการขโมยภายในเครื่องเสมือนแต่ละเครื่อง:
- ตัวเลือกที่มี paravirtualization อธิบายไว้ข้างต้นแล้ว เครื่องเสมือนสามารถรับเมตริกที่ระบุการขโมยได้ แม้ว่าไฮเปอร์ไวเซอร์จะดีก็ตาม จากผลการทดลองของเรา ตัวเลือกการขโมยนี้ไม่เกิน 10% และไม่ควรส่งผลกระทบอย่างมีนัยสำคัญต่อประสิทธิภาพของแอปพลิเคชันภายในเครื่องเสมือน
- พารามิเตอร์ LA ถูกคำนวณไม่ถูกต้อง แม่นยำยิ่งขึ้นในแต่ละช่วงเวลาจะมีการคำนวณอย่างถูกต้อง แต่เมื่อเฉลี่ยมากกว่าหนึ่งนาที กลับกลายเป็นว่าถูกประเมินต่ำไป ตัวอย่างเช่น หากเครื่องเสมือนหนึ่งเครื่องต่อสามของไฮเปอร์ไวเซอร์ใช้โปรเซสเซอร์ทั้งหมดเป็นเวลาครึ่งนาที ดังนั้น LA ต่อนาทีบนไฮเปอร์ไวเซอร์จะเท่ากับ 0,15 เครื่องเสมือนสี่เครื่องที่ทำงานพร้อมกันจะให้ 0,6 และความจริงที่ว่าเป็นเวลาครึ่งนาทีในแต่ละอันมีการขโมยแบบป่าที่ 25% ตามตัวบ่งชี้ LA ไม่สามารถดึงออกมาได้อีกต่อไป
- อีกครั้งเพราะคนจัดตารางเวลาตัดสินใจว่ามีคนกินมากเกินไปและปล่อยให้ใครบางคนรอ ในระหว่างนี้ ฉันจะเปลี่ยนบริบท จัดการกับการขัดจังหวะ และดูแลเรื่องสำคัญอื่นๆ ของระบบ เป็นผลให้เครื่องเสมือนบางเครื่องไม่เห็นปัญหาใดๆ ในขณะที่เครื่องอื่นๆ ประสบกับประสิทธิภาพการทำงานที่ลดลงอย่างมาก
4. การบิดเบือนอื่นๆ
มีเหตุผลอีกล้านประการในการบิดเบือนการส่งคืนเวลาโปรเซสเซอร์อย่างยุติธรรมบนเครื่องเสมือน ตัวอย่างเช่น ไฮเปอร์เธรดและ NUMA ทำให้เกิดความยุ่งยากในการคำนวณ พวกเขาสับสนอย่างสิ้นเชิงกับการเลือกเคอร์เนลสำหรับดำเนินการกระบวนการเนื่องจากตัวกำหนดเวลาใช้ค่าสัมประสิทธิ์ - น้ำหนักซึ่งทำให้การคำนวณยากยิ่งขึ้นเมื่อเปลี่ยนบริบท
มีการบิดเบือนเนื่องจากเทคโนโลยี เช่น เทอร์โบบูสต์ หรือในทางกลับกัน โหมดประหยัดพลังงาน ซึ่งเมื่อคำนวณการใช้งาน อาจเพิ่มหรือลดความถี่เทียม หรือแม้แต่ส่วนแบ่งเวลาบนเซิร์ฟเวอร์ได้ การเปิดใช้งาน Turbo Boost จะลดประสิทธิภาพของเธรดตัวประมวลผลตัวหนึ่งเนื่องจากการเพิ่มประสิทธิภาพของตัวประมวลผลตัวอื่น ในขณะนี้ ข้อมูลเกี่ยวกับความถี่ของโปรเซสเซอร์ปัจจุบันไม่ได้ถูกส่งไปยังเครื่องเสมือน และเชื่อว่ามีใครบางคนกำลังขโมยเวลา (เช่น ร้องขอ 2 GHz แต่ได้รับครึ่งหนึ่ง)
โดยทั่วไปอาจมีสาเหตุหลายประการที่ทำให้เกิดการบิดเบือน คุณอาจพบสิ่งอื่นในระบบใดระบบหนึ่ง เริ่มต้นด้วยหนังสือที่ฉันให้ลิงก์ด้านบนดีกว่า และดึงข้อมูลสถิติจากไฮเปอร์ไวเซอร์โดยใช้ยูทิลิตี้เช่น perf, sysdig, systemtap ซึ่ง .
5. บทสรุป
- การขโมยบางส่วนอาจเกิดขึ้นเนื่องจากพาราเวอร์ชวลไลเซชัน และถือเป็นเรื่องปกติ พวกเขาเขียนบนอินเทอร์เน็ตว่าค่านี้สามารถเป็น 5-10% ขึ้นอยู่กับแอปพลิเคชันภายในเครื่องเสมือนและโหลดที่ติดตั้งบนอุปกรณ์ทางกายภาพ สิ่งสำคัญคือต้องใส่ใจกับความรู้สึกของแอปพลิเคชันภายในเครื่องเสมือน
- อัตราส่วนของโหลดบนไฮเปอร์ไวเซอร์และการขโมยภายในเครื่องเสมือนไม่ได้เชื่อมโยงกันอย่างชัดเจนเสมอไป การประมาณค่าการขโมยทั้งสองอาจมีข้อผิดพลาดในสถานการณ์เฉพาะภายใต้โหลดที่แตกต่างกัน
- ผู้จัดกำหนดการมีทัศนคติที่ไม่ดีต่อกระบวนการที่ถามมาก เขาพยายามให้น้อยลงแก่ผู้ที่ขอมากขึ้น เครื่องเสมือนขนาดใหญ่นั้นชั่วร้าย
- การขโมยเพียงเล็กน้อยอาจเป็นบรรทัดฐานแม้ว่าจะไม่มี paravirtualization (โดยคำนึงถึงโหลดภายในเครื่องเสมือน ลักษณะของโหลดของเพื่อนบ้าน การกระจายโหลดข้ามเธรด และปัจจัยอื่น ๆ )
- หากคุณต้องการทราบว่ามีการขโมยในระบบใดระบบหนึ่ง คุณจะต้องสำรวจตัวเลือกต่างๆ รวบรวมหน่วยวัด วิเคราะห์อย่างรอบคอบ และคิดถึงวิธีกระจายโหลดอย่างเท่าเทียมกัน การเบี่ยงเบนไปจากกรณีใดๆ เป็นไปได้ ซึ่งต้องได้รับการยืนยันจากการทดลองหรือดูในเคอร์เนลดีบักเกอร์
ที่มา: will.com