ประสิทธิภาพดิสก์ KVM ต่ำอย่างไม่น่าเชื่อ (ไฟล์ดิสก์ qcow2 + virtio)

ฉันประสบปัญหาประสิทธิภาพการทำงานของดิสก์ร้ายแรงในขณะที่ตั้งค่าผู้เยี่ยมชม KVM ใช้ง่ายddทดสอบพาร์ติชันบนโฮสต์ที่ภาพ qcow2 อาศัยอยู่บน (อาร์เรย์ RAID มิเรอร์) เขียนที่มากกว่า120MB / sในขณะที่แขกของฉันได้รับการเขียนตั้งแต่0.5 ถึง 3MB / s

• แขกได้รับการกำหนดค่าด้วย CPU สองตัวและ RAM 4G และไม่ได้ทำงานอย่างอื่นอยู่ในขณะนี้ เป็นการติดตั้งขั้นต่ำที่สมบูรณ์แบบในขณะนี้
• time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000ผลการดำเนินงานมีการทดสอบโดยใช้
• แขกได้รับการกำหนดค่าให้ใช้ virtio แต่ไม่ปรากฏว่าสร้างความแตกต่างให้กับประสิทธิภาพ
• พาร์ติชันโฮสต์ถูกจัดตำแหน่งไว้ที่ 4kb (และประสิทธิภาพการทำงานดีบนโฮสต์แล้ว)
• การใช้แคชการเขียนกลับในดิสก์เพิ่มประสิทธิภาพการทำงานที่รายงานอย่างหนาแน่น แต่ฉันไม่ต้องการใช้ แม้จะไม่มีประสิทธิภาพก็ควรจะดีกว่านี้
• โฮสต์และแขกกำลังใช้งาน Ubuntu 12.04 LTS ซึ่งมาพร้อมกับ qemu-kvm 1.0 + noroms-0ubuntu13 และ libvirt 0.9.8-2ubuntu17.1
• โฮสต์ได้เปิดใช้งานตัวกำหนดตารางเวลา IO แล้วและแขกมี noop

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

อัปเดต 1

ทันใดนั้นเมื่อฉันกลับไปทดสอบในตอนนี้มันเป็น26.6 MB / s; นี่เป็นสิ่งที่ฉันคาดไว้มากกว่าด้วย / qcrow2 ฉันจะทิ้งคำถามไว้ในกรณีที่มีใครมีความคิดเกี่ยวกับสิ่งที่อาจเป็นปัญหา (และในกรณีที่มันกลับมาอย่างลึกลับอีกครั้ง)

อัปเดต 2

ฉันหยุดกังวลเกี่ยวกับประสิทธิภาพการทำงานของ qcow2 และเพิ่งตัดไปยัง LVM ด้านบนของ RAID1 ด้วยรูปภาพดิบยังคงใช้ virtio แต่การตั้งค่าแคช = 'none' และ io = 'native' บนดิสก์ไดรฟ์ ประสิทธิภาพการเขียนตอนนี้คือแอป 135MB / sโดยใช้การทดสอบขั้นพื้นฐานเดียวกันกับข้างต้นดังนั้นจึงไม่มีประเด็นที่จะทราบได้ว่าปัญหานี้เกิดขึ้นเมื่อใดที่สามารถแก้ไขได้อย่างง่ายดาย

ใช่ไฟล์ qcow2 ไม่ได้ออกแบบมาเพื่อประสิทธิภาพที่รวดเร็ว คุณจะได้รับโชคที่ดีขึ้นจากพาร์ติชั่นแบบดิบ

วิธีการบรรลุประสิทธิภาพสูงสุดด้วย QCOW2 :

qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts=on imageXYZ

สิ่งที่สำคัญที่สุดคือการจัดสรรล่วงหน้าซึ่งให้การสนับสนุนที่ดีตามนักพัฒนา qcow2 ใกล้เคียงกับ LVMแล้ว! โปรดทราบว่าโดยปกติจะเปิดใช้งานใน distros Linux (Fedora 25+) ที่ทันสมัย

นอกจากนี้คุณสามารถให้แคชที่ไม่ปลอดภัยหากนี่ไม่ใช่อินสแตนซ์ที่ใช้ในการผลิต (เป็นอันตรายและไม่แนะนำให้ใช้สำหรับการทดสอบเท่านั้น):

<driver name='qemu' cache='unsafe' />

ผู้ใช้บางคนรายงานว่าการกำหนดค่านี้ชนะการกำหนดค่า LVM / ไม่ปลอดภัยในบางการทดสอบ

