Hvorfor er min NVMe tregere enn en SSD?

I denne artikkelen vil vi se på noen av nyansene til I/O-delsystemet og deres innvirkning på ytelsen.

For et par uker siden møtte jeg et spørsmål om hvorfor NVMe på en server er tregere enn SATA på en annen. Jeg så på egenskapene til serverne og innså at det var et lurespørsmål: NVMe var fra brukersegmentet, og SSD var fra serversegmentet.

Det er åpenbart ikke riktig å sammenligne produkter fra ulike segmenter i ulike miljøer, men dette er ikke et uttømmende teknisk svar. Vi vil studere det grunnleggende, gjennomføre eksperimenter og gi et svar på spørsmålet som stilles.

Hva er fsync og hvor brukes det

For å fremskynde arbeidet med stasjoner, bufres data, det vil si lagret i flyktig minne til en praktisk mulighet byr seg til å lagre innholdet i bufferen til stasjonen. Mulighetskriterier bestemmes av operativsystemet og kjøreegenskapene. Ved strømbrudd vil alle data i bufferen gå tapt.

Det er en rekke oppgaver der du må være sikker på at endringene i filen skrives til stasjonen, og ikke ligger i en mellombuffer. Denne forsikringen kan oppnås ved å bruke det POSIX-kompatible fsync-systemkallet. Fsync-kallet tvinger en skriving fra bufferen til stasjonen.

La oss demonstrere effekten av buffere med et kunstig eksempel i form av et kort C-program.

#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;
}

Kommentarer forklarer handlingsrekkefølgen i programmet godt. Teksten "svaret på hovedspørsmålet om livet, universet og alt det der" vil bli bufret av operativsystemet, og hvis du starter serveren på nytt ved å trykke på Reset-knappen under "beregninger", vil filen være tom. I vårt eksempel er ikke teksttap et problem, så fsync er ikke nødvendig. Databaser deler ikke denne optimismen.

Databaser er komplekse programmer som jobber med mange filer samtidig, så de vil være sikre på at dataene de skriver blir lagret på stasjonen, siden konsistensen av data i databasen avhenger av dette. Databasene er designet for å registrere alle fullførte transaksjoner og være klare for strømbrudd når som helst. Denne oppførselen forplikter deg til å bruke fsync konstant i store mengder.

Hva påvirker hyppig bruk av fsync

Med vanlig I/O prøver operativsystemet å optimalisere diskkommunikasjonen, siden eksterne stasjoner er de tregeste i minnehierarkiet. Derfor prøver operativsystemet å skrive så mye data som mulig i én tilgang til stasjonen.

La oss demonstrere virkningen av å bruke fsync med et spesifikt eksempel. Vi har følgende SSD-er som testpersoner:

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

Tester er utført på en Intel® Xeon® W-2255 som kjører Ubuntu 20.04. For å teste disker brukes sysbench 1.0.18. Diskene har en enkelt partisjon formatert som ext4. Forberedelse til testen er å lage 100 GB filer:

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

Løpende tester:

# Без 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

Testresultatene er presentert i tabellen.

Test
Intel® S4500
Samsung 970 EVO+

Les uten fsync, MiB/s
5734.89
9028.86

Skriv uten fsync, MiB/s
3823.26
6019.24

Leser med fsync, MiB/s
37.76
3.27

Opptak med fsync, MiB/s
25.17
2.18

Det er lett å se at NVMe fra klientsegmentet leder trygt når operativsystemet selv bestemmer hvordan det skal jobbes med disker, og taper når fsync brukes. Dette reiser to spørsmål:

1. Hvorfor overskrider lesehastigheten den fysiske båndbredden til lenken i testen uten fsync?
2. Hvorfor er en serversegment-SSD bedre til å håndtere et stort antall fsync-forespørsler?

Svaret på det første spørsmålet er enkelt: sysbench genererer nullfylte filer. Dermed ble testen utført over 100 gigabyte med nuller. Siden dataene er veldig ensartede og forutsigbare, spiller ulike OS-optimaliseringer inn, og de fremskynder utførelsen betydelig.

Hvis du stiller spørsmål ved alle resultatene til sysbench, kan du bruke 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+

Les uten fsync, MiB/s
45.5
178

Skriv uten fsync, MiB/s
30.4
119

Leser med fsync, MiB/s
32.6
20.9

Opptak med fsync, MiB/s
21.7
13.9

Trenden mot ytelsesfall i NVMe ved bruk av fsync er tydelig synlig. Du kan gå videre til det andre spørsmålet.

Optimalisering eller bløff

Tidligere sa vi at dataene er lagret i en buffer, men spesifiserte ikke i hvilken, siden det ikke var viktig. Selv nå vil vi ikke fordype oss i forviklingene ved operativsystemer og skille ut to generelle typer buffere:

• program;
• maskinvare.

Programvarebufferen refererer til bufferne som er i operativsystemet, og maskinvarebufferen refererer til det flyktige minnet til diskkontrolleren. Systemkallet fsync sender en kommando til stasjonen for å skrive data fra bufferen til hovedlageret, men det har ingen mulighet til å kontrollere riktig utførelse av kommandoen.

Siden SSD-en yter bedre, kan to antakelser gjøres:

• disken er designet for en belastning av en lignende plan;
• disken "bløffer" og ignorerer kommandoen.

Uærlig oppførsel av stasjonen kan bli lagt merke til hvis du utfører en test med strømbrudd. Du kan sjekke dette med et script. diskchecker.pl, det var etablert i 2005 år.

Dette skriptet krever to fysiske maskiner - "server" og "klient". Klienten skriver en liten mengde data til stasjonen som testes, kaller fsync og sender serverinformasjon om hva som ble skrevet.

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

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

Etter å ha kjørt skriptet, er det nødvendig å deaktivere "klienten" og ikke returnere strøm på flere minutter. Det er viktig å koble testpersonen fra strøm, og ikke bare utføre en hard avstengning. Etter en tid kan serveren kobles til og lastes inn i operativsystemet. Etter oppstart av operativsystemet, må du starte på nytt diskchecker.pl, men med et argument verifisere.

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

På slutten av kontrollen vil du se antall feil. Hvis de er 0, besto disken testen. For å utelukke en kombinasjon av omstendigheter som er vellykket for disken, kan eksperimentet gjentas flere ganger.

Vår S4500 viste ingen feil ved strømtap, noe som betyr at den er klar for belastninger med mange fsync-anrop.

Konklusjon

Når du velger disker eller hele ferdige konfigurasjoner, bør du huske på detaljene for oppgavene som må løses. Ved første øyekast virker det åpenbart at NVMe, det vil si en SSD med PCIe-grensesnitt, er raskere enn en «klassisk» SATA SSD. Men som vi har forstått i dag, under spesifikke forhold og med visse oppgaver kan dette imidlertid ikke være tilfelle.

Hvordan tester du serverkomponenter når du leier fra en IaaS-leverandør?
Vi venter på deg i kommentarfeltet.

Kilde: www.habr.com