🥇Waarom is mijn NVMe langzamer dan SSD?

In dit artikel bespreken we enkele nuances van het invoer-uitvoersysteem en hun invloed op de prestaties.

Een paar weken geleden deed ik het volgende vooronderzoek: waarom is NVMe op de ene server langzamer dan SATA op de andere? Ik keek naar de specificaties van de servers en realiseerde me dat het een misleidende vraag was: de NVMe kwam uit het consumentensegment, terwijl de SSD uit het serversegment kwam.

Het is duidelijk dat het niet correct is om producten uit verschillende segmenten in een andere omgeving te vergelijken, maar dat geeft geen uitputtend technisch antwoord. Laten we de basisprincipes onderzoeken, experimenten uitvoeren en een antwoord op de gestelde vraag geven.

Wat is fsync en waar wordt het gebruikt?

Om de prestaties met opslagmedia te verbeteren, worden gegevens gebufferd, dat wil zeggen opgeslagen in vluchtig geheugen totdat het een geschikt moment is om de inhoud van de buffer naar de opslag te schrijven. De criteria voor een ‘geschikt moment’ worden bepaald door het besturingssysteem en de specificaties van de opslag. In het geval van een stroomuitval gaan alle gegevens in de buffer verloren.

Er zijn verschillende taken waarbij je zeker moet zijn dat wijzigingen in een bestand op de opslag zijn geschreven en niet in de tussentijdse buffer liggen. Deze zekerheid kan worden verkregen door gebruik te maken van de POSIX-compatibele systeemaanroep fsync. De aanroep fsync initieert een gedwongen schrijven van de buffer naar de opslag.

We zullen de invloed van buffers demonstreren met een kunstmatig voorbeeld in de vorm van een kort programma in 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;
}

De commentaren leggen goed uit wat de volgorde van handelingen in het programma is. De tekst ‘antwoord op de belangrijkste vraag van het leven, het universum en alles’ wordt gebufferd door het besturingssysteem, en als je de server opnieuw opstart door op de Reset-knop te drukken tijdens de ‘berekeningen’, zal het bestand leeg zijn. In ons voorbeeld is het verlies van tekst geen probleem, dus is fsync niet nodig. Dat is voor databases niet hetzelfde.

Databases zijn complexe programma's die gelijktijdig met meerdere bestanden werken, dus ze willen er zeker van zijn dat de gegevens die ze schrijven op de opslag worden opgeslagen, omdat dit de consistentie van de gegevens binnen de database beïnvloedt. Databases zijn ontworpen om alle voltooide transacties vast te leggen en zich voor te bereiden op een stroomuitval op elk moment. Dit gedrag verplicht het gebruik van fsync voortdurend en in grote hoeveelheden.

Welke invloed heeft het frequente gebruik van fsync

Bij normaal input-output probeert het besturingssysteem de communicatie met schijven te optimaliseren, aangezien externe opslagmiddelen in de geheugenhiërarchie de traagste zijn. Daarom probeert het besturingssysteem zoveel mogelijk gegevens in één schijfinvoer te schrijven.

Laten we de invloed van het gebruik van fsync demonstreren aan de hand van een specifiek voorbeeld. De volgende solid-state drives zijn onze proefpersonen:

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

De tests worden uitgevoerd op een Intel® Xeon® W-2255 onder het besturingssysteem Ubuntu 20.04. Voor het testen van de schijven wordt sysbench 1.0.18 gebruikt. Op de schijven is één partitie aangemaakt, geformatteerd als ext4. De voorbereiding voor de test omvat het creëren van bestanden van 100 GB:

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

Tests starten:

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

De testresultaten zijn weergegeven in de tabel.

Test
Intel® S4500
Samsung 970 EVO+

Lezen zonder fsync, MiB/s
5734.89
9028.86

Schrijven zonder fsync, MiB/s
3823.26
6019.24

Lezen met fsync, MiB/s
37.76
3.27

Schrijven met fsync, MiB/s
25.17
2.18

Het is niet moeilijk te zien dat NVMe uit het consumentensegment duidelijk de leiding heeft wanneer het besturingssysteem zelf bepaalt hoe het met schijven omgaat, maar verloren gaat wanneer fsync wordt gebruikt. Dit roept twee vragen op:

