🥇Prečo je môj NVMe pomalší ako SSD?

V tomto článku sa pozrieme na niektoré nuansy subsystému vstup-výstup a ich vplyv na výkon.

Pred pár týždňami som narazil na otázku, prečo je NVMe na jednom serveri pomalšie ako SATA na druhom. Pozrel som sa na špecifikácie serverov a uvedomil si, že to bola otázka s háčikom: NVMe bol zo spotrebiteľského segmentu, zatiaľ čo SSD bol zo serverového.

Je evidentné, že porovnávať produkty z rôznych segmentov v rôznych prostrediach nie je správne, ale to nie je vyčerpávajúca technická odpoveď. Preskúmame základy, vykonáme experimenty a poskytneme odpoveď na položenú otázku.

Čo je fsync a kde sa používa.

Na urýchlenie práce s úložiskami sú dáta vyrovnávané, to znamená, že sú ukladané v pamäti závislej od energie, kým sa nenaskytne výhodná príležitosť na uloženie obsahu vyrovnávacej pamäte na úložisko. Kritériá „výhodnej príležitosti“ sú stanovené operačným systémom a vlastnosťami úložiska. V prípade výpadku napájania budú všetky dáta v vyrovnávacej pamäti stratené.

Existuje množstvo úloh, v ktorých je potrebné mať istotu, že zmeny v súbore sú uložené na úložisku, a nie ležia v medziúložnej vyrovnávacej pamäti. Túto istotu je možné získať použitím systémového volania fsync, ktoré iniciuje nútené zápisy z vyrovnávacej pamäte na úložisko.

Demonštrujeme vplyv vyrovnávacích pamätí umelým príkladom v podobe krátkeho programu v jazyku 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áre dobre vysvetľujú postupnosť krokov v programe. Text "odpoveď na hlavné otázky života, vesmíru a všetkého takého" bude vyrovnávaný operačným systémom, a ak resetujete server stlačením tlačidla Reset počas "výpočtov", súbor bude prázdny. V našom príklade nie je strata textu problém, takže fsync nie je potrebný. Databázy nemajú také optimistické názory.

Databázy sú komplexné programy, ktoré súčasne pracujú s množstvom súborov, a preto chcú mať istotu, že dáta, ktoré zapisujú, budú uložené na úložisku, pretože od toho závisí konzistencia údajov vo vnútri DB. Databázy sú navrhnuté na zapisovanie všetkých dokončených transakcií a na to, aby boli pripravené na výpadky napájania v akomkoľvek momente. Takéto správanie ich núti používať fsync neustále a vo veľkých množstvách.

Aký vplyv má časté používanie fsync

Pri bežnom vstupe a výstupe sa operačný systém snaží optimalizovať komunikáciu s diskami, pretože vo hierarchii pamäte sú externé úložiská najpomalšie. Preto sa operačný systém snaží pri jednom prístupe k úložisku zapísať čo najviac dát.

Demonštrujeme vplyv používania fsync na konkrétnom príklade. Našim testovaným zariadením budú nasledujúce SSD disky:

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

Testy sa vykonávajú na Intel® Xeon® W-2255 pod správou operačného systému Ubuntu 20.04. Na testovanie diskov sa používa sysbench 1.0.18. Na diskoch je vytvorená jedna partícia naformátovaná ako ext4. Príprava na test spočíva vo vytvorení súborov s objemom 100 GB:

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

Spustenie testov:

# Без 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 testov sú uvedené v tabuľke.

Test
Intel® S4500
Samsung 970 EVO+

Čítanie bez fsync, MiB/s
5734.89
9028.86

Zápis bez fsync, MiB/s
3823.26
6019.24

Čítanie s fsync, MiB/s
37.76
3.27

Zápis s fsync, MiB/s
25.17
2.18

Nie je ťažké si všimnúť, že NVMe z klientskeho segmentu jasne vedie, keď operačný systém sám rozhoduje, ako pracovať s diskami, a prehráva, keď sa používa fsync. Odtiaľ vznikajú dve otázky:

