🥇Miks on minu NVMe aeglasem kui SSD?

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

Mõni nädal tagasi sattusin küsimuse ette, miks NVMe ühel serveril on aeglasem kui SATA teisel. Vaatasin serverite spetsifikatsioone ja sain aru, et see oli petlik küsimus: NVMe kuulus kasutajasegmenti, samas kui SSD oli serverisegmentist.

Ilmselgelt ei ole õiglane võrrelda erinevate segmentide tooteid erinevates tingimustes, kuid see ei ole ammendav tehniline vastus. Uurime põhialuseid, viime läbi eksperimentaalsed katsetused ja anname vastuse esitatud küsimusele.

Mis on fsync ja kus seda kasutatakse

Andmete salvestamise kiirendamiseks vahemäluandmed salvestatakse, see tähendab, et need talletatakse energiat tarvitavas mälus seni, kuni tekib sobiv olukord vahemälu sisu salvestamiseks andmekandjale. "Sobivus" määratakse operatsioonisüsteemi ja andmekandja omaduste järgi. Võimsuse kadumise korral kaotatakse kõik vahemälu andmed.

On mitmeid ülesandeid, kus on oluline olla kindel, et faili muudatused on kirjutatud andmekandjale, mitte ei ole vahemikus. Seda usaldusväärsust saab tagada POSIX-ühilduva süsteemikõne fsync kasutamisega. Fsynci kutsumine algatab vahemälu sunniviisilise kirjutamise andmekandjale.

Demonstrime vahemälu mõju kunstliku näite kaudu, kasutades lühikest C keeles kirjutatud programmi.

#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 programmi tegevuste järjestust. Tekst "vastus elu, universumi ja kõike muud tähtsa kohta" salvestatakse operatsioonisüsteemis vahemällu, ja kui serverit taaskäivitada Reset nuppu vajutades "arvutuste" ajal, jääb fail tühjaks. Meie näites ei ole teksti kaotus probleem, seega fsync ei ole vajalik. Andmebaasid ei jaga seda optimismi.

Andmebaasid on keerukad programmid, mis töötavad samaaegselt paljude failidega, seega peavad nad olema kindlad, et nende kirjutatud andmed salvestatakse andmekandjale, kuna see mõjutab andmete järjepidevust andmebaasis. Andmebaasid on projekteeritud salvestama kõik lõpetatud tehingud ja olema valmis voolu katkestamiseks igal hetkel. Selline käitumine nõuab fsynci pidevat kasutamist suurtes kogustes.

Mille poole püüab sageli kasutada fsync?

Tavalise sisendi ja väljundi korral püüab operatsioonisüsteem optimeerida suhtlemist ketastega, kuna välimised andmekandjad on mäluhierarhiis kõige aeglasemad. Seetõttu püüab operatsioonisüsteem salvestada võimalikult palju andmeid ühe salvestamisprotsessi käigus.

Demonstrime fsynci kasutamise mõju konkreetse näite kaudu. Meie katsealusteks on järgmised tahkete andmekandjad:

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 all Ubuntu 20.04. Ketaste testimiseks kasutatakse sysbench 1.0.18. Diskidel on loodud üks jaotis, mis on vormindatud ext4-ks. Testiks valmistumine 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 fsynciga, MiB/s
37.76
3.27

Kirjutamine fsynciga, MiB/s
25.17
2.18

Ei ole raske märkida, et kliendisegmendi NVMe on kindel liider, kui operatsioonisüsteem ise otsustab, kuidas ketastega töötada, ja kaotab, kui kasutatakse fsync'i. Sellega seondub kaks küsimust:

Miks on testis, kus fsync ei ole kasutusel, lugemise kiirus füüsilisest läbilaskevõimest suurem?
Miks töötleb serverisegmendi SSD paremini suurt hulka fsynci päringuid?

Esimese küsimuse vastus on lihtne: sysbench genereerib faile, mis on täidetud nullidega. Seega viidi test läbi 100 GB nullide üle. Kuna andmed on väga ühetaolised ja etteennustatavad, on kasutusele võetud erinevad operatsioonisüsteemi optimeerimised, mis kiirendavad märgatavalt teostust.

Kui kahtled kõikide sysbench'i tulemuste osas, saad 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 fsynciga, MiB/s
32.6
20.9

Kirjutamine fsynciga, MiB/s
21.7
13.9

Tendents NVMe jõudluse vähenemisele fsynci kasutamisel on hästi märgatav. Võime liikuda vastuse juurde teisele küsimusele.

Optimeerimine või petmine

Varem rääkisime, et andmed salvestatakse vahemällu, kuid ei täpsustanud, millisesse, kuna see ei olnud oluline. Me ei süvene ka praegu operatsioonisüsteemide üksikasjadesse ja eristame kahte üldist vahemälu tüüpi:

tarkvaraline;
riistvaraline.

Programmi puhver viitab bufeeridele, mis on operatsioonisüsteemis, samas kui riistvara puhver on energia sõltuv mälu ketta kontrolleris. Süsteemi kutsung fsync saadab talletile käsu kirjutada andmed oma puhvrist peamisse salvestusse, kuid ei suuda jälgida käsu täitmise korrektsust.

Kuna SSD näitab paremaid tulemusi, võib teha kaks oletust:

kettas on projekteeritud sellise koormuse all;
kettas "petab" ja ignoreerib käsku.

Ketta ebaaus käitumine võib ilmneda, kui teostada test voolu katkestamisega. Seda saab kontrollida skripti abil diskchecker.pl, mis oli ja ja ja ja ja ja. aastal 2005.

See skript nõuab kahte füüsilist masinat - "server" ja "kliendi". Klient kirjutab testitavale kettale väikese hulga andmeid, kutsub esile fsync ja saadab serverile teavet 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 "kliendi" toide katkestada ja mitte taastada seda mitme minuti jooksul. On oluline, et just testitav oleks elektrist välja lülitatud, mitte lihtsalt jõhkralt välja lülitatud. Pärast mõningast aega saab serveri taas ühendama ja käivitama operatsioonisüsteemi. Pärast operatsioonisüsteemi käivitamist on vaja uuesti käivitada diskchecker.pl, kuid argumendiga verify.

./diskchecker.pl -s  verify

Kontrollimise lõpuks näete vigade arvu. Kui vigu ei ole, tähendab see, et kettas on katsumuse vastu pidanud. Õnnestunud tingimuste välistamiseks võib katset korrata mitu korda.

Meie S4500 ei näidanud voolu kadumise korral vigu, st saame väita, et see on valmis suure koormusega fsynci ülesannete täitmiseks.

Kokkuvõte

Kettade või terve komplekteeritud konfiguratsiooni valimisel tuleks arvesse võtta tegevuste spetsiifikat, mida on vaja lahendada. Esmapilgul tundub ilmne, et NVMe, st PCIe-liidese SSD-d, on kiiremad kui "klassikalised" SATA SSD-d. Kuid nagu me täna mõistsime, võib see teatud tingimustes ja ülesannetes olla ekslik.

Kuidas testite serverikomponente, kui rendite IaaS-teenuse pakkujalt?
Ootame teie kommentaare.

Allikas: habr.com