Waarom overschrijdt de leessnelheid zonder fsync de fysieke bandbreedte van de verbinding?
Waarom verwerkt SSD uit het serversegment een groot aantal fsync-aanvragen beter?

Het antwoord op de eerste vraag is eenvoudig: sysbench genereert bestanden die met nullen zijn gevuld. Zo werd de test uitgevoerd over 100 gigabyte aan nullen. Aangezien de gegevens zeer uniform en voorspelbaar zijn, komen verschillende optimalisaties van het besturingssysteem in actie en versnellen ze de uitvoering aanzienlijk.

Als je twijfelt aan alle resultaten van sysbench, kun je gebruikmaken van 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+

Lezen zonder fsync, MiB/s
45.5
178

Schrijven zonder fsync, MiB/s
30.4
119

Lezen met fsync, MiB/s
32.6
20.9

Schrijven met fsync, MiB/s
21.7
13.9

De tendens van de prestatiedaling bij NVMe bij gebruik van fsync is goed zichtbaar. We kunnen nu verder gaan met het antwoord op de tweede vraag.

Optimalisatie of bluffen

Eerder hebben we gezegd dat gegevens in de buffer worden opgeslagen, maar we hebben niet gespecificeerd in welke specifiek, omdat dit niet essentieel was. We zullen nu ook niet dieper ingaan op de details van besturingssystemen en we zullen twee algemene soorten buffers onderscheiden:

softwarematig;
hardwarematig.

Met een softwarebuffer verwijzen we naar de buffers in het besturingssysteem, terwijl de hardwarebuffer verwijst naar het vluchtige geheugen van de schijfcontroller. De systeemaanroep fsync stuurt een opdracht naar de schijf om gegevens uit zijn buffer naar de hoofdopslag te schrijven, maar kan de correctheid van de uitvoering van het opdracht niet controleren.

Aangezien SSD's betere resultaten tonen, kunnen we twee aannames doen:

de schijf is ontworpen voor een dergelijke belasting;
de schijf 'blufft' en negeert de opdracht.

Oneerlijk gedrag van de schijf kan worden opgemerkt als je een test uitvoert met uitval van de stroom. Dit kan worden getest met een script diskchecker.pl, dat was een aparte sectie gecreëerd voor scripts voor verborgen identificatie. Bovendien stelde FP-Inspector in staat om enkele nieuwe manieren van gebruik van de Web API voor identificatie te onthullen, die eerder nog niet in de praktijk waren voorgekomen. in 2005.

Dit script vereist twee fysieke machines - een 'server' en een 'klant'. De klant schrijft een kleine hoeveelheid gegevens naar de te testen schijf, roept fsync aan en stuurt de server informatie over wat er is opgeslagen.

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

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

Na het starten van het script moet de 'klant' zonder stroom worden gezet en enkele minuten zonder stroom blijven. Het is belangrijk om de testmachine van de elektriciteit los te koppelen en niet gewoon een harde uitschakeling uit te voeren. Na een tijdje kan de server weer worden aangesloten en opgestart in het besturingssysteem. Na het opstarten van het besturingssysteem moet je opnieuw diskchecker.pl, maar met het argument is het uitvoeren van tests op de verkregen configuratie met behulp van.

.\/diskchecker.pl -s  verify

Aan het einde van de controle zie je het aantal fouten. Als het er 0 zijn, heeft de schijf de test doorstaan. Om een gelukkige samenloop van omstandigheden voor de schijf uit te sluiten, kan de test meerdere keren worden herhaald.

Onze S4500 vertoonde geen fouten bij stroomuitval, wat betekent dat we kunnen stellen dat hij bestand is tegen belastingen met een groot aantal fsync-aanroepen.

Conclusie

Bij het kiezen van schijven of volledige configuraties moet rekening worden gehouden met de specifieke taken die opgelost moeten worden. Op het eerste gezicht lijkt het vanzelfsprekend dat NVMe, dat wil zeggen SSD's met een PCIe-interface, sneller zijn dan 'klassieke' SATA SSD's. Echter, zoals we vandaag hebben begrepen, kan dit onder specifieke omstandigheden en met bepaalde taken anders zijn.

Hoe test je serveronderdelen bij het huren bij een IaaS-provider?
We kijken uit naar jullie reacties.

Bron: habr.com