매우 낮은 KVM 디스크 성능 (qcow2 디스크 파일 + virtio)

KVM 게스트를 설정하는 동안 디스크 성능에 심각한 문제가 있습니다. 간단한 사용하여 dd테스트의 qcow2 이미지 (미러링 된 RAID 어레이)에 상주하는 호스트의 파티션에 걸쳐에서 기록 1백20메가바이트가 / S 내 손님에 이르기까지 쓰기 느끼는 동안, 0.5 3메가바이트에를 / S .

• 게스트는 몇 개의 CPU와 4G의 RAM으로 구성되었으며 현재 다른 것을 실행하지 않습니다. 현재로서는 최소한의 설치입니다.
• 를 사용하여 성능을 테스트 time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000합니다.
• 게스트가 virtio를 사용하도록 구성되었지만 성능에 차이가있는 것으로 보이지는 않습니다.
• 호스트 파티션은 4kb로 정렬됩니다 (어쨌든 호스트의 성능은 양호합니다).
• 디스크에 쓰기 저장 캐싱을 사용하면보고 된 성능이 크게 향상되지만 사용하지 않는 것이 좋습니다. 그것 없이도 성능은 이것보다 훨씬 나을 것입니다.
• 호스트와 게스트 모두 우분투 12.04 LTS를 실행하고 있으며 qemu-kvm 1.0 + noroms-0ubuntu13 및 libvirt 0.9.8-2ubuntu17.1과 함께 제공됩니다.
• 호스트는 최종 기한 IO 스케줄러를 활성화하고 게스트는 noop을 갖습니다.

kvm 성능을 조정하는 가이드가 많이있는 것 같습니다. 결국 거기에 도달 할 것입니다. 그러나이 시점에서 이보다 훨씬 더 나은 성능을 얻는 것처럼 보이므로 뭔가 잘못되었습니다.

업데이트 1

갑자기 돌아가서 지금 테스트하면 26.6MB / s입니다. 이것은 내가 qcrow2를 기대했던 것과 더 비슷합니다. 누군가 문제가 무엇인지에 대한 아이디어가있는 경우 (그리고 신비하게 다시 돌아 오는 경우) 질문을 남길 것입니다.

업데이트 2

qcow2 성능에 대한 걱정을 멈추고 원시 이미지로 RAID1 위에 LVM으로 넘어갔습니다. 여전히 virtio를 사용하지만 디스크 드라이브에서 cache = 'none'및 io = 'native'를 설정했습니다. 쓰기 성능은 이제 appx입니다. 위와 동일한 기본 테스트를 사용하는 135MB / s 이므로 문제를 완전히 해결할 수있을 때 문제가 무엇인지 파악하는 데별로 중요하지 않습니다.

예, qcow2 파일은 놀랍도록 빠른 성능을 위해 설계되지 않았습니다. 원시 파티션 (또는 바람직하게는 LV)에서 훨씬 더 운이 좋을 것입니다.

QCOW2로 최고의 성능 을 달성하는 방법 :

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

qcow2 개발자에 따르면 가장 중요한 것은 사전 할당이며 크게 향상됩니다. 이제 LVM과 거의 같은 수준입니다 ! 이것은 일반적으로 최신 (Fedora 25+) Linux 배포판에서 활성화됩니다.

또한 프로덕션 인스턴스 가 아닌 경우 안전하지 않은 캐시를 제공 할 수 있습니다 (위험하고 권장되지 않으며 테스트에만 적합 함).

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

일부 사용자는 일부 테스트에서이 구성이 LVM / 안전하지 않은 구성보다 뛰어나다 고보고합니다.

이러한 모든 매개 변수에는 최신 QEMU 1.5 이상 이 필요합니다! 다시 말하지만, 현대 배포판의 대부분에는 이것들이 있습니다.

이 설정으로 qcow2 이미지에 대한 훌륭한 결과를 얻었습니다.

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

게스트 캐시를 비활성화하고 AIO (비동기 IO)를 활성화합니다. dd명령을 실행 하면 호스트에서 177MB / s, 게스트에서 155MB / s가 나옵니다. 이미지는 호스트 테스트가 수행 된 동일한 LVM 볼륨에 배치됩니다.

내 qemu-kvm버전은 재고 Ubuntu 12.04.2 LTS의 1.0+noroms-0ubuntu14.8커널 3.2.0-41-generic입니다.

단일 명령으로 vms를 실행하는 경우 인수에 사용할 수 있습니다

kvm-드라이브 파일 = / path_to.qcow2, if = virtio, cache = off <...>

3MB / s에서 70MB / s로

이전 Qemu / KVM 버전에서 Qcow2 백엔드는 사전 할당되지 않은 경우 매우 느려서 쓰기 백 캐시가 활성화되지 않은 경우 더 많이 사용됩니다. 자세한 내용은 여기를 참조하십시오.

최신 Qemu 버전에서는 사전 할당 (또는 메타 데이터 전용 사전 할당)을 사용하지 않더라도 Qcow2 파일이 훨씬 빠릅니다. 여전히 LVM 볼륨은 더 빠릅니다.

캐시 모드에 대한 참고 사항 : 디스크 캐시 플러시 / 배리어에 대한 지원이 없거나 비활성화 된 게스트를 사용하지 않는 한 쓰기 저장 캐시가 선호되는 모드입니다. 실제로, Win2000 + 게스트와 모든 Linux EXT4, XFS 또는 EXT3 + 배리어 마운트 옵션이 적합합니다. 반면, 캐시 플러시는 호스트 시스템으로 전파되지 않기 때문에 cache = unsafe는 프로덕션 시스템에서 사용 해서는 안됩니다 . 예기치 않은 호스트 종료는 말 그대로 게스트의 파일 시스템을 파괴 할 수 있습니다.

나는 정확히 같은 문제를 경험했다. RHEL7 가상 머신에는 다른 머신이 연결되는 LIO iSCSI 대상 소프트웨어가 있습니다. 내 iSCSI LUN의 기본 저장소 (백 스토어)로서 처음에는 LVM을 사용했지만 파일 기반 이미지로 전환했습니다.

간단히 말해 : 백업 스토리지가 virtio_blk (vda, vdb 등) 스토리지 컨트롤러에 연결되어있는 경우 iSCSI 대상에 연결하는 iSCSI 클라이언트의 성능은 내 환경에서 ~ 20 IOPS, 처리량 (IO 크기에 따라) ~ 2- 3 MiB / s. 가상 머신 내의 가상 디스크 컨트롤러를 SCSI로 변경했으며 iSCSI 클라이언트에서 1000+ IOPS 및 처리량 100+ MiB / s를 얻을 수 있습니다.

<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>