🥇Miks on minu NVMe aeglasem kui SSD?

Selles artiklis vaatleme mõningaid sisendi ja väljundi alamsüsteemi nüansse ning nende mõju jõudlusele.

Mõni nädal tagasi kohtasin küsimust, miks NVMe on ühel serveril aeglasem kui SATA teisel. Vaatasin serverite omadusi ja mõistsin, et see oli petuküsimus: NVMe kuulus tarbijasegmenti, samas kui SSD kuulus serverisegmenti.

Ilmselgelt ei ole erinevate segmentide tooteid erinevates keskkondades võrrelda korrektne, kuid see ei ole ammendav tehniline vastus. Uurime aluseid, viime läbi eksperimente ja anname vastuse esitatud küsimusele.

Mis on fsync ja kus seda kasutatakse

Andmete töötlemise kiirendamiseks pufferdatakse andmed, s.t. need salvestatakse energiaga seotud mällu, kuni tekib mugav hetk sisendi salvestamiseks mäluseadmest. Kriteeriumid "mugava hetke" määramiseks määrab operatsioonisüsteem ja salvestise omadused. Toitekatkestuse korral kaovad kõik pufferdatud andmed.

On olemas hulk ülesandeid, kus on oluline olla kindel, et faili muudatused on salvestatud mäluseadmest, mitte vahemällu. Seda kindlust saab saavutada, kasutades POSIX-ühilduvat süsteemikõnet fsync. Fsync kutsub esile sunnitud kirjutamise vahemälust mäluseadmest.

Demonstrime puhverdatud andmete mõju kunstliku näitena lühikese programmi kaudu C keeles.

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

Kommentaarid selgitavad hästi programmijärjekorda. Tekst "vastus elu, universumi ja kõigi selliste asjade peamisele küsimusele" puhverdatakse operatsioonisüsteemi poolt, ja kui serveri taaskäivitamiseks vajutada nuppu Reset "arvutuste" ajal, siis fail jääb tühjaks. Meie näites tekstikaotus ei ole probleem, seega fsync ei ole vajalik. Andmebaasid ei jaga sellist optimistlikkust.

Andmebaasid on keerukad programmid, mis töötavad samal ajal paljude failidega, mistõttu nad soovivad olla kindlad, et salvestatud andmed säilibad mäluseadmest, kuna see mõjutab andmete järjepidevust andmebaasis. Andmebaasid on kavandatud salvestama kõiki lõpuleviidud tehinguid ja olema valmis toitekatkestuseks igal hetkel. Selline käitumine nõuab fsynci pidevat kasutamist suurtes kogustes.

Mille see tähendab sagedane fsync kasutamine

Tavapärase sisendi- ja väljundi korral püüab operatsioonisüsteem optimeerida suhtlemist kettaseadmetega, kuna mäluhierarhias on välised salvestusseadmed kõige aeglasemad. Seetõttu püüab operatsioonisüsteem ühe kettaseadmest päringu ajal salvestada võimalikult palju andmeid.

Kujutame ette fsync kasutamise mõju konkreetse näite kaudu. Katsetatavateks seadmeteks on järgmised SSD-d:

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

Testid viiakse läbi Intel® Xeon® W-2255, töötades Ubuntu 20.04-ga. Diskide testimiseks kasutatakse sysbench 1.0.18. Diskidel on loodud üks partitsioon, mis on vormindatud ext4-ks. Testi ettevalmistamine seisneb 100 GB suuruste failide loomises:

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

Testide käivitamine:

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

Testide tulemused on esitatud tabelis.

Test
Intel® S4500
Samsung 970 EVO+

Lugemine ilma fsyncita, MiB/s
5734.89
9028.86

Kirjutamine ilma fsyncita, MiB/s
3823.26
6019.24

Lugemine koos fsynciga, MiB/s
37.76
3.27

Kirjutamine koos fsynciga, MiB/s
25.17
2.18

