Hvorfor er min NVMe tregere enn SSD?

I denne artikkelen skal vi se på noen aspekter av input-output subsystemet og deres innvirkning på ytelsen.

For et par uker siden støtte jeg på spørsmålet om hvorfor NVMe på en server er tregere enn SATA på en annen. Jeg så på spesifikasjonene til serverne og innså at dette var et spørsmål med en vri: NVMe var fra forbrukermarkedet, mens SSD var fra servermarkedet.

Det er tydelig at det ikke er korrekt å sammenligne produkter fra forskjellige segmenter i et ulikt miljø, men dette er ikke et uttømmende teknisk svar. La oss se på det grunnleggende, gjennomføre eksperimenter og gi et svar på det stilte spørsmålet.

Hva er fsync og hvor brukes det?

For å akselerere arbeidet med lagringsenheter blir data buffret, det vil si lagret i energikrevende minne inntil det foreligger en passende anledning til å lagre innholdet i bufferen på lagringsenheten. Kriteriene for hva som utgjør en 'passende anledning' fastsettes av operativsystemet og egenskapene til lagringsenheten. Ved strømbrudd vil all data i bufferen gå tapt.

Det finnes en rekke oppgaver der det er nødvendig å være sikker på at endringer i en fil er skrevet til lagringsenheten, og ikke bare ligger i en mellomlagret buffer. Denne sikkerheten kan oppnås ved å bruke det POSIX-kompatible systemkallet fsync. Kallet fsync initierer en tvungen skriving fra bufferen til lagringsenheten.

Vi vil demonstrere innflytelsen av buffere med et kunstig eksempel i form av et kort program på 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;
}

Kommentarene forklarer godt sekvensen av handlingene i programmet. Teksten 'svaret på hovedspørsmålet i livet, universet og alt annet' vil bli buffret av operativsystemet, og hvis serveren resettes ved å trykke på tilbakestillingsknappen under 'beregningene', vil filen bli tom. I vårt eksempel er tap av tekst ikke et problem, så fsync er ikke nødvendig. Databaser deler imidlertid ikke denne optimismen.

Databaser er komplekse programmer som samtidig arbeider med mange filer, så de ønsker å være sikre på at dataene de skriver vil bli lagret på lagringsenheten, ettersom dette påvirker datakonsistensen inne i databasen. Databaser er designet for å skrive alle fullførte transaksjoner og være klare for strømbrudd når som helst. Denne oppførselen krever konstant bruk av fsync i store mengder.

Hva påvirker hyppig bruk av fsync

Ved vanlig inn- og utdata prøver operativsystemet å optimalisere kommunikasjonen med diskene, ettersom eksterne lagringsenheter er de tregeste i hukommelseshierarkiet. Derfor prøver operativsystemet å skrive så mange data som mulig i ett enkelt kall til lagringsenheten.

Vi skal demonstrere effekten av å bruke fsync med et konkret eksempel. Testobjektene våre er følgende solid-state-lagringsenheter:

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

Testene utføres på Intel® Xeon® W-2255 som kjører Ubuntu 20.04. For diskene brukes sysbench 1.0.18 til testing. Det er opprettet én partisjon på diskene, formatert som ext4. Forberedelsen til testen innebærer å opprette filer med en størrelse på 100 GB:

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

Kjøring av 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

Testresultatene er presentert i tabellen.

Test
Intel® S4500
Samsung 970 EVO+

Lesing uten fsync, MiB/s
5734.89
9028.86

Skriving uten fsync, MiB/s
3823.26
6019.24

Lesing med fsync, MiB/s
37.76
3.27

Skriving med fsync, MiB/s
25.17
2.18

Det er ikke vanskelig å se at NVMe i klientssegmentet leder klart når operativsystemet selv bestemmer hvordan det skal arbeide med diskene, og taper når fsync brukes. Dette stiller to spørsmål:

1. Hvorfor overstiger lesefarten uten fsync den fysiske båndbredden til kanalen?
2. Hvorfor håndterer SSD-er i serversegmentet et stort antall fsync-forespørsel bedre?

Svaret på det første spørsmålet er enkelt: sysbench genererer filer fylt med nuller. Så testen ble utført på 100 GB med nuller. Siden dataene er ganske ensartede og forutsigbare, trer forskjellige optimaliseringer fra OS-en inn, noe som betydelig akselererer utførelsen.

Dersom man setter spørsmålstegn ved alle resultatene fra sysbench, kan man 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+

Lesing uten fsync, MiB/s
45.5
178

Skriving uten fsync, MiB/s
30.4
119

Lesing med fsync, MiB/s
32.6
20.9

Skriving med fsync, MiB/s
21.7
13.9

Tendensen til ytelsestap hos NVMe ved bruk av fsync er godt merkbar. Vi kan nå gå videre til svaret på det andre spørsmålet.

Optimalisering eller bløff

Tidligere snakket vi om at data lagres i bufferen, men presiserte ikke hvilken, da dette ikke var viktig. Vi vil ikke gå i dybden på nyansene i operativsystemer, men vil trekke frem to generelle typer buffere:

• programvare;
• maskinvare.

Programvarebufferen refererer til bufferne i operativsystemet, mens maskinvaren refererer til den energikrevende minnet i kontrolleren for disken. Systemkallet fsync sender en kommando til lagringsenheten om å skrive data fra dens buffer til hovedlagringsenheten, men kan ikke kontrollere korrektheten av gjennomføringen av kommanden.

Siden SSD viser de beste resultatene, kan to antagelser gjøres:

• disken er designet for belastning av denne typen;
• disken 'bløffer' og ignorerer kommandoen.

Urettferdig oppførsel fra lagringsenheten kan oppdages ved å utføre en test med strømkutt. Dette kan sjekkes med skriptet diskchecker.pl, som ble opprettet i 2005.

Dette skriptet krever to fysiske maskiner - 'server' og 'klient'. Klienten skriver en liten mengde data til den testede disken, kaller fsync og sender informasjon til serveren om hva som er skrevet.

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

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

Etter at skriptet er startet, må 'klienten' bli frakoblet strømmen i flere minutter. Det er viktig å kutte strømmen til den testede enheten, ikke bare å utføre en hard avstengning. Etter en stund kan serveren kobles til og startes opp til OS. Når OS er lastet inn, må diskchecker.pligjen startes, men med argumentet verify.

.\/diskchecker.pl -s  verify

Ved slutten av testen vil du se antall feil. Hvis det er 0, så har disken bestått testen. For å utelukke en tilfeldighet kan testen gjentas flere ganger.

Vår S4500 viste ingen feil ved strømkutt, noe som betyr at vi kan si at den er klar for belastninger med mange fsync-forespørsel.

Konklusjon

Når du velger disker eller komplette konfigurasjoner, er det viktig å huske på spesifikasjonene for oppgavene som må løses. Ved første øyekast kan det virke åpenbart at NVMe, altså SSD-er med PCIe-grensesnitt, er raskere enn 'klassiskt' SATA SSD. Men, som vi har forstått i dag, kan dette i spesifikke forhold og med bestemte oppgaver ikke alltid være tilfelle.

Hvordan tester du serverkomponenter når du leier fra en IaaS-leverandør?
Vi venter på kommentarene dine.

Kilde: habr.com