Prečo rýchlosť čítania bez fsync presahuje fyzickú priepustnosť kanála?
Prečo SSD z serverového segmentu lepšie spracováva veľké množstvo požiadaviek fsync?

Odpoveď na prvú otázku je jednoduchá: sysbench generuje súbory naplnené nulami. Tak bol test vykonaný nad 100 gigabajtmi núl. Keďže sú dáta veľmi jednotvárne a predvídateľné, vstupujú do hry rôzne optimalizácie OS a tie výrazne urýchľujú vykonávanie.

Ak by sme spochybňovali všetky výsledky sysbench, môžeme využiť 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+

Čítanie bez fsync, MiB/s
45.5
178

Zápis bez fsync, MiB/s
30.4
119

Čítanie s fsync, MiB/s
32.6
20.9

Zápis s fsync, MiB/s
21.7
13.9

Tendencia k poklesu výkonu pri používaní fsync je u NVMe dobre pozorovateľná. Môžeme prejsť k odpovedi na druhú otázku.

Optimalizácia alebo klam

Predtým sme hovorili, že dáta sú uložené v cache, ale nešpecifikovali sme v ktorej, pretože to nebolo zásadné. Ani teraz sa nebudeme hlboko zaoberať detailmi operačných systémov a vyberieme dva všeobecné typy cache:

softvérová;
hardvérová.

Pod pojmom softvérového vyrovnávacieho pamäťového priestoru rozumieme vyrovnávacie pamäte, ktoré existujú v operačnom systéme, a pod hardvérom sa rozumie pamäť ovládača disku, ktorá je závislá na energii. Systémové volanie fsync posiela úložisku príkaz zapísať údaje zo svojej vyrovnávacej pamäte do hlavného úložiska, ale nijako nemôže kontrolovať správnosť vykonania príkazu.

Keďže SSD dosahuje lepšie výsledky, môžeme urobiť dve predpoklady:

disk je navrhnutý na to, aby zvládal záťaž tohto druhu;
disk "klame" a ignoruje príkaz.

Nečestné správanie úložiska možno spozorovať, ak vykonáte test s výpadkom napájania. Môžete to overiť skripom diskchecker.pl, ktorý bol bol vytvorený v roku 2005.

Tento skript vyžaduje dve fyzické zariadenia — „server“ a „klient“. Klient zapisuje na testovaný disk malý objem údajov, volá fsync a posiela serveru informácie o tom, čo bolo zapísané.

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

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

Po spustení skriptu je potrebné odpojiť „klienta“ od napájania a nevrátiť napájanie niekoľko minút. Dôležité je odpojiť testovaného od elektrickej energie, nie len vykonať tvrdé vypnutie. Po uplynutí určitého času možno server pripojiť a načítať operačný systém. Po načítaní operačného systému je potrebné opäť spustiť diskchecker.pl, ale s argumentom verify.

.\/diskchecker.pl -s  verify

Na konci kontroly uvidíte počet chýb. Ak je ich 0, znamená to, že disk prežil skúšku. Na vylúčenie úspešného výsledku pre disk je možné experiment zopakovať niekoľkokrát.

Náš S4500 nesignalizoval chyby pri výpadku napájania, takže môžeme tvrdiť, že je pripravený na zaťaženia s vysokým počtom volaní fsync.

Záver

Pri výbere diskov alebo celých hotových konfigurácií treba mať na pamäti špecifiku úloh, ktoré je potrebné vyriešiť. Na prvý pohľad sa zdá zrejmé, že NVMe, teda SSD s PCIe rozhraním, je rýchlejší ako "klasický" SATA SSD. Avšak, ako sme dnes pochopili, v špecifických podmienkach a s určitými úlohami to nemusí byť tak.

A kako testujete komponenty serverov pri prenájme od poskytovateľa IaaS?
Tešíme sa na vaše komentáre.

Zdroj: habr.com