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?
Tomasz Torcz
