🥇Proč je moje NVMe pomalejší než SSD?

V tomto článku se podíváme na některé nuance subsystému vstupu a výstupu a jejich vliv na výkon.

Před několika týdny jsem se setkal s otázkou, proč je NVMe na jednom serveru pomalejší než SATA na jiném. Prozkoumal jsem specifikace serverů a zjistil, že to byla záludná otázka: NVMe byl z uživatelského segmentu, zatímco SSD z serverového.

Je očividné, že je nepřesné porovnávat produkty z různých segmentů v odlišném prostředí, ale to není vyčerpávající technická odpověď. Prozkoumejme základy, provedeme experimenty a poskytneme odpověď na položenou otázku.

Co je fsync a kde se používá

Aby se urychlil přístup k úložným médiím, jsou data ukládána do mezipaměti, tedy uchovávána v paměti závislé na energii, dokud nenastane vhodná příležitost pro uložení obsahu mezipaměti na úložné médium. Kritéria "vhodné příležitosti" jsou určována operačním systémem a vlastnostmi úložného média. Při výpadku napájení budou všechna data v mezipaměti ztracena.

Existuje řada úloh, ve kterých je nutné mít jistotu, že změny v souboru byly uloženy na úložné médium, a nikoli leží v mezipaměti. Tato jistota může být získána pomocí systémového volání fsync, které iniciuje nucené uložení z mezipaměti na úložné médium.

Demonstrujeme vliv mezipamětí pomocí umělého příkladu ve formě krátkého programu v jazyce C.

#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main(void) {
    /* Открываем файл answer.txt на запись, если его нет -- создаём */
    int fd = open("answer.txt", O_WRONLY | O_CREAT);
    /* Записываем первый набор данных */
    write(fd, "Answer to the Ultimate Question of Life, The Universe, and Everything: ", 71);
    /* Делаем вид, что проводим вычисления в течение 10 секунд */
    sleep(10);
    /* Записываем результат вычислений */
    write(fd, "42n", 3); 

    return 0;
}

Komentáře dobře vysvětlují sekvenci kroků v programu. Text "odpověď na hlavní otázku života, vesmíru a všeho" bude mezipaměťován operačním systémem, a pokud se server restartuje stisknutím tlačítka Reset během "výpočtů", soubor bude prázdný. V našem příkladě ztráta textu není problém, takže fsync není potřeba. Databáze ale tento optimismus nesdílí.

Databáze jsou složité programy, které současně pracují s mnoha soubory, a proto chtějí mít jistotu, že ukládaná data budou uchována na úložném médiu, protože to ovlivňuje konzistenci dat uvnitř DB. Databáze jsou navrženy tak, aby zapisovaly všechny dokončené transakce a byly připraveny na výpadek napájení kdykoli. Takové chování vyžaduje používat fsync neustále ve velkém množství.

Na co má vliv časté používání fsync

Při běžném vstupu a výstupu se operační systém snaží optimalizovat komunikaci s disky, jelikož externí úložná zařízení jsou v hierarchii paměti nejpomalejší. Proto se snaží, aby během jednoho přístupu k úložišti zapsal co nejvíce dat.

Demonstrace vlivu používání fsync na konkrétním příkladu. Našimi subjekty jsou následující SSD disky:

Intel® DC SSD S4500 480 GB, připojený přes SATA 3.2, 6 Gb/s;
Samsung 970 EVO Plus 500 GB, připojený přes PCIe 3.0 x4, ~31 Gb/s.

Testy se provádějí na Intel® Xeon® W-2255 běžícím na OS Ubuntu 20.04. Pro testování disků se využívá sysbench 1.0.18. Na discích je vytvořen jeden oddíl naformátovaný jako ext4. Příprava na test zahrnuje vytvoření souborů o velikosti 100 GB:

sysbench --test=fileio --file-total-size=100G prepare

Spuštění testů:

# Без fsync
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=0 run

# С fsync после каждой записи
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=1 run

Výsledky testů jsou uvedeny v tabulce.

Test
Intel® S4500
Samsung 970 EVO+

Čtení bez fsync, MiB/s
5734.89
9028.86

Zápis bez fsync, MiB/s
3823.26
6019.24

