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

U ovom članku ćemo razmotriti neke nijanse podsustava ulaza-izlaza i njihov utjecaj na performanse.

Prije nekoliko tjedana suočio sam se s pitanjem zašto je NVMe na jednom serveru sporiji od SATA na drugom. Proučio sam karakteristike servera i shvatio da je to bila zamka: NVMe je bio iz korisničkog segmenta, dok je SSD bio iz servernog.

Očito je da nije ispravno uspoređivati proizvode iz različitih segmenata u različitim okruženjima, ali to nije iscrpan tehnički odgovor. Istražit ćemo osnove, provesti eksperimente i dati odgovor na postavljeno pitanje.

Što je fsync i gdje se koristi

Kako bi se ubrzao rad s pohranjivačima, podaci se predmemoriraju, tj. pohranjuju se u memoriji koja ovisi o energiji dok ne dođe zgodna prilika za spremanje sadržaja predmemorije na pohranu. Kriteriji za "ugodnu priliku" određuju operativni sustav i karakteristike pohrane. U slučaju nestanka struje, svi podaci u predmemoriji bit će izgubljeni.

Postoji niz zadataka u kojima je potrebno biti siguran da su promjene u datoteci zapisane na pohranu, a ne u međuspremniku. Ovu sigurnost možete dobiti korištenjem POSIX kompatibilnog sistemskog poziva fsync. Poziv fsync pokreće prisilno zapisivanje iz predmemorije na pohranu.

Demonstrirat ćemo utjecaj predmemorija umjetnim primjerom u obliku kratkog programa na jeziku 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;
}

Komentari dobro objašnjavaju slijed radnji u programu. Tekst "odgovor na glavno pitanje života, svemira i svega takvog" bit će predmemoriran od strane operativnog sustava, a ako resetirate server pritiskom na gumb Reset tijekom "izračuna", datoteka će biti prazna. U našem primjeru gubitak teksta nije problem, pa fsync nije potreban. Baze podataka ne dijele takav optimizam.

Baze podataka su složeni programi koji istovremeno rade s mnogim datotekama, pa žele biti sigurni da će podaci koje zapisuju biti sačuvani na pohrani, jer od toga ovisi konzistentnost podataka unutar Baze podataka. Baze podataka su dizajnirane da zapisuju sve završene transakcije i da budu spremne za isključivanje napajanja u bilo kojem trenutku. Ovakvo ponašanje zahtijeva stalnu upotrebu fsync-a u velikim količinama.

Kako često korištenje fsync utječe na performanse

Prilikom uobičajenog ulaza-izlaza, operacijski sustav pokušava optimizirati komunikaciju s diskovima, jer su vanjski uređaji najspori u hijerarhiji memorije. Stoga operacijski sustav nastoji zapisati što više podataka u jednom pristupu uređaju.

Prikazat ćemo utjecaj korištenja fsync na konkretnom primjeru. Kao ispitanici imamo sljedeće SSD-ove:

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

Testovi se provode na Intel® Xeon® W-2255 s operacijskim sustavom Ubuntu 20.04. Za testiranje diskova koristi se sysbench 1.0.18. Na diskovima je stvoren jedan particija formatirana kao ext4. Priprema za test uključuje kreiranje datoteka ukupne veličine 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 testova prikazani su u tablici.

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 s fsync, MiB/s
37.76
3.27

Pisanje s fsync, MiB/s
25.17
2.18

Nije teško primijetiti da NVMe iz klijentskog segmenta uvjerljivo prednjači kada operacijski sustav odlučuje kako raditi s diskovima, ali gubi kada se koristi fsync. Ovdje se postavljaju dva pitanja:

1. Zašto u testu bez fsync brzina čitanja premašuje fizičku propusnost kanala?
2. Zašto SSD iz servernog segmenta bolje obrađuje velik broj fsync zahtjeva?

Odgovor na prvo pitanje je jednostavan: sysbench generira datoteke ispunjene nulama. Dakle, test je proveden na 100 gigabajta nula. Kako su podaci vrlo uniformni i predvidljivi, na snagu dolaze različite optimizacije OS-a koje značajno ubrzavaju izvršenje.

Ako sumnjate u sve rezultate sysbench-a, 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 s fsync, MiB/s
32.6
20.9

Pisanje s fsync, MiB/s
21.7
13.9

Trend smanjenja performansi kod NVMe-a pri korištenju fsync-a dobro se primjećuje. Možemo preći na odgovor na drugo pitanje.

Optimizacija ili zavaravanje

Ranije smo govorili da se podaci pohranjuju u međuspremniku, ali nismo precizirali u kojem točno, jer to nije bilo presudno. Ni sada nećemo ulaziti u pojedinosti operacijskih sustava, već ćemo istaknuti dva opća tipa međuspremnika:

• softverski;
• hardverski.

Pod programskom baferom podrazumijevaju se baferi u operativnom sustavu, dok je hardverski — energijom ovisna memorija kontrolera diska. Sistem poziv fsync šalje pohrani naredbu da zapiše podatke iz svog bafera u glavno skladište, ali nikako ne može kontrolirati ispravnost izvršenja naredbe.

Budući da SSD pokazuje bolje rezultate, može se izvesti dva pretpostavke:

• disk je dizajniran za opterećenje sličnog tipa;
• disk ‘blefira’ i ignorira naredbu.

Neispravno ponašanje pohrane može se primijetiti ako se provede test s nestankom napajanja. To se može provjeriti skriptom diskchecker.pl, koji je bio osnovan 2005. godine.

Ovaj skript zahtijeva dvije fizičke mašine — ‘server’ i ‘klijent’. Klijent zapisuje na testirani disk mali volumen podataka, poziva fsync i šalje serveru informacije o tome što je zapisano.

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

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

Nakon pokretanja skripta potrebno je isključiti ‘klijenta’ i ne vraćati napajanje nekoliko minuta. Važno je isključiti testiranog iz napajanja, a ne samo izvršiti tvrdo gašenje. Nakon nekog vremena server se može povezat i pokrenuti OS. Nakon pokretanja OS-a potrebno je ponovo pokrenuti diskchecker.pl, ali s argumentom verify.

.\/diskchecker.pl -s  verify

Na kraju provjere vidjet ćete broj grešaka. Ako ih je 0, to znači da je disk prošao ispitivanje. Da bi se isključila slučajnost za disk, test se može ponoviti nekoliko puta.

Naš S4500 nije pokazao greške prilikom gubitka napajanja, stoga se može tvrditi da je spreman za opterećenja s velikim brojem poziva fsync.

Zaključak

Prilikom odabira diskova ili cijelih gotovih konfiguracija treba imati na umu specifičnost zadataka koje treba riješiti. Na prvi pogled se čini očitim da je NVMe, odnosno SSD s PCIe sučeljem, brži od ‘klasičnog’ SATA SSD-a. Međutim, kao što smo shvatili danas, u specifičnim uvjetima i s određenim zadacima to može biti drugačije.

Kako vi testirate komponente servera prilikom najma kod IaaS pružatelja?
Čekamo vas u komentarima.

Izvor: habr.com