Ei ole raske märkida, et kliendi segmentide NVMe juhib kindlalt, kui operatsioonisüsteem otsustab ise, kuidas ketastega töötada, ja kaotab, kui kasutatakse fsynci. Siit tekib kaks küsimust:

Miks testis, kus fsynci ei kasutatud, ületab lugemise kiirus füüsilise kanalite läbilaskevõime?
Miks SSD-d serveri segmentidest töötlevad paremini suurt hulka fsynci päringuid?

Esimesele küsimusele on vastus lihtne: sysbench genereerib nullidega täidetud faile. Seega viidi test läbi 100 gigabaidi nullide üle. Kuna andmed on väga ühtlased ja ennustatavad, tulevad mängu operatsioonisüsteemi erinevad optimeerimised ning need kiirendavad täitmist oluliselt.

Kui seada kahtluse alla kõik sysbench'i tulemused, siis saab kasutada 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+

Lugemine ilma fsyncita, MiB/s
45.5
178

Kirjutamine ilma fsyncita, MiB/s
30.4
119

Lugemine koos fsynciga, MiB/s
32.6
20.9

Kirjutamine koos fsynciga, MiB/s
21.7
13.9

Tendents NVMe jõudluse langemisele fsynci kasutamisel on hästi märgatav. Saame liikuda teise küsimuse vastuse juurde.

Optimeerimine või bluff

Varem rääkisime, et andmeid hoitakse vahemikus, kuid ei täpsustanud, millises, kuna see ei olnud oluline. Me ei tahanud ka nüüd süveneda operatsioonisüsteemide nüanssidesse ja toome välja kaks üldist tüüpide vahemikku:

programmist;
riistvaraliselt.

Programmi bufferd tähendab, et need on süsteemis olevad puhverid, samas kui riistvaraline puhver on draivi kontrolleri energiasõltuv mälu. Süsteemikõne fsync saadab draivile käsu kirjutada andmed tema puhvrist peamisse salvestusse, kuid ei saa kuidagi kontrollida käsu täitmise täpsust.

Kuna SSD-l on parem jõudlus, võib teha kaks eeldust:

ketas on projekteeritud sarnase koormuse jaoks;
ketas 'petab' ja ignoreerib käsku.

Ebaausat käitumist saame märkida, kui teha test, kus vool katkeb. Seda saab kontrollida skripti abil diskchecker.pl, mis loodi loodi 2005. aastal.

See skript nõuab kahte füüsilist masinat — 'server' ja 'klient'. Klient kirjutab testitavale kettale väikese hulga andmeid, kutsub esile fsync'i ja edastab serverile teabe selle kohta, mis on salvestatud.

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

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

Pärast skripti käivitamist tuleb 'klient' voolust välja lülitada ja mitte toita see mitu minutit. Oluline on just testitav seade elektrist välja lülitada, mitte lihtsalt jõhkralt kinni panna. Mõne aja pärast on server võimalik uuesti sisse lülitada ja OS-i laadida. Pärast OS-i laadimist tuleb taas käivitada diskchecker.pl, kuid argumendiga verify.

.\/diskchecker.pl -s  verify

Kontrollimise lõpus näete, kui palju vigu esines. Kui neid on 0, siis võib öelda, et ketas talus testi. Õnnega ketta suhtes välistamiseks võib katset korrata mitu korda.

Meie S4500 ei näidanud voolukatkestuse korral vigu, mis tähendab, et saame väita, et see on valmis suure hulga fsync-kutsumise koormuste jaoks.

Kokkuvõte

Kettaste või tervete valmis konfiguratsioonide valimisel tuleb arvestada ülesannete spetsiifikat, mida tuleb lahendada. Esmapilgul tundub olevat ilmne, et NVMe, see tähendab PCIe-liidesega SSD, on kiiremini kui 'klassikaline' SATA SSD. Kuid nagu me täna mõistsime, ei pruugi see olla nii spetsiifilistes tingimustes ja teatud ülesannete korral.

Kuidas teie testite serverikomponente IaaS-teenusepakkuja rentimise ajal?
Ootame teid kommentaarides.

Allikas: habr.com