Zašto je moj NVMe sporiji od SSD-a?

U ovom članku ćemo pogledati neke od nijansi I/O podsistema i njihov utjecaj na performanse.

Prije nekoliko sedmica naišao sam na pitanje zašto je NVMe na jednom serveru sporiji od SATA na drugom. Pogledao sam karakteristike servera i shvatio da je to trik pitanje: NVMe je iz segmenta korisnika, a SSD iz segmenta servera.

Očigledno, nije korektno uspoređivati ​​proizvode iz različitih segmenata u različitim okruženjima, ali ovo nije iscrpan tehnički odgovor. Proučavat ćemo osnove, provoditi eksperimente i dati odgovor na postavljeno pitanje.

Šta je fsync i gdje se koristi

Da bi se ubrzao rad sa diskovima, podaci se baferuju, odnosno pohranjuju u nestabilnu memoriju sve dok se ne ukaže zgodna prilika da se sadržaj bafera sačuva na disk jedinici. Kriterijumi mogućnosti određuju operativni sistem i karakteristike pogona. U slučaju nestanka struje, svi podaci u međuspremniku će biti izgubljeni.

Postoji niz zadataka u kojima morate biti sigurni da su promjene u datoteci upisane na disk jedinicu i da ne leže u međubaferu. Ovo osiguranje se može dobiti korištenjem POSIX-kompatibilnog fsync sistemskog poziva. Poziv fsync prisiljava upisivanje iz bafera u disk jedinicu.

Hajde da demonstriramo efekat bafera na veštačkom primeru u obliku kratkog C programa.

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

Komentari dobro objašnjavaju redoslijed radnji u programu. Tekst „odgovor na glavno pitanje života, univerzuma i svega toga“ će biti baferovan od strane operativnog sistema, a ako ponovo pokrenete server pritiskom na dugme Reset tokom „kalkulacija“, fajl će biti prazan. U našem primjeru gubitak teksta nije problem, tako da fsync nije potreban. Baze podataka ne dijele ovaj optimizam.

Baze podataka su složeni programi koji rade sa više datoteka u isto vrijeme, pa žele biti sigurni da će podaci koje pišu biti pohranjeni na drajv, budući da konzistentnost podataka unutar baze podataka ovisi o tome. Baze podataka su dizajnirane da bilježe sve izvršene transakcije i budu spremne za nestanak struje u svakom trenutku. Ovo ponašanje vas obavezuje da stalno koristite fsync u velikim količinama.

Šta utiče na čestu upotrebu fsync-a

Sa normalnim I/O, operativni sistem pokušava da optimizuje komunikaciju diska, pošto su eksterni diskovi najsporiji u hijerarhiji memorije. Stoga operativni sistem pokušava da upiše što više podataka u jednom pristupu disku.

Hajde da demonstriramo uticaj korišćenja fsync na konkretnom primeru. Imamo sljedeće SSD-ove kao ispitanike:

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

Testovi se sprovode na Intel® Xeon® W-2255 koji koristi Ubuntu 20.04. Za testiranje diskova koristi se sysbench 1.0.18. Diskovi imaju jednu particiju formatiranu kao ext4. Priprema za test je kreiranje fajlova od 100 GB:

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

Pokretanje testova:

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

Rezultati ispitivanja prikazani su u tabeli.

Test
Intel® S4500
Samsung 970 EVO+

Čitanje bez fsync, MiB/s
5734.89
9028.86

Pisanje bez fsync, MiB/s
3823.26
6019.24

Čitanje uz fsync, MiB/s
37.76
3.27

Snimanje uz fsync, MiB/s
25.17
2.18

Lako je uočiti da NVMe iz segmenta klijenata pouzdano vodi kada sam operativni sistem odlučuje kako će raditi sa diskovima, a gubi kada se koristi fsync. Ovo otvara dva pitanja:

1. Zašto brzina čitanja premašuje fizičku propusnost veze u testu bez fsync-a?
2. Zašto je SSD segment servera bolji u rukovanju velikim brojem fsync zahtjeva?

Odgovor na prvo pitanje je jednostavan: sysbench generiše fajlove koji nisu ispunjeni nulom. Tako je test obavljen preko 100 gigabajta nula. Budući da su podaci vrlo ujednačeni i predvidljivi, dolaze u obzir razne optimizacije OS-a koje značajno ubrzavaju izvođenje.

Ako dovodite u pitanje sve rezultate sysbench-a, onda možete koristiti 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+

Čitanje bez fsync, MiB/s
45.5
178

Pisanje bez fsync, MiB/s
30.4
119

Čitanje uz fsync, MiB/s
32.6
20.9

Snimanje uz fsync, MiB/s
21.7
13.9

Jasno je vidljiv trend pada performansi u NVMe kada se koristi fsync. Možete preći na drugo pitanje.

Optimizacija ili blef

Ranije smo rekli da se podaci pohranjuju u bafer, ali nismo precizirali u koji, jer to nije važno. Čak ni sada nećemo ulaziti u zamršenosti operativnih sistema i izdvajati dvije opće vrste bafera:

• program;
• hardver.

Softverski bafer se odnosi na bafere koji se nalaze u operativnom sistemu, a hardverski bafer se odnosi na nestabilnu memoriju kontrolera diska. Sistemski poziv fsync šalje naredbu pogonu za pisanje podataka iz njegovog bafera u glavnu memoriju, ali nema načina da kontrolira ispravno izvršenje naredbe.

Budući da SSD radi bolje, mogu se napraviti dvije pretpostavke:

• disk je dizajniran za opterećenje sličnog plana;
• disk "blefira" i ignoriše komandu.

Nepošteno ponašanje pogona može se primijetiti ako izvršite test sa nestankom struje. Ovo možete provjeriti pomoću skripte. diskchecker.pl, to je bilo kreirao u 2005 godine.

Ova skripta zahtijeva dvije fizičke mašine - "server" i "client". Klijent upisuje malu količinu podataka na disk koji se testira, poziva fsync i šalje serveru informacije o tome šta je napisano.

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

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

Nakon pokretanja skripte, potrebno je isključiti „klijent“ i ne vraćati napajanje nekoliko minuta. Važno je isključiti ispitanika iz struje, a ne samo izvršiti teško gašenje. Nakon nekog vremena, server se može povezati i učitati u OS. Nakon pokretanja OS-a, morate ponovo pokrenuti diskchecker.pl, ali sa argumentom verifikuj.

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

Na kraju provjere vidjet ćete broj grešaka. Ako su 0, disk je prošao test. Da bi se isključila kombinacija okolnosti koja je uspješna za disk, eksperiment se može ponoviti nekoliko puta.

Naš S4500 nije pokazao greške u gubitku energije, što znači da je spreman za opterećenja s puno fsync poziva.

zaključak

Prilikom odabira diskova ili čitavih gotovih konfiguracija, treba imati na umu specifičnosti zadataka koje treba riješiti. Na prvi pogled se čini očiglednim da je NVMe, odnosno SSD sa PCIe interfejsom, brži od "klasičnog" SATA SSD-a. Međutim, kako smo danas shvatili, u specifičnim uslovima i sa određenim zadacima to možda nije slučaj.

Kako testirate serverske komponente kada iznajmljujete od IaaS provajdera?
Čekamo vas u komentarima.

izvor: www.habr.com