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

V tomto článku se podíváme na některé nuance I/O subsystému a jejich dopad na výkon.

Před pár týdny jsem narazil na otázku, proč je NVMe na jednom serveru pomalejší než SATA na jiném. Podíval jsem se na vlastnosti serverů a uvědomil jsem si, že to byla triková otázka: NVMe bylo ze segmentu uživatelů a SSD bylo ze segmentu serverů.

Je zřejmé, že není správné porovnávat produkty z různých segmentů v různých prostředích, ale toto není vyčerpávající technická odpověď. Budeme studovat základy, provádět experimenty a dát odpověď na položenou otázku.

Co je fsync a kde se používá

Pro urychlení práce s jednotkami jsou data ukládána do vyrovnávací paměti, tj. ukládána do volatilní paměti, dokud se nenaskytne vhodná příležitost uložit obsah vyrovnávací paměti na jednotku. Kritéria příležitosti jsou určena operačním systémem a charakteristikami disku. V případě výpadku napájení budou všechna data ve vyrovnávací paměti ztracena.

Existuje řada úloh, u kterých si musíte být jisti, že změny v souboru jsou zapsány na jednotku a neleží v mezilehlé vyrovnávací paměti. Toto ujištění lze získat pomocí systémového volání fsync kompatibilního s POSIX. Volání fsync vynutí zápis z vyrovnávací paměti na disk.

Ukažme si vliv bufferů na umělém příkladu v podobě krátkého C programu.

#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í sled akcí v programu. Text „odpověď na hlavní otázku života, vesmíru a toho všeho“ bude uložen do vyrovnávací paměti operačním systémem, a pokud během „výpočtů“ restartujete server stisknutím tlačítka Reset, soubor bude prázdný. V našem příkladu není ztráta textu problém, takže fsync není potřeba. Databáze tento optimismus nesdílejí.

Databáze jsou složité programy, které pracují s mnoha soubory současně, takže chtějí mít jistotu, že data, která zapisují, budou uložena na disku, protože na tom závisí konzistence dat v databázi. Databáze jsou navrženy tak, aby zaznamenávaly všechny dokončené transakce a byly kdykoli připraveny na výpadek proudu. Toto chování vás zavazuje používat fsync neustále ve velkém množství.

Co ovlivňuje časté používání fsync

Při normálním I/O se operační systém snaží optimalizovat komunikaci disku, protože externí disky jsou nejpomalejší v hierarchii paměti. Operační systém se proto snaží zapsat co nejvíce dat při jednom přístupu na disk.

Ukažme si dopad použití fsync na konkrétním příkladu. Jako testovací subjekty máme následující SSD:

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

Testy se provádějí na Intel® Xeon® W-2255 se systémem Ubuntu 20.04. K testování disků se používá sysbench 1.0.18. Disky mají jeden oddíl naformátovaný jako ext4. Příprava na test je vytvoření 100 GB souborů:

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

Průběžné testy:

# Без 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 testu 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í pomocí fsync, MiB/s
37.76
3.27

Nahrávání s fsync, MiB/s
25.17
2.18

Je dobře vidět, že NVMe z klientského segmentu suverénně vede, když se operační systém sám rozhoduje, jak s disky pracovat, a prohrává při použití fsync. To vyvolává dvě otázky:

1. Proč rychlost čtení překračuje fyzickou šířku pásma odkazu v testu bez fsync?
2. Proč je SSD segmentu serveru lepší při zpracování velkého počtu požadavků fsync?

Odpověď na první otázku je jednoduchá: sysbench generuje nulové soubory. Test byl tedy proveden přes 100 gigabajtů nul. Vzhledem k tomu, že data jsou velmi jednotná a předvídatelná, přicházejí 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í pomocí fsync, MiB/s
32.6
20.9

Nahrávání s fsync, MiB/s
21.7
13.9

Trend k poklesu výkonu v NVMe při použití fsync je jasně viditelný. Můžete přejít k druhé otázce.

Optimalizace nebo blaf

Dříve jsme řekli, že data jsou uložena ve vyrovnávací paměti, ale nespecifikovali jsme ve které, protože to nebylo důležité. Ani nyní se nebudeme ponořit do složitostí operačních systémů a vyčlenit dva obecné typy vyrovnávacích pamětí:

• program;
• Hardware.

Softwarová vyrovnávací paměť odkazuje na vyrovnávací paměti, které jsou v operačním systému, a hardwarová vyrovnávací paměť na energeticky nezávislou paměť řadiče disku. Systémové volání fsync posílá na jednotku příkaz k zápisu dat z vyrovnávací paměti do hlavního úložiště, ale nemá žádný způsob, jak řídit správné provedení příkazu.

Vzhledem k tomu, že SSD funguje lépe, lze učinit dva předpoklady:

• disk je navržen pro zatížení podobného plánu;
• disk "blafuje" a ignoruje příkaz.

Nepoctivé chování pohonu lze zaznamenat, pokud provedete test s výpadkem napájení. Můžete to zkontrolovat pomocí skriptu. diskchecker.pl, to bylo vytvořeno v 2005 roce.

Tento skript vyžaduje dva fyzické stroje – „server“ a „klient“. Klient zapíše malé množství dat na testovaný disk, zavolá 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 nutné odpojit „klienta“ od napájení a několik minut nezapínat napájení. Důležité je odpojit testovaný subjekt od elektřiny, a ne jen provést tvrdé vypnutí. Po nějaké době lze server připojit a načíst do operačního systému. Po nabootování OS je potřeba začít znovu diskchecker.pl, ale s argumentem ověřit si.

./diskchecker.pl -s <server[:port]> verify <file>

Na konci kontroly uvidíte počet chyb. Pokud jsou 0, pak disk testem prošel. Pro vyloučení kombinace okolností, která je pro disk úspěšná, lze experiment několikrát opakovat.

Náš S4500 nevykazoval žádné chyby při ztrátě napájení, což znamená, že je připraven na zatížení se spoustou volání fsync.

Závěr

Při výběru disků nebo celých hotových konfigurací byste měli mít na paměti specifika úkolů, které je třeba vyřešit. Na první pohled se zdá zřejmé, že NVMe, tedy SSD s rozhraním PCIe, je rychlejší než „klasické“ SATA SSD. Jak jsme však dnes pochopili, ve specifických podmínkách a při určitých úkolech tomu tak být nemusí.

Jak testujete komponenty serveru při pronájmu od poskytovatele IaaS?
Čekáme na vás v komentářích.

Zdroj: www.habr.com