Niesamowicie niska wydajność dysku KVM (pliki dyskowe qcow2 + virtio)

27

Mam poważne problemy z wydajnością dysku podczas konfigurowania gościa KVM. Za pomocą prostego ddtestu partycja na hoście, na której znajdują się obrazy qcow2 (lustrzana macierz RAID), zapisuje z prędkością ponad 120 MB / s , podczas gdy mój gość zapisuje w zakresie od 0,5 do 3 MB / s .

  • Gość jest skonfigurowany z kilkoma procesorami i 4G pamięci RAM i obecnie nie działa na niczym innym; w tej chwili jest to całkowicie minimalna instalacja.
  • Wydajność jest testowana przy użyciu time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000.
  • Gość jest skonfigurowany do korzystania z virtio, ale nie ma to wpływu na wydajność.
  • Partycje hosta są wyrównane do 4 KB (a wydajność na hostu jest dobra).
  • Używanie buforowania z zapisem na dyskach znacznie zwiększa raportowaną wydajność, ale wolałbym jej nie używać; nawet bez tego wydajność powinna być znacznie lepsza.
  • Zarówno host, jak i gość korzystają z systemu Ubuntu 12.04 LTS, który jest wyposażony w qemu-kvm 1.0 + noroms-0ubuntu13 i libvirt 0.9.8-2ubuntu17.1.
  • Host ma włączony harmonogram IO, a gość nie ma noop.

Wydaje się, że istnieje wiele przewodników na temat poprawiania wydajności KVM i w końcu się tam dostanę, ale wydaje się, że powinienem uzyskać znacznie lepszą wydajność w tym momencie, więc wydaje się, że coś jest już bardzo źle.

Aktualizacja 1

I nagle, kiedy wracam i testuję teraz, jest to 26,6 MB / s; to bardziej przypomina to, czego się spodziewałem w / qcrow2. Zostawię to pytanie na wypadek, gdyby ktoś miał jakieś pomysły na temat problemu (i na wypadek, gdyby w tajemniczy sposób powrócił).

Aktualizacja 2

Przestałem się martwić wydajnością qcow2 i po prostu przełączyłem się na LVM na RAID1 z surowymi obrazami, wciąż używając virtio, ale ustawiając cache = „none” i io = „native” na dysku. Wydajność zapisu wynosi teraz appx. 135 MB / s przy użyciu tego samego testu podstawowego, co powyżej, więc wydaje się, że nie ma sensu ustalanie, na czym polega problem, gdy można go tak łatwo obejść całkowicie.

performance kvm-virtualization qcow2 El Yobo
źródło
Nie wspominałeś o używanej wersji dystrybucji i oprogramowania.
dyasny,
Dodano informacje o wersjach.
El Yobo,
ah, zgodnie z oczekiwaniami, ubuntu ... jest jakaś szansa na odtworzenie tego na fedora?
dyasny,
Serwer znajduje się w Niemczech, a ja jestem obecnie w Meksyku, więc może to być trochę trudne. A jeśli zadziałałoby to nagle ... Nadal nie chciałbym mieć do czynienia z serwerem Fedora;) Widziałem kilka komentarzy sugerujących, że systemy Debian / Ubuntu miały więcej problemów niż Fedora / CentOS dla KVM prace rozwojowe zostały tam wykonane.
El Yobo,
dokładnie o to mi chodzi. w każdym razie, jeśli szukasz systemu operacyjnego klasy serwerowej, potrzebujesz RHEL, a nie Ubuntu
dyasny

Odpowiedzi:

14

Tak, tak, pliki qcow2 nie są zaprojektowane z myślą o niesamowicie szybkiej wydajności. Znacznie więcej szczęścia uzyskasz dzięki surowym partycjom (lub najlepiej LV).

womble
źródło
3
Oczywiście, ale one również nie mają być tak bzdurne, jak liczby, które otrzymuję.
El Yobo,
1
Większość dostępnych przykładów pokazuje podobną wydajność z qcow2, co wydaje się znaczącą poprawą w porównaniu ze starszą wersją. Sama strona KVM pojawiła się na linux-kvm.org/page/Qcow2, które pokazują porównywalne czasy dla szeregu przypadków.
El Yobo,
1
18:35 (qcow2) vs 8:48 (surowe) to „porównywalne czasy”?
womble
1
Zmieniłem je na nieprzetworzone obrazy LVM na RAID1, ustawiłem terminarz io na noop na gościu i termin na hoście, a teraz zapisuje z prędkością 138 MB / s. Nadal nie wiem, co spowodowało, że qcow2 miał prędkości 3 MB / s, ale najwyraźniej można go ominąć, używając surowego, więc dziękuję za popchnięcie mnie w tym kierunku.
El Yobo,
1
To nie do końca prawda - najnowsze łatki w qemu bardzo przyspieszają qcow2! Jesteśmy prawie na równi.
lzap
7