Čtení s fsync, MiB/s
37.76
3.27

Zápis s fsync, MiB/s
25.17
2.18

Není těžké si všimnout, že NVMe z klientského segmentu pevně dominuje, když operační systém sám rozhoduje, jak pracovat s disky, a prohrává při použití fsync. Odtud vyvstávají dvě otázky:

Proč v testu bez fsync rychlost čtení překračuje fyzickou šířku pásma kanálu?
Proč SSD z serverového segmentu lépe zpracovává velké množství požadavků na fsync?

Odpověď na první otázku je jednoduchá: sysbench generuje soubory vyplněné nulami. Takže test byl prováděn na 100 gigabajtech nul. Vzhledem k tomu, že data jsou značně homogenní a předvídatelná, vstupují do hry různé optimalizace OS, které výrazně urychlují provádění.

Pokud zpochybňujete všechny výsledky sysbench, můžete použít fio.

# Без fsync
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=0 --filename=/dev/sdb

# С fsync после каждой записи
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=1 --filename=/dev/sdb

Test
Intel® S4500
Samsung 970 EVO+

Čtení bez fsync, MiB/s
45.5
178

Zápis bez fsync, MiB/s
30.4
119

Čtení s fsync, MiB/s
32.6
20.9

Zápis s fsync, MiB/s
21.7
13.9

Tendence k poklesu výkonu u NVMe při použití fsync je dobře patrná. Můžeme přejít k odpovědi na druhou otázku.

Optimalizace nebo klam

Dříve jsme říkali, že data jsou uchovávána v zásobníku, ale neuvedli jsme, v jakém konkrétně, protože to nebylo zásadní. Ani nyní se nebudeme zabývat detaily operačního systému a vymezíme dva obecné typy zásobníků:

softwarový;
hardwarový.

Pod programovým vyrovnávacím pamětí rozumíme vyrovnávací paměti, které se nacházejí v operačním systému, a pod hardwarovou pamětí se myslí energie závislá paměť řadiče disku. Systémový volání fsync posílá úložnému zařízení příkaz zapsat data z jeho vyrovnávací paměti do hlavního úložiště, ale nemůže nijak kontrolovat správnost provedení příkazu.

Protože SSD vykazuje lepší výsledky, lze učinit dvě předpoklady:

disk je navržen na zatížení tohoto typu;
disk "blufuje" a ignoruje příkaz.

Nečestné chování úložného zařízení lze zaznamenat, pokud provedeme test s výpadkem napájení. Ověřit to lze skriptem diskchecker.pl, který byl vytvořen v roce 2005.

Tento skript vyžaduje dvě fyzické stroje — "server" a "klient". Klient zapisuje na testovaný disk malé množství dat, vyvolá fsync a odešle serveru informace o tom, co bylo zapsáno.

# Запускается на сервере
./diskchecker.pl -l [port]

# Запускается на клиенте
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

Po spuštění skriptu je třeba odpojit "klienta" od elektrické sítě a nezapnout ho několik minut. Je důležité skutečně odpojit testovaný od elektrické energie, a ne jen provést tvrdé vypnutí. Po uplynutí určité doby lze server zapnout a načíst operační systém. Po načtení OS je třeba znovu spustit diskchecker.pl, ale s argumentem verify.

.\/diskchecker.pl -s  verify

Na konci kontroly uvidíte počet chyb. Pokud je jich 0, znamená to, že disk vyhověl testu. Pro vyloučení šťastné náhody lze experiment opakovat několikrát.

Náš S4500 neukázal chyby při ztrátě napájení, což znamená, že můžeme tvrdit, že je připraven na zátěže s vysokým počtem volání fsync.

Závěr

Při výběru disků nebo celých hotových konfigurací je třeba mít na paměti specifika úloh, které je třeba vyřešit. Na první pohled se zdá být zřejmé, že NVMe, tedy SSD s PCIe rozhraním, je rychlejší než "klasické" SATA SSD. Nicméně, jak jsme si dnes uvědomili, v specifických podmínkách a s určitými úkoly to může být jinak.

A jak testujete komponenty serverů při pronájmu u IaaS poskytovatele?
Těšíme se na vaše komentáře.

Zdroj: habr.com