Kodėl mano NVMe yra lėtesnis nei mano SSD?

Šiame straipsnyje apžvelgsime kai kuriuos I/O posistemio niuansus ir jų įtaką našumui.

Prieš porą savaičių susidūriau su klausimu, kodėl NVMe viename serveryje yra lėtesnė nei SATA kitame. Pažiūrėjau į serverių charakteristikas ir supratau, kad tai gudrus klausimas: NVMe buvo iš vartotojų segmento, o SSD – iš serverių segmento.

Akivaizdu, kad nėra teisinga lyginti skirtingų segmentų produktus skirtingose ​​aplinkose, tačiau tai nėra išsamus techninis atsakymas. Išstudijuosime pagrindus, atliksime eksperimentus ir atsakysime į užduotą klausimą.

Kas yra fsync ir kur jis naudojamas?

Siekiant pagreitinti darbą su diskais, duomenys yra saugomi buferyje, tai yra, saugomi nepastovioje atmintyje, kol atsiranda patogi galimybė išsaugoti buferio turinį diske. „Galimybės“ kriterijus lemia operacinė sistema ir disko charakteristikos. Nutrūkus maitinimui, visi buferyje esantys duomenys bus prarasti.

Yra keletas užduočių, kurias atliekant turite būti tikri, kad failo pakeitimai įrašomi į diską, o ne į tarpinį buferį. Šį patikinimą galima gauti naudojant su POSIX suderinamą fsync sistemos iškvietimą. Fsync iškvietimas verčia rašyti iš buferio į diską.

Pademonstruokime buferių poveikį dirbtiniu pavyzdžiu trumpos C programos pavidalu.

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

Komentarai gerai paaiškina veiksmų seką programoje. Tekstas „atsakymas į pagrindinį gyvenimo klausimą, Visata ir visa tai“ bus buferizuotas operacinės sistemos, o jei „skaičiavimų“ metu paspausdami mygtuką Reset iš naujo paleisite serverį, failas bus tuščias. Mūsų pavyzdyje teksto praradimas nėra problema, todėl fsync nereikia. Duomenų bazės nepritaria šiam optimizmui.

Duomenų bazės yra sudėtingos programos, kurios vienu metu dirba su daugybe failų, todėl jos nori būti tikri, kad įrašyti duomenys bus išsaugoti diske, nes nuo to priklauso duomenų bazės viduje esančių duomenų nuoseklumas. Duomenų bazės yra skirtos įrašyti visas atliktas operacijas ir būti pasirengusios bet kada prarasti energiją. Dėl šio elgesio reikia nuolat naudoti fsync dideliais kiekiais.

Kas turi įtakos dažnam fsync naudojimui

Įprasto I/O metu operacinė sistema bando optimizuoti ryšį su diskais, nes išoriniai diskai yra lėčiausi atminties hierarchijoje. Todėl operacinė sistema bando įrašyti kuo daugiau duomenų per vieną prieigą prie disko.

Parodykime fsync naudojimo poveikį konkrečiu pavyzdžiu. Bandomiesiems diskams turime šiuos SSD:

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

Bandymai atliekami naudojant Intel® Xeon® W-2255, kuriame veikia Ubuntu 20.04. Norėdami išbandyti diskus, naudojamas sysbench 1.0.18. Diskai turi vieną skaidinį, suformatuotą kaip ext4. Pasiruošimas bandymui yra sukurti 100 GB failus:

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

Vykdomi testai:

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

Bandymų rezultatai pateikti lentelėje.

Testas
Intel® S4500
Samsung 970 EVO+

Skaitymas be fsync, MiB/s
5734.89
9028.86

Įrašymas be fsync, MiB/s
3823.26
6019.24

Skaitymas su fsync, MiB/s
37.76
3.27

Įrašymas su fsync, MiB/s
25.17
2.18

Nesunku pastebėti, kad NVMe iš klientų segmento užtikrintai pirmauja, kai pati operacinė sistema nusprendžia, kaip dirbti su diskais, ir pralaimi, kai naudojamas fsync. Tai kelia du klausimus:

1. Kodėl skaitymo greitis bandyme be fsync viršija fizinį kanalo pralaidumą?
2. Kodėl serverio segmento SSD geriau tvarko daug fsync užklausų?

Atsakymas į pirmąjį klausimą yra paprastas: sysbench generuoja nulinius failus. Taigi, bandymas buvo atliktas daugiau nei 100 gigabaitų nulių. Kadangi duomenys yra labai vienodi ir nuspėjami, atsiranda įvairių OS optimizacijų, kurios žymiai pagreitina vykdymą.

Jei abejojate visais sysbench rezultatais, galite naudoti 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

Testas
Intel® S4500
Samsung 970 EVO+

Skaitymas be fsync, MiB/s
45.5
178

Įrašymas be fsync, MiB/s
30.4
119

Skaitymas su fsync, MiB/s
32.6
20.9

Įrašymas su fsync, MiB/s
21.7
13.9

Aiškiai matoma NVMe našumo blogėjimo tendencija naudojant fsync. Galite pereiti prie antrojo klausimo.

Optimizavimas arba blefas

Anksčiau sakėme, kad duomenys saugomi buferyje, bet nenurodėme, kuris iš jų, nes tai nebuvo svarbu. Net ir dabar nesigilinsime į operacinių sistemų subtilybes ir išskirsime du bendrus buferių tipus:

• programa;
• techninė įranga.

Programinės įrangos buferis reiškia buferius, esančius operacinėje sistemoje, o aparatinės įrangos buferis – nepastovią disko valdiklio atmintį. Fsync sistemos iškvietimas siunčia į diską komandą įrašyti duomenis iš buferio į pagrindinę saugyklą, bet negali patikrinti, ar komanda vykdoma teisingai.

Kadangi SSD rodo geriausius rezultatus, galima daryti dvi prielaidas:

• diskas skirtas panašiai apkrovai;
• diskas "blefuoja" ir nepaiso komandos.

Nesąžiningą pavaros elgesį galima pastebėti, jei atliksite bandymą, kai dingo elektra. Tai galite patikrinti naudodami scenarijų. diskchecker.pl, tai buvo sukurta 2005 metų.

Šiam scenarijui reikalingi du fiziniai įrenginiai – „serveris“ ir „klientas“. Klientas įrašo nedidelį kiekį duomenų į bandomąjį diską, iškviečia fsync ir siunčia informaciją į serverį apie tai, kas buvo parašyta.

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

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

Paleidę scenarijų, turite išjungti „kliento“ maitinimą ir keletą minučių negrąžinti maitinimo. Svarbu atjungti tikrinamąjį nuo elektros, o ne tik atlikti sunkų išjungimą. Po kurio laiko serverį galima prijungti ir įkelti į OS. Paleidę OS, turite pradėti iš naujo diskchecker.pl, bet su argumentu patikrinti.

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

Patikrinimo pabaigoje pamatysite klaidų skaičių. Jei yra 0, tada diskas išlaikė testą. Kad būtų išvengta laimingo disko sutapimo, eksperimentą galima pakartoti keletą kartų.

Mūsų S4500 nerodė jokių klaidų, kai dingo maitinimas, o tai reiškia, kad jis yra paruoštas darbui su daugybe fsync skambučių.

išvada

Renkantis diskus ar visas paruoštas konfigūracijas, turėtumėte atsiminti problemų, kurias reikia išspręsti, specifiką. Iš pirmo žvilgsnio atrodo akivaizdu, kad NVMe, tai yra SSD su PCIe sąsaja, yra greitesnis nei „klasikinis“ SATA SSD. Tačiau, kaip šiandien sužinojome, tam tikromis sąlygomis ir atliekant tam tikras užduotis to gali nebūti.

Kaip tikrinate serverio komponentus, kai nuomojatės iš IaaS teikėjo?
Laukiame Jūsų komentaruose.

Šaltinis: www.habr.com