🥇De ce NVMe-ul meu este mai lent decât SSD?

În acest articol, vom analiza anumite aspecte ale subsistemului de intrare-ieșire și influența acestora asupra performanței.

Acu câteva săptămâni, m-am confruntat cu întrebarea de ce NVMe pe un server este mai lent decât SATA pe altul. Am verificat specificațiile serverelor și am realizat că a fost o întrebare cu subînțeles: NVMe era din segmentul utilizatorilor, iar SSD-ul era din segmentul serverelor.

Este evident că compararea produselor din segmente diferite într-un mediu diferit este incorectă, dar aceasta nu reprezintă un răspuns tehnic epuizant. Vom studia conceptele de bază, vom efectua experimente și vom oferi un răspuns la întrebarea pusă.

Ce este fsync și unde este folosit

Pentru a accelera lucrul cu stocarea, datele sunt bufferizate, adică stocate în memorie volatila până când apare o oportunitate favorabilă de a salva conținutul buffer-ului pe stocare. Criteriile pentru „oportunitatea favorabilă” sunt determinate de sistemul de operare și de caracteristicile stocării. În cazul întreruperii de alimentare, toate datele din buffer vor fi pierdute.

Există o serie de sarcini în care este necesar să fim siguri că modificările dintr-un fișier sunt scrise pe stocare și nu sunt lăsate în buffer intermediar. Această certitudine poate fi obținută prin utilizarea apelului de sistem compatibil POSIX fsync. Apelul fsync initiază scrierea forțată din buffer pe stocare.

Vom demonstra influența bufferelor printr-un exemplu artificial sub forma unui program scurt în limbajul 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;
}

Comentariile explică bine secvența de acțiuni din program. Textul „răspunsul la întrebarea principală a vieții, universului și tot ce ține de el” va fi bufferizat de sistemul de operare, iar dacă resetăm serverul apăsând butonul Reset în timpul „calculărilor”, fișierul va fi gol. În exemplul nostru, pierderea textului nu reprezintă o problemă, astfel că fsync nu este necesar. Baze de date nu împărtășesc același optimism.

Bazele de date sunt programe complexe care lucrează simultan cu multe fișiere, așa că doresc să fie sigure că datele scrise de ele vor fi salvate pe stocare, deoarece aceasta depinde de consistența datelor în cadrul Bazei de Date. Bazele de date sunt proiectate să scrie toate tranzacțiile finalizate și să fie pregătite pentru întreruperea alimentării în orice moment. Acest comportament obligă la utilizarea constantă a fsync în cantități mari.

Ce influențează utilizarea frecventă a fsync

În timpul operațiunilor normale de citire și scriere, sistemul de operare își propune să optimizeze comunicarea cu discurile, deoarece în ierarhia memoriei, unitățile de stocare externe sunt cele mai lente. De aceea, sistemul de operare se străduiește să scrie cât mai multe date într-o singură accesare a unității.

Să demonstrăm influența utilizării fsync printr-un exemplu concret. Unitățile de testare sunt următoarele unități SSD:

Intel® DC SSD S4500 480 GB, conectat prin SATA 3.2, 6 Gbps;
Samsung 970 EVO Plus 500GB, conectat prin PCIe 3.0 x4, ~31 Gbps.

Testele se desfășoară pe un Intel® Xeon® W-2255, folosind sistemul de operare Ubuntu 20.04. Pentru testarea discurilor, este utilizat sysbench 1.0.18. Pe discuri a fost creată o singură partiție, formatată ca ext4. Pregătirea pentru test constă în crearea de fișiere cu o dimensiune totală de 100 GB:

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

Rularea testelor:

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

Rezultatele testelor sunt prezentate în tabel.

Test
Intel® S4500
Samsung 970 EVO+

Citire fără fsync, MiB/s
5734.89
9028.86

Scriere fără fsync, MiB/s
3823.26
6019.24

Citire cu fsync, MiB/s
37.76
3.27

Scriere cu fsync, MiB/s
25.17
2.18

