☰

QEMU + KVM + LVM - 블록 장치 드라이브 성능과 파일 이미지 비교

tag-icon • tag-icon linux filesystems lvm qemu
QEMU + KVM + LVM - 블록 장치 드라이브 성능과 파일 이미지 비교

가상 머신에 대한 새 설정을 만들고 어떤 저장 방법이 가장 빠른지 테스트하고 있습니다. 내 테스트 환경은 LUKS의 LVM이 있는 HDD 드라이브로 구성됩니다. 가상 머신 드라이브용 단일 LV를 생성하고 두 테스트 모두에 이를 재사용하여 HDD 드라이브에서 동일한 위치를 유지하여 일관된 성능을 유지했습니다(HDD 읽기/쓰기 속도는 물리적 위치에 따라 다름).

  • 호스트: 아치 리눅스, 커널 4.12.8
  • 게스트: 우분투 데스크탑 17.04

다음 명령으로 성능을 테스트했습니다.

    dd if=/dev/zero of=test bs=16M count=100 conv=sync

첫 번째 테스트: LV를 가상 머신의 드라이브로 직접 사용

명령:

qemu-system-x86_64 \
  -drive format=raw,file=/dev/mapper/vg_vm-lv_vm_test,if=virtio,aio=native,cache.direct=on \
  -net nic,model=virtio \
  -net user \
  -vga virtio \
  -display gtk,gl=on \
  -smp 3 \
  -cpu host \
  -machine type=pc,accel=kvm \
  -m 3G

결과(각 값은 단일 실행을 나타냄):

  • 새 파일 생성: 98.4MB/s ; 112MB/초
  • 기존 파일에 쓰기: 62.5MB/s ; 68.7MB/초; 64.8MB/초

두 번째 테스트: LV에 ext4를 생성하고 거기에 원시 이미지 파일 넣기

명령:

qemu-system-x86_64 \
  -drive format=raw,file=./ubuntu_17,if=virtio,aio=native,cache.direct=on \
  -net nic,model=virtio \
  -net user \
  -vga virtio \
  -display gtk,gl=on \
  -smp 3 \
  -cpu host \
  -machine type=pc,accel=kvm \
  -m 3G

결과(각 값은 단일 실행을 나타냄):

  • 새 파일 생성: 254MB/s ; 242MB/초
  • 기존 파일에 쓰기: 187MB/s ; 189MB/초; 190MB/초

세 번째 테스트: LV를 가상 머신의 드라이브로 직접 사용, 다른 설정

명령:

qemu-system-x86_64 \
  -drive format=raw,file=/dev/mapper/vg_vm-lv_vm_test,if=virtio,cache=none \
  -net nic,model=virtio \
  -net user \
  -vga virtio \
  -display gtk,gl=on \
  -smp 3 \
  -cpu host \
  -machine type=pc,accel=kvm \
  -m 3G

결과(각 값은 단일 실행을 나타냄):

  • 새 파일 생성: 129MB/s ; 125MB/초
  • 기존 파일에 쓰기: 103MB/s ; 97MB/초; 81.9MB/초

질문

분명히 이 두 가지 솔루션 사이에는 차이가 있지만 호스트 파일 시스템에 오버헤드가 없어야 하기 때문에 원시 블록 장치가 최소한 이미지 파일만큼 빠르다고 예상했습니다. 파일 이미지 사이에 일부 캐싱이 발생하거나 원시 블록 장치에 대한 옵션이 최적이 아니라고 가정합니다. 이 경우 원시 LV가 더 느린 이유는 무엇입니까? 성능을 향상시키려면 어떻게 해야 합니까? 아니면 속도가 더 느려져야 한다면 왜 그럴까요?

편집: 다음 설정을 사용하여 세 번째 테스트 사례를 추가했습니다.http://www.linux-kvm.org/page/Tuning_KVM. 파일 이미지보다 약간 빠르지만 여전히 느린 것으로 나타났습니다. 또한 기존 파일을 실행할 때마다 속도가 느려지는 것을 관찰했습니다. 그러나 파일 덮어쓰기에서는 조각화가 발생해서는 안 되므로 왜 그런 일이 발생하는지 잘 모르겠습니다.

답변1

블록 크기 불일치가 문제일 수 있습니다.

이상적으로는 파일 시스템을 미디어의 기본 블록 크기와 일치시키는 것이 좋습니다. 블록 크기에 대해 선택한 것을 공유하지 않았지만 Ext4 시도에는 4KB, LV에는 512바이트가 있다고 생각합니다. 기본 미디어의 자연 블록 크기가 4KB인 경우 이것이 속도 문제와 속도 감소를 모두 설명한다고 생각합니다. 4k 블록에 512개만 쓸 가능성이 있으므로 블록의 75%를 낭비하고 후속 쓰기에서는 더 많은 블록을 사용하게 되어 더 많은 오버헤드와 낭비가 발생합니다.

기본 미디어 블록 크기와 잘 일치하는 파일 시스템 블록 크기로 테스트를 다시 시도하십시오. 이 경우 4k 블록 크기로 LV를 사용해 보십시오.

LVM은 Ext4보다 약간 더 많은 오버헤드를 추가합니다. 스택 오버플로 답변 그래서 이것이 왜 조금 느린지 설명할 수 있다고 생각합니다. :)

관련 정보