สำหรับพารามิเตอร์ทั้งหมดเหล่านี้จำเป็นต้องมีQEMU 1.5+ ล่าสุด ! อีกครั้ง distros ทันสมัยส่วนใหญ่มีสิ่งเหล่านี้

ฉันได้ผลลัพธ์ที่ยอดเยี่ยมสำหรับภาพ qcow2 ด้วยการตั้งค่านี้:

<driver name='qemu' type='raw' cache='none' io='native'/>

ซึ่งปิดใช้งานแคชของผู้เยี่ยมชมและเปิดใช้งาน AIO (Asynchronous IO) การรันddคำสั่งของคุณทำให้ฉันมีโฮสต์ที่ 177MB / s และ 155MB / s กับแขก ภาพจะถูกวางในระดับเสียงเดียวกับที่โฮสต์ทำการทดสอบ

qemu-kvmรุ่นของฉันคือ1.0+noroms-0ubuntu14.8และเคอร์เนล3.2.0-41-genericจากสต็อก Ubuntu 12.04.2 LTS

หากคุณใช้ vms ด้วยคำสั่งเดียวสำหรับอาร์กิวเมนต์ที่คุณสามารถใช้ได้

kvm -drive file = / path_to.qcow2, if = virtio, cache = off <... >

มันทำให้ฉันจาก 3MB / s ถึง 70MB / s

สำหรับเวอร์ชันเก่าของ Qemu / KVM แบ็คเอนด์ Qcow2 นั้นช้ามากเมื่อไม่ได้ถูกจัดสรรล่วงหน้ามากขึ้นดังนั้นหากใช้โดยไม่เปิดใช้งานแคชการเขียนกลับ ดูที่นี่สำหรับข้อมูลเพิ่มเติม

สำหรับเวอร์ชัน Qemu ล่าสุดไฟล์ Qcow2 นั้นเร็วกว่ามากแม้ว่าจะไม่มีการจัดสรรล่วงหน้า (หรือการจัดสรรล่วงหน้าเฉพาะเมตาดาต้าเท่านั้น) อย่างไรก็ตามปริมาณ LVM ยังคงเร็วขึ้น

หมายเหตุเกี่ยวกับโหมดแคช: writebackแคชเป็นโหมดที่ต้องการเว้นแต่การใช้ของผู้เข้าพักที่ไม่มีหรือการสนับสนุนคนพิการสำหรับแคชดิสก์ล้าง / อุปสรรค ในทางปฏิบัติแขกของ Win2000 + และตัวเลือกการเมานท์ Linux EXT4, XFS หรือ EXT3 + ใด ๆ นั้นเป็นค่าปรับ บนมืออื่น ๆ , แคช = ไม่ปลอดภัยควรไม่เคยถูกนำมาใช้เครื่องมือการผลิตเช่นวูบวาบแคชไม่ได้แพร่กระจายไปยังระบบโฮสต์ การปิดโฮสต์ที่ไม่คาดคิดสามารถทำลายระบบไฟล์ของแขกได้อย่างแท้จริง

ฉันพบปัญหาเดียวกันทั้งหมดแล้ว ภายในเครื่องเสมือน RHEL7 ฉันมีซอฟต์แวร์ LIO iSCSI เป้าหมายที่เชื่อมต่อกับเครื่องอื่น ในฐานะที่เก็บข้อมูลพื้นฐาน (แบ็คสโตร์) สำหรับ iSCSI LUN ของฉันฉันเริ่มใช้ LVM ในตอนแรก แต่จากนั้นเปลี่ยนเป็นไฟล์รูปภาพ

เรื่องสั้น ๆ สั้น ๆ : เมื่อหน่วยเก็บข้อมูลสำรองติดอยู่กับ virtio_blk (vda, vdb เป็นต้น) คอนโทรลเลอร์ - ประสิทธิภาพจากไคลเอนต์ iSCSI ที่เชื่อมต่อกับเป้าหมาย iSCSI อยู่ในสภาพแวดล้อมของฉัน ~ 20 IOPS พร้อมปริมาณงาน (ขึ้นอยู่กับขนาด IO) ~ 2- 3 MiB / s ฉันเปลี่ยนคอนโทรลเลอร์ดิสก์เสมือนภายในเครื่องเสมือนเป็น SCSI และฉันสามารถรับ 1,000+ IOPS และปริมาณงาน 100+ MiB / s จากไคลเอนต์ iSCSI ของฉัน

<disk type='file' device='disk'>
   <driver name='qemu' type='qcow2' cache='none' io='native'/>
   <source file='/var/lib/libvirt/images/station1/station1-iscsi1-lun.img'/>
   <target dev='sda' bus='scsi'/>
   <address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>