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

De ce este NVMe-ul meu mai lent decât un SSD?
În acest articol, vom analiza câteva dintre nuanțele subsistemului I/O și impactul acestora asupra performanței.

În urmă cu câteva săptămâni, am întâlnit o întrebare de ce NVMe pe un server este mai lent decât SATA pe altul. M-am uitat la caracteristicile serverelor și mi-am dat seama că era o întrebare șmecheră: NVMe era din segmentul de utilizatori, iar SSD era din segmentul de server.

Evident, nu este corect să comparăm produse din diferite segmente în diferite medii, dar acesta nu este un răspuns tehnic exhaustiv. Vom studia elementele de bază, vom efectua experimente și vom oferi un răspuns la întrebarea pusă.

Ce este fsync și unde este utilizat

Pentru a accelera lucrul cu unitățile, datele sunt stocate în memoria tampon, adică stocate în memoria volatilă până când se prezintă o oportunitate convenabilă de a salva conținutul tamponului pe unitate. Criteriile de oportunitate sunt determinate de sistemul de operare și de caracteristicile unității. În cazul unei pene de curent, toate datele din buffer se vor pierde.

Există o serie de sarcini în care trebuie să vă asigurați că modificările din fișier sunt scrise pe unitate și nu se află într-un buffer intermediar. Această asigurare poate fi obținută utilizând apelul de sistem fsync compatibil cu POSIX. Apelul fsync forțează o scriere din buffer pe unitate.

Să demonstrăm efectul bufferelor cu un exemplu artificial sub forma unui scurt program 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 succesiunea acțiunilor din program. Textul „răspunsul la întrebarea principală a vieții, universul și toate acestea” va fi tamponat de sistemul de operare, iar dacă reporniți serverul apăsând butonul Reset în timpul „calculelor”, fișierul va fi gol. În exemplul nostru, pierderea textului nu este o problemă, așa că fsync nu este necesar. Bazele de date nu împărtășesc acest optimism.

Bazele de date sunt programe complexe care funcționează cu mai multe fișiere în același timp, așa că vor să fie siguri că datele pe care le scriu vor fi stocate pe unitate, deoarece de aceasta depinde consistența datelor din baza de date. Bazele de date sunt concepute pentru a înregistra toate tranzacțiile finalizate și pentru a fi pregătite pentru o întrerupere de curent în orice moment. Acest comportament vă obligă să utilizați fsync în mod constant în cantități mari.

Ce afectează utilizarea frecventă a fsync

Cu I/O normale, sistemul de operare încearcă să optimizeze comunicarea discului, deoarece unitățile externe sunt cele mai lente din ierarhia memoriei. Prin urmare, sistemul de operare încearcă să scrie cât mai multe date posibil într-un singur acces la unitate.

Să demonstrăm impactul utilizării fsync cu un exemplu specific. Avem următoarele SSD-uri ca subiecte de testare:

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

Testele sunt efectuate pe un Intel® Xeon® W-2255 care rulează Ubuntu 20.04. Pentru a testa discurile, se folosește sysbench 1.0.18. Discurile au o singură partiție formatată ca ext4. Pregătirea pentru test este să creați fișiere de 100 GB:

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

Executarea 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+

Citiți fără fsync, MiB/s
5734.89
9028.86

Scrieți fără fsync, MiB/s
3823.26
6019.24

Citirea cu fsync, MiB/s
37.76
3.27

Înregistrare cu fsync, MiB/s
25.17
2.18

Este ușor de observat că NVMe din segmentul de clienți conduce cu încredere atunci când sistemul de operare însuși decide cum să lucreze cu discuri și pierde atunci când este utilizat fsync. Acest lucru ridică două întrebări:

  1. De ce viteza de citire depășește lățimea de bandă fizică a conexiunii în test fără fsync?
  2. De ce un SSD cu segment de server este mai bine să gestioneze un număr mare de solicitări fsync?

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

Dacă puneți la îndoială toate rezultatele sysbench, atunci puteți utiliza 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+

Citiți fără fsync, MiB/s
45.5
178

Scrieți fără fsync, MiB/s
30.4
119

Citirea cu fsync, MiB/s
32.6
20.9

Înregistrare cu fsync, MiB/s
21.7
13.9

Tendința către scăderea performanței în NVMe atunci când utilizați fsync este clar vizibilă. Puteți trece la a doua întrebare.

Optimizare sau bluff

Mai devreme am spus că datele sunt stocate într-un buffer, dar nu am specificat în care, deoarece nu era important. Nici acum nu vom aprofunda în complexitatea sistemelor de operare și nu vom evidenția două tipuri generale de buffere:

  • program;
  • hardware.

Buffer-ul software se referă la tampoanele care se află în sistemul de operare, iar tamponul hardware se referă la memoria volatilă a controlerului de disc. Apelul de sistem fsync trimite o comandă către unitate pentru a scrie date din buffer-ul său în memoria principală, dar nu are nicio modalitate de a controla execuția corectă a comenzii.

Deoarece SSD-ul funcționează mai bine, se pot face două ipoteze:

  • discul este proiectat pentru o încărcare de un plan similar;
  • discul „cacealma” și ignoră comanda.

Comportamentul necinstit al unității poate fi observat dacă efectuați un test cu o pană de curent. Puteți verifica acest lucru cu un script. discchecker.pl, care era creat în anul 2005.

Acest script necesită două mașini fizice - „server” și „client”. Clientul scrie o cantitate mică de date pe unitatea testată, apelează fsync și trimite serverului informații despre ceea ce a fost scris.

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

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

După rularea scriptului, este necesar să dezactivați „clientul” și să nu reveniți la alimentare timp de câteva minute. Este important să deconectați subiectul de testat de la electricitate și nu doar să efectuați o oprire puternică. După ceva timp, serverul poate fi conectat și încărcat în sistemul de operare. După pornirea sistemului de operare, trebuie să porniți din nou discchecker.pl, dar cu un argument verifica.

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

La sfârșitul verificării, veți vedea numărul de erori. Dacă sunt 0, atunci discul a trecut testul. Pentru a exclude o combinație de circumstanțe care are succes pentru disc, experimentul poate fi repetat de mai multe ori.

S4500-ul nostru nu a prezentat erori de pierdere a puterii, ceea ce înseamnă că este pregătit pentru încărcări cu o mulțime de apeluri fsync.

Concluzie

Atunci când alegeți discuri sau configurații întregi gata făcute, ar trebui să aveți în vedere specificul sarcinilor care trebuie rezolvate. La prima vedere, pare evident că NVMe, adică un SSD cu interfață PCIe, este mai rapid decât un SSD SATA „clasic”. Cu toate acestea, așa cum am înțeles astăzi, în condiții specifice și cu anumite sarcini, acest lucru poate să nu fie cazul.

Cum testați componentele serverului când închiriați de la un furnizor IaaS?
Vă așteptăm în comentarii.

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

Sursa: www.habr.com

Adauga un comentariu