Hvorfor er mit NVMe langsommere end en SSD?

I denne artikel vil vi se på nogle af nuancerne i I/O-undersystemet og deres indflydelse på ydeevnen.

For et par uger siden stod jeg over for spørgsmålet om, hvorfor NVMe på en server var langsommere end SATA på en anden. Jeg kiggede på serverspecifikationerne og indså, at dette var et vanskeligt spørgsmål: NVMe var fra brugersegmentet, og SSD var fra serversegmentet.

Det er naturligvis ikke rimeligt at sammenligne produkter fra forskellige segmenter i forskellige miljøer, men dette er ikke et komplet teknisk svar. Lad os studere det grundlæggende, udføre eksperimenter og give et svar på det stillede spørgsmål.

Hvad er fsync, og hvor bruges det?

For at fremskynde arbejdet med drev bufres data, det vil sige, lagres i flygtig hukommelse, indtil en passende mulighed byder sig for at gemme indholdet af bufferen på drevet. Kriterierne for en "mulighed" bestemmes af operativsystemet og drevets karakteristika. I tilfælde af strømsvigt vil alle data i bufferen gå tabt.

Der er en række opgaver, hvor du skal være sikker på, at ændringer til en fil bliver skrevet til drevet og ikke i en mellembuffer. Denne sikkerhed kan opnås ved at bruge det POSIX-kompatible fsync-systemkald. Kaldning af fsync tvinger en skrivning fra bufferen til drevet.

Lad os demonstrere effekten af ​​buffere med et kunstigt eksempel i form af et kort program i 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;
}

Kommentarerne forklarer godt rækkefølgen af ​​handlinger i programmet. Teksten "svaret på livets hovedspørgsmål, universet og alt det der" vil blive bufferet af operativsystemet, og hvis du genstarter serveren ved at trykke på Reset-knappen under "beregninger", vil filen være tom. I vores eksempel er teksttab ikke et problem, så fsync er ikke nødvendigt. Databaser deler ikke denne optimisme.

Databaser er komplekse programmer, der samtidig arbejder med mange filer, så de vil være sikre på, at de data, de skriver, bliver gemt på drevet, da konsistensen af ​​dataene inde i databasen afhænger af dette. Databaser er designet til at registrere alle gennemførte transaktioner og være klar til at miste strøm til enhver tid. Denne adfærd kræver konstant brug af fsync i store mængder.

Hvad er effekten af ​​hyppig brug af fsync?

Under normal I/O forsøger operativsystemet at optimere kommunikationen med diske, da eksterne drev er de langsomste i hukommelseshierarkiet. Derfor forsøger operativsystemet at skrive så mange data som muligt i én adgang til drevet.

Lad os demonstrere virkningen af ​​at bruge fsync med et specifikt eksempel. Vi har følgende SSD'er som testdrev:

• Intel® DC SSD S4500 480 GB, tilsluttet via SATA 3.2, 6 Gbit/s;
• Samsung 970 EVO Plus 500GB, tilsluttet via PCIe 3.0 x4, ~31 Gbit/s.

Tests udføres på en Intel® Xeon® W-2255, der kører Ubuntu 20.04. Sysbench 1.0.18 bruges til at teste diske. Der er oprettet en partition på diskene, formateret som ext4. Forberedelse til testen involverer oprettelse af 100 GB filer:

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

Løbende 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

Testresultaterne er vist i tabellen.

prøve
Intel® S4500
Samsung 970 EVO+

Læser uden fsync, MiB/s
5734.89
9028.86

Optagelse uden fsync, MiB/s
3823.26
6019.24

Læser med fsync, MiB/s
37.76
3.27

Optagelse med fsync, MiB/s
25.17
2.18

Det er let at se, at NVMe fra klientsegmentet er trygt i spidsen, når styresystemet selv bestemmer, hvordan der skal arbejdes med diske, og taber, når fsync bruges. Dette rejser to spørgsmål:

1. Hvorfor overstiger læsehastigheden i testen uden fsync kanalens fysiske båndbredde?
2. Hvorfor er et serversegment-SSD bedre til at håndtere et stort antal fsync-anmodninger?

Svaret på det første spørgsmål er enkelt: sysbench genererer filer fyldt med nuller. Testen blev således udført over 100 gigabyte nuller. Da dataene er meget ensartede og forudsigelige, kommer forskellige OS-optimeringer i spil og fremskynder eksekveringen markant.

Hvis du sætter spørgsmålstegn ved alle sysbench-resultater, kan du bruge 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

prøve
Intel® S4500
Samsung 970 EVO+

Læser uden fsync, MiB/s
45.5
178

Optagelse uden fsync, MiB/s
30.4
119

Læser med fsync, MiB/s
32.6
20.9

Optagelse med fsync, MiB/s
21.7
13.9

Tendensen til, at NVMe-ydeevnen forringes, når du bruger fsync, er tydeligt synlig. Du kan gå videre til at besvare det andet spørgsmål.

Optimering eller bluff

Tidligere sagde vi, at dataene er gemt i en buffer, men vi specificerede ikke hvilken, da dette ikke var vigtigt. Selv nu vil vi ikke dykke ned i forviklingerne af operativsystemer og vil fremhæve to generelle typer buffere:

• program;
• hardware.

Softwarebufferen refererer til de buffere, der findes i operativsystemet, og hardwarebufferen refererer til diskcontrollerens flygtige hukommelse. Systemkaldet fsync sender en kommando til drevet om at skrive data fra dets buffer til hovedlageret, men har ingen mulighed for at verificere, at kommandoen udføres korrekt.

Da SSD'en viser de bedste resultater, kan der tages to antagelser:

• disken er designet til en lignende belastning;
• disken "bluffer" og ignorerer kommandoen.

Drevets uærlige opførsel kan bemærkes, hvis du udfører en strømtabstest. Du kan tjekke dette med et script diskchecker.pl, som var skabt i 2005 år.

Dette script kræver to fysiske maskiner - en "server" og en "klient". Klienten skriver en lille mængde data til disken under test, kalder fsync og sender information til serveren om, hvad der blev skrevet.

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

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

Efter at have kørt scriptet, skal du slukke for strømmen til "klienten" og ikke returnere strømmen i flere minutter. Det er vigtigt at afbryde den person, der testes, fra elektricitet, og ikke bare udføre en hård nedlukning. Efter nogen tid kan serveren tilsluttes og indlæses i OS. Efter indlæsning af operativsystemet skal du starte det igen diskchecker.pl, men med et argument verificere.

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

I slutningen af ​​kontrollen vil du se antallet af fejl. Hvis der er 0, har disken bestået testen. For at udelukke et heldigt tilfælde for disken, kan eksperimentet gentages flere gange.

Vores S4500 viste ingen fejl, da strømmen gik tabt, hvilket betyder, at den er klar til arbejdsbelastninger med mange fsync-opkald.

Konklusion

Når du vælger diske eller hele færdige konfigurationer, skal du huske detaljerne i de problemer, der skal løses. Umiddelbart virker det indlysende, at NVMe, altså en SSD med PCIe interface, er hurtigere end den “klassiske” SATA SSD. Men som vi har erfaret i dag, er dette muligvis ikke tilfældet under specifikke forhold og med visse opgaver.

Hvordan tester du serverkomponenter, når du lejer fra en IaaS-udbyder?
Vi venter på dig i kommentarerne.

Kilde: www.habr.com