Hvorfor er min NVMe langsommere end SSD?

I denne artikel vil vi se på nogle nuancer af input-output subsystemet og deres indflydelse på ydeevnen.

For et par uger siden stødte jeg på spørgsmålet om, hvorfor NVMe på én server var langsommere end SATA på en anden. Jeg kiggede på specifikationerne for serverne og indså, at det var et trickspørgsmål: NVMe var fra forbrugersegmentet, mens SSD'en var fra serversegmentet.

Det er åbenlyst, at det ikke er korrekt at sammenligne produkter fra forskellige segmenter i forskellige omgivelser, men det er ikke en udtømmende teknisk forklaring. Lad os undersøge grundene, udføre eksperimenter og give svar på det stillede spørgsmål.

Hvad er fsync, og hvor anvendes det?

For at fremskynde arbejdet med lagringsenheder, bliver data buffere, det vil sige gemt i energikrævende hukommelse, indtil der er en passende mulighed for at gemme indholdet fra bufferen til lagringsenheden. Kriterierne for en 'passende mulighed' bestemmes af operativsystemet og lagringsenhedens specifikationer. Hvis strømmen forsvinder, vil alle data i bufferen gå tabt.

Der er en række opgaver, hvor det er nødvendigt at være sikker på, at ændringer i en fil er skrevet til lagringsenheden og ikke blot ligger i det mellemliggende buffer. Denne sikkerhed kan opnås ved at bruge den POSIX-kompatible systemopkald fsync. Opkaldet til fsync initierer en tvungen skrivning fra bufferen til lagringsenheden.

Lad os demonstrere indflydelsen af buffere med et kunstigt eksempel i form af et kort program i C-sprog.

#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 involverede handlinger i programmet. Teksten 'svaret på det store spørgsmål om livet, universet og alt sådan noget' vil blive buffere af operativsystemet, og hvis serveren genstartes ved at trykke på Reset-knappen under 'beregningerne', så vil filen være tom. I vores eksempel er tabet af tekst ikke et problem, så fsync er ikke nødvendig. Databaser deler ikke denne optimisme.

Databaser er komplekse programmer, der samtidig arbejder med mange filer, så de ønsker at være sikre på, at de data, de skriver, bliver gemt på lagringsenheden, da dette påvirker datakonsistensen i databasen. Databaser er designet til at skrive alle afsluttede transaktioner og være klar til strømafbrydelser på ethvert tidspunkt. Denne adfærd kræver konstant brug af fsync i store mængder.

Hvad påvirker hyppig brug af fsync

Ved almindelig I/O forsøger operativsystemet at optimere kommunikationen med diske, da eksterne lagerenheder er de langsomste i hukommelseshierarkiet. Derfor forsøger operativsystemet at skrive så mange data som muligt pr. adgang til lageret.

Lad os demonstrere indflydelsen af brugen af fsync med et konkret eksempel. Som testobjekter har vi følgende SSD'er:

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

Testerne udføres på en Intel® Xeon® W-2255 under styresystemet Ubuntu 20.04. Til test af diske bruges sysbench 1.0.18. Der er oprettet en partition på diskene, formateret som ext4. Forberedelsen til testen indebærer at oprette filer på 100 GB:

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

Start af testene:

# Без 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 præsenteres i tabellen.

Test
Intel® S4500
Samsung 970 EVO+

Læsning uden fsync, MiB/s
5734.89
9028.86

Skrivning uden fsync, MiB/s
3823.26
6019.24

Læsning med fsync, MiB/s
37.76
3.27

Skrivning med fsync, MiB/s
25.17
2.18

Det er ikke svært at bemærke, at NVMe fra klientssegmentet klart fører, når operativsystemet selv bestemmer, hvordan det skal arbejde med diske, og taber, når fsync bruges. Her opstår to spørgsmål:

1. Hvorfor overskrider læsehastigheden uden fsync den fysiske båndbredde af kanalen?
2. Hvorfor håndterer SSD'er fra serversegmentet et stort antal fsync-anmodninger bedre?

Svaret på det første spørgsmål er simpelt: sysbench genererer filer fyldt med nuller. Således blev testen udført på 100 gigabyte af nuller. Da dataene er meget ensartede og forudsigelige, træder forskellige OS-optimeringer i kraft, og de væsentligt fremskynder udførelsen.

Hvis man stiller spørgsmålstegn ved alle sysbench-resultaterne, kan man 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

Test
Intel® S4500
Samsung 970 EVO+

Læsning uden fsync, MiB/s
45.5
178

Skrivning uden fsync, MiB/s
30.4
119

Læsning med fsync, MiB/s
32.6
20.9

Skrivning med fsync, MiB/s
21.7
13.9

Tendensen til fald i ydelsen hos NVMe ved brug af fsync er tydelig. Vi kan nu gå videre til svaret på det andet spørgsmål.

Optimering eller bluff

Tidligere har vi nævnt, at data opbevares i en buffer, men vi specificerede ikke hvilken, da det ikke var væsentligt. Vi vil heller ikke dykke ned i detaljerne i operativsystemer og vil fremhæve to generelle typer buffere:

• programmeringsbuffer;
• hardwarebuffer.

Under software buffer, we mean the buffers present in the operating system, while hardware refers to the volatile memory of the disk controller. The system call fsync sends a command to the storage device to write data from its buffer to the main storage but cannot control the accuracy of the command execution.

Since SSDs show better performance, we can make two assumptions:

• the disk is designed for a workload of this kind;
• the disk is 'bluffing' and ignoring the command.

Dishonest behavior of the storage device can be noticed if a test is conducted with power loss. This can be checked with the script diskchecker.pl, which was oprettet created in 2005.

This script requires two physical machines - a 'server' and a 'client.' The client writes a small amount of data to the tested disk, calls fsync, and sends the information about what was written to the server.

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

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

After starting the script, the 'client' must be powered off and not restored for several minutes. It is crucial to disconnect the tested device from electricity, not just perform a hard shutdown. After some time, the server can be connected and booted into the OS. Once the OS is loaded, you need to run diskchecker.pl, but with the argument verify.

.\/diskchecker.pl -s  verify

At the end of the check, you will see the number of errors. If there are 0 errors, then the disk has passed the test. To rule out a lucky coincidence for the disk, the test can be repeated several times.

Our S4500 showed no errors during a power loss, so we can say it is ready for workloads with a high number of fsync calls.

Konklusion

When choosing disks or entire ready-made configurations, one should remember the specifics of the tasks that need to be solved. At first glance, it seems obvious that NVMe, meaning SSDs with a PCIe interface, are faster than 'classic' SATA SSDs. However, as we understood today, this may not be the case under specific conditions and tasks.

How do you test server components when renting from an IaaS provider?
We look forward to your comments.

Kilde: habr.com