Jak osiągnąć najwyższą wydajność dzięki QCOW2 :

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

Najważniejszym z nich jest prealokacja, która według deweloperów qcow2 daje niezły zastrzyk. Teraz jest prawie na równi z LVM ! Zauważ, że jest to zwykle włączone w nowoczesnych dystrybucjach Linuksa (Fedora 25+).

Możesz także zapewnić niebezpieczną pamięć podręczną, jeśli nie jest to instancja produkcyjna (jest to niebezpieczne i niezalecane, nadaje się tylko do testowania):

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

Niektórzy użytkownicy zgłaszają, że ta konfiguracja w niektórych testach przewyższa konfigurację LVM / niebezpieczną.

Dla wszystkich tych parametrów wymagana jest najnowsza wersja QEMU 1.5+ ! Ponownie większość współczesnych dystrybucji ma je.

lzap
źródło
2
To nie jest dobry pomysł do wykorzystania cache = niebezpieczne: nieoczekiwane zamknięcie host może siać spustoszenie na całym systemie plików gościa. O wiele lepiej jest używać cache = writeback: podobna wydajność, ale znacznie lepsza niezawodność.
shodanshok
1
Jak już powiedziałem: jeśli nie jest to instancja produkcyjna (dobra do testowania)
lzap
Słusznie.
Tęskniłem
6

Dzięki temu ustawieniu uzyskałem świetne wyniki dla obrazu qcow2:

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

która wyłącza pamięć podręczną gości i włącza AIO (asynchroniczne operacje we / wy). Uruchomienie ddpolecenia dało mi 177 MB / s na hoście i 155 MB / s na gościu. Obraz jest umieszczony na tym samym woluminie LVM, w którym przeprowadzono test hosta.

Moja qemu-kvmwersja to 1.0+noroms-0ubuntu14.8i jądro 3.2.0-41-genericz magazynu Ubuntu 12.04.2 LTS.

gertas
źródło
5
Ustawiłeś typ obrazu qcow2 na „raw”?
Alex
Wydaje mi się, że skopiowałem starszy wpis. Przypuszczam, że korzyści płynące z szybkości powinny być takie same type='qcow2', czy możesz to sprawdzić przed edycją? Nie mam już dostępu do takiej konfiguracji - przeprowadziłem migrację do LXC z mount bindkatalogami, aby osiągnąć rzeczywistą prędkość natywną u gości.
gertas
2

Jeśli używasz vms za pomocą jednego polecenia, możesz użyć argumentów

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

Dostałem od 3 MB / s do 70 MB / s

Kourindou Hime
źródło
2

W starszych wersjach Qemu / KVM backend Qcow2 był bardzo wolny, gdy nie był wstępnie przydzielony, a tym bardziej, jeśli był używany bez włączonej pamięci podręcznej zapisu. Zobacz tutaj, aby uzyskać więcej informacji.

W nowszych wersjach Qemu pliki Qcow2 są znacznie szybsze, nawet gdy nie są używane wstępna alokacja (lub wstępna alokacja tylko metadanych). Mimo to wolumeny LVM pozostają szybsze.

Uwaga na trybów cache: opóźnionego zapisu cache jest preferowany tryb, chyba że przy użyciu gościa bez lub niepełnosprawnej wsparcie dla pamięci podręcznej dysku gładkimi / barier. W praktyce goście Win2000 + i wszelkie opcje montowania barier w systemach Linux EXT4, XFS lub EXT3 + są karane grzywną. Z drugiej strony, pamięci podręcznej = niebezpieczne nie należy nigdy używać w maszynach produkcyjnych, ponieważ opróżnianie pamięci podręcznej nie jest propagowane do systemu hosta. Nieoczekiwane zamknięcie hosta może dosłownie zniszczyć system plików gościa.

Shodanshok
źródło
2

Wystąpił dokładnie ten sam problem. W maszynie wirtualnej RHEL7 mam oprogramowanie docelowe LIO iSCSI, z którym łączą się inne maszyny. Jako podstawową pamięć (backstore) dla moich jednostek LUN iSCSI początkowo użyłem LVM, ale potem przełączyłem się na obrazy oparte na plikach.

Krótko mówiąc: po podłączeniu pamięci masowej do kontrolera pamięci masowej virtio_blk (vda, vdb itp.) - wydajność klienta iSCSI łączącego się z celem iSCSI była w moim środowisku ~ 20 IOPS, z przepustowością (w zależności od wielkości IO) ~ 2- 3 MiB / s. Zmieniłem wirtualny kontroler dysku w maszynie wirtualnej na SCSI i jestem w stanie uzyskać ponad 1000 IOPS i przepustowość 100+ MiB / s od moich klientów 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>
Greg W.
źródło