Nu este greu de observat că NVMe din segmentul clientului conduce cu încredere atunci când sistemul de operare decide singur cum să lucreze cu discurile, dar pierde când se folosește fsync. Așadar, se nasc două întrebări:

De ce, în testul fără fsync, viteza de citire depășește lățimea de bandă fizică a canalului?
De ce SSD-urile din segmentul serverelor gestionează mai bine un număr mare de cereri fsync?

Răspunsul la prima întrebare este simplu: sysbench generează fișiere umplute cu zero. Astfel, testul a fost efectuat pe 100 de gigabytes de zero. Deoarece datele sunt foarte uniforme și previzibile, diferite optimizări ale sistemului de operare intră în acțiune, accelerând semnificativ execuția.

Dacă punem la îndoială toate rezultatele sysbench, putem folosi 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+

Citire fără fsync, MiB/s
45.5
178

Scriere fără fsync, MiB/s
30.4
119

Citire cu fsync, MiB/s
32.6
20.9

Scriere cu fsync, MiB/s
21.7
13.9

Tendința de scădere a performanței pentru NVMe la utilizarea fsync este bine evidentă. Putem trece la răspunsul la cea de-a doua întrebare.

Optimizare sau bluff

Anterior am menționat că datele sunt stocate în memorie tampon, dar nu am specificat în care anume, deoarece nu a fost esențial. Și acum nu ne vom adânci în subtilitățile sistemelor de operare și vom evidenția două tipuri generale de memorii tampon:

software;
hardware.

Prin buferul software se înțelege buferele care există în sistemul de operare, iar prin buferul hardware se înțelege memoria volatilă a controlerului de disc. Apelul de sistem fsync trimite dispozitivului comanda de a scrie datele din buffer în memoria principală, dar nu poate controla corectitudinea executării comenzii.

Deoarece SSD-ul arată rezultate mai bune, se pot face două presupuneri:

discul este proiectat pentru o sarcină de acest tip;
discul "blufează" și ignoră comanda.

Comportamentul incorect al dispozitivului poate fi observat dacă se efectuează un test cu dispariția alimentării. Acest lucru poate fi verificat cu un script diskchecker.pl, care a fost o secțiune separată pentru scripturile de identificare ascunsă. În plus, FP-Inspector a permis identificarea unor moduri noi de utilizare a API-urilor Web pentru identificare, care nu au fost întâlnite anterior în practică. în 2005.

Acest script necesită două mașini fizice — „server” și „client”. Clientul scrie pe discul testat un volum mic de date, apelează fsync și trimite serverului informații despre ce a fost scris.

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

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

După ce scriptul a fost lansat, este necesar să se deconecteze „clientul” de la sursa de alimentare și să nu se restabilească alimentarea timp de câteva minute. Este important să deconectați testatul de la electricitate, nu doar să efectuați o oprire forțată. După o anumită perioadă de timp, serverul poate fi conectat și pornit în sistemul de operare. După pornirea sistemului de operare, este necesar să relansați diskchecker.pl, dar cu argumentul verify.

.\/diskchecker.pl -s  verify

La finalul verificării veți vedea numărul de erori. Dacă sunt 0, înseamnă că discul a trecut testul. Pentru a exclude o întâmplare favorabilă pentru disc, experimentul poate fi repetat de mai multe ori.

S4500 al nostru nu a arătat erori la pierderea alimentării, deci se poate susține că este pregătit pentru sarcini cu un număr mare de apeluri fsync.

Concluzie

Atunci când alegeți discuri sau configurații complete, trebuie să țineți cont de specificitatea sarcinilor care trebuie rezolvate. La prima vedere pare evident că NVMe, adică SSD-uri cu interfață PCIe, sunt mai rapide decât SSD-urile „clasice” SATA. Cu toate acestea, așa cum am înțeles astăzi, în condiții specifice și cu sarcini particulare, acest lucru poate să nu fie adevărat.

Cum testați componentele serverelor atunci când le închiriați de la un provider IaaS?
Așteptăm comentariile voastre.

Sursa: habr.com