Więc, często tak sobie benchmarkujesz?

Tomasz Torcz 2013-04-15 15:14 Comments

Do tematu wspomagania wolnego dysku mechanicznego szybkim SSD wracam trzy lata później. Celem jest sprawdzenie jak sobie radzi i ile daje dostępne w jądrze linuksa dm-cache.

Co potrzeba?

dysk wolny — udział bierze dysk 5400 RPM 160GB
dysk na cache, czyli partycja 5GiB na Samsung SSD 830
dysk na metadane — partycja 32MiB na powyższym SSD

Pokusiłem się o test real-life. Na wolnym dysku znajdują się obrazy maszyn wirtualnych. W czasie testu w jednej z nich robiona był aktualizacja dwóch pakietów — kernel oraz fedup — oraz usunięcie trzeciego preupgrade. Po aktualizacji cofnięcie tranzakcji. Pomiar wykonany 5 krotnie, skrajne wyniki odrzucone, pozostałe uśrednione. Następnie włączenie cachu na SSD i powtórzenie procedury.

Środowisko:

host: Fedora 18 Spherical Cow z jądrem 3.9.0-0.rc6.git0.1.fc19.x86_64
gość: Fedora 20 Rawhide

Instalacja:

 fedup     noarch      0.7.3-2.fc20               rawhide     67 k
     replacing  preupgrade.noarch 1.1.11-3.fc19
 kernel    x86_64      3.9.0-0.rc6.git0.1.fc20    rawhide     27 M

Pomiar:

% time yum history redo 558 -y
% time yum history undo 558 -y

Decyzje i konfiguracja

Rozdzielenie urządzenia dla metadanych i właściwego cache ma na celu zwiększenie elastyczności rozwiązania. O ile dobór wielkości cache jest prosty (im więcej tym lepiej), to jak z nośnikiem metadanych? Do tego służy następująca reguła:

4MiB + (16bytes * nr_blocks)

A wielkość bloku? To już zależy od charakterystyki obciążenia. Ja przyjąłem “na oko” blok wielkości 64KiB. Przy urządzeniu cache wielkości 5GiB, otrzymujemy porywające zapotrzebowanie 5,25 MiB.

Mamy więc już prawie wszystko: urządzenie do przyspieszenia (sdb), partycję na cache (sda5), partycję na metadane (sda6) i wielkość bloku (64KiB czyli 128 sektorów po 512 bajtów). Potrzebujemy tylko wielkości urządzenia sdb w sektorach:

% blockdev --getsz /dev/sdb 
312581808

Możemy więc utworzyć, zamountować cache i przejść do pomiarów:

% dmsetup create fusiondrive --table '0 312581808 cache /dev/sda6 /dev/sda5 /dev/sdb 128 1 writeback default 0'

% mount /dev/mapper/fusiondrive /var/lib/libvirt/images -o subvol=var_lib_libvirt_images

Wyniki i intepretacja

Zero. Żadnej zauważalnej różnicy. O ile jeszcze procent trafień przy zapisie oscylował w okolicach 4%, to przy odczycie średnia wyszła 0,12%. Czasy sys i user zbliżone - okolice 40s i 50s dla instalacji, w granicach 2,5s dla deinstalacji. Czas real - duży rozrzut, do 83s do ponad 330s. Całkowicie bezużytecznie, nawet nie ma co wykresów robić.

Winny 1 - time yum

Instalacja jądra wydawała się dobrym pomysłem do momentu spojrzenia na wykresy zajętości zasobów przez maszynę wirtualną. Gros czasu obciążenie 100% CPU przy minimalnym użyciu dysku. Powodem było tworzenie obrazu initramfs, a użycie CPU wynika z tworzeni i kompresji pliku cpio. Przydatność do testowania wejścia/wyjścia — żadna. Dodatkowo, yum większość czasu spędzał śpiąc i czekając na procesy potomne wykonujące prawdziwą pracę, w tym czasie nie był mu naliczany czas.

Winny 2 - system plików btrfs

Zarówno dysk sdb, na którym znajduje się obraz maszyny wirtualnej, jak i sama maszyna skonfigurowane są z btrfs. Jest to system plików typu copy-on-write, co oznacza, że dane nigdy nie są nadpisywane. Zapis polega na odczycie danych, zapisaniu zmodyfikowanej kopii gdzieś indziej i uaktualnieniu wskaźników na dysku. Odniesienia do oryginalnej kopii danych znikają (o ile nie ma snapshotów).

Cache działający na poziomie bloków danych nie ma pojęcia, że wrzuca do pamięci podręcznej bloki, do których system plików już nie będzie wracał. Taka już jego uroda, ma ten problem dm-cache, ma go bcache, będzie miał każdy inny. btrfs nie nadaje sie do akceleracji w ten sposób. Dopiero wbudowanie mechanizmów cache SSD w sam btrfs da jakieś sensowne wyniki. Może nawet porównywalne z osiągami ZFS.

W skrócie: benchmarkować to trzeba umieć, panoczku.

Archived comments:

DeHa 2013-04-15 15:19:11

Czyli eksperyment dowiódł, że btrfs jest faktycznie CoW. ;)

zdz 2013-04-15 15:29:57

Mooooo!

LCF 2013-04-15 16:00:35

Huh,

A nie prościej wszystko przemigrować na SSD, zamiast jakieś wynalazki z cachami ?

zdz 2013-04-15 17:00:45

Oczywiście, że łatwiej i za parę lat ekonomicznie to będzie uzasadnione. Na dzień dzisiejszy rozwiązania pamięci hierarchicznej sprzedają się dobrze.

tap 2013-11-25 14:43:31

Zrobiłem teścik bcache - taki organoleptyczny.

Bcache na 2x 120GB SSD (samsung pro i kingston jakiś szybki) w raid1 na linuxowym md + 4x 1TB Segate w raidz1 i na tym zfs.

Bez ssd-ków trzy chodzące równolegle tary powodowały zawał systemu. Load szedł w kosmos, próba zrobienia zfs list kosztowała czasem nawet kilkanaście sekund.

Z bcache 10 chodzących równolegle tarów, load na poziomie 2-3 (8 fizycznych rdzeni HT, więc znikomy), system reponsywny, nadal możliwe było dowalenie jakiejś jeszcze operacji dyskowej. Co ciekawe, 10 tarów wykonało się szybciej (182s) niż 3 tary (270s).

bcache fkoz jako write-back - dlatego na MD, dlatego na dwóch różnych SSD.

zdz 2013-12-18 13:35:31

Przecież ZFS ma natywną obsługę cache na SSD, dlaczego przez bcache?