🥇Pse NVMe im është më i ngadalshëm se SSD?

Në këtë artikull do të shqyrtojmë disa nuanca të nën-sistemit të hyrjes-daljes dhe ndikimin e tyre në performancë.

Disa javë më parë, u përballa me pyetjen se pse NVMe në një server ishte më i ngadalshëm se SATA në një tjetër. Shikova specifikat e serverëve dhe e kuptova se ishte një pyetje me kurth: NVMe ishte nga segmenti i përdoruesve, ndërsa SSD ishte nga segmenti i serverëve.

Është e qartë që krahasimi i produkteve nga segmente të ndryshme në një ambient të ndryshëm është i gabuar, por kjo nuk është një përgjigje teknike përfundimtare. Le të shqyrtojmë bazat, të zhvillojmë eksperimente dhe të japim një përgjigje për pyetjen e ngritur.

Çfarë është fsync dhe ku përdoret ai?

Për të përshpejtuar punën me ndërlikuesit, të dhënat buferizohen, dmth ruajnë në kujtesën e varur nga energjia deri sa të ketë një rast të përshtatshëm për të ruajtur përmbajtjen e buferit në ndërlikues. Kritere të "rastit të përshtatshëm" përcaktohen nga sistemi operativ dhe karakteristikat e ndërlikuesit. Në rast të ndërprerjes së energjisë, të dhënat e gjitha në bufer do të humbasin.

Ekziston një sërë detyrash, ku është e nevojshme të jesh i sigurt se ndryshimet në një skedar janë shkruar në ndërlikues, dhe jo të qëndrojnë në buferin ndërmjetës. Kjo siguri mund të arrihet duke përdorur thirrjen sistemore fsync, që iniciaton shkrimin e detyrueshëm nga buferi në ndërlikues.

Do të demonstrojmë ndikimin e buferëve me një shembull artificial në formën e një programi të shkurtër në gjuhën 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;
}

Komentet shpjegojnë mirë sekuencën e veprimeve në program. Teksti "përgjigja për pyetjen kryesore të jetës, universit dhe gjithçkaje" do të buferizohet nga sistemi operativ, dhe nëse rindizni serverin duke shtypur butonin Reset gjatë "llogaritjeve", skedari do të jetë bosh. Në shembullin tonë, humbja e tekstit nuk është një problem, prandaj fsync nuk është i nevojshëm. Bazat e të dhënave nuk ndajnë një optimizëm të tillë.

Bazat e të dhënave janë programe të ndërlikuara, që punojnë njëherazi me shumë skedarë, prandaj kanë nevojë të jenë të sigurta se të dhënat që shkruajnë do të ruhen në ndërlikues, pasi nga kjo varet konsistenca e të dhënave brenda DB. Bazat e të dhënave janë projektuar të regjistrojnë të gjitha transaksionet e përfunduara dhe të jenë gati për ndalimin e energjisë në çdo moment. Një sjellje e tillë detyron përdorimin e fsync vazhdimisht në sasi të mëdha.

Çfarë ndikon përdorimi i shpeshtë i fsync

Në inputin e zakonshëm dhe daljen, sistemi operativ përpiqet të optimizojë komunikimin me diskët, pasi në hierarkinë e memories, ruajtësit e jashtëm janë më të ngadalshëm. Prandaj, sistemi operativ përpiqet të regjistrojë sa më shumë të dhëna në një kërkesë për në ruajtës.

Do të demonstrojmë ndikimin e përdorimit të fsync në një shembull konkret. Si subjekt kemi këta ruajtës solidë:

Intel® DC SSD S4500 480 GB, i lidhur përmes SATA 3.2, 6 Gbit/s;
Samsung 970 EVO Plus 500GB, i lidhur përmes PCIe 3.0 x4, ~31 Gbit/s.

Testet kryhen në Intel® Xeon® W-2255 duke përdorur sistemin operativ Ubuntu 20.04. Për testimin e diskëve, përdoret sysbench 1.0.18. Në diskët është krijuar një pjesë, e formatuar si ext4. Përgatitja për testin përfshin krijimin e skedarëve me volum 100 GB:

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

Fillimi i testeve:

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

Të dhënat e testeve paraqiten në tabelë.

Test
Intel® S4500
Samsung 970 EVO+

Leximi pa fsync, MiB/s
5734.89
9028.86

Shkrimi pa fsync, MiB/s
3823.26
6019.24

Leximi me fsync, MiB/s
37.76
3.27

Shkrimi me fsync, MiB/s
25.17
2.18

Nuk është e vështirë të vëreni se NVMe nga segmenti i klientëve është në krye, kur sistemi operativ vendos si të punojë me diskët, dhe humbet kur përdoret fsync. Këtu lindin dy pyetje:

Përse në testin pa fsync shpejtësia e leximit kalon kapacitetin fizik të kanalit?
Përse SSD-të nga segmenti server janë më të afta të përballojnë një sasi të madhe kërkesash fsync?

Përgjigja në pyetjen e parë është e thjeshtë: sysbench gjeneron skedarë të mbushur me zero. Pra, testi u krye mbi 100 gigabajt zero. Duke qenë se të dhënat janë mjaft uniforme dhe të parashikueshme, optimizimet e ndryshme të sistemit operativ hyjnë në lojë dhe ato përshpejtojnë ndjeshëm ekzekutimin.

Nëse vërehet çdo rezultat i sysbench, atëherë mund të përdoret 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+

Leximi pa fsync, MiB/s
45.5
178

Shkrimi pa fsync, MiB/s
30.4
119

Leximi me fsync, MiB/s
32.6
20.9

Shkrimi me fsync, MiB/s
21.7
13.9

Tendenca për rënien e performancës së NVMe kur përdoret fsync është e dukshme. Mund të kalojmë te përgjigja e pyetjes së dytë.

Optimizimi apo mashtrimi

Më parë folëm se të dhënat ruhen në bufer, por nuk sqaruam se në cilin bufer, pasi kjo nuk ishte thelbësore. Dhe tani nuk do të thellohemi në detajet e sistemeve operative dhe do të përmendim dy lloje të përgjithshme të buferëve:

programor;
harduer.

Me bufere të programeve nënkuptojnë bufetë që ekzistojnë në sistemin operativ, ndërsa ato harduerike janë memorie e varur nga energjia e kontrollorit të disku. Thirrja sistemike fsync i dërgon pajisjes komandën për të shkruar të dhënat nga bufferi i saj në ruajtjen kryesore, por nuk ka mënyrë të kontrollojë saktësinë e ekzekutimit të komandës.

Duke qenë se SSD-të tregojnë rezultate më të mira, mund të bëhen dy supozime:

disku është projektuar për ngarkesa të këtij lloji;
disku "blef" dhe anashkalon komandën.

Shtypja e pavërtetë e pajisjes mund të vërehet nëse kryhet një test me humbje energjie. Kjo mund të kontrollohet me skriptin diskchecker.pl, që është krijuar krijua në vitin 2005.

Ky skript kërkon dy makina fizike — "server" dhe "klient". Klienti shkruan një sasi të vogël të dhënash në disqin e testuar, thërret fsync dhe dërgon informacionin në server rreth asaj që është shkruar.

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

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

Pas fillimit të skriptit, është e nevojshme të fikni "klientin" dhe të mos ktheheni energjinë për disa minuta. Është e rëndësishme të çaktivizohet testi nga energjia, jo thjesht të kryhet një fikje e ashpër. Pas një kohe, serveri mund të lidhet dhe ngarkohet në sistemin operativ. Pas ngarkimit të sistemit operativ, është e nevojshme të filloni përsëri diskchecker.pl, por me argumentin verify.

.\/diskchecker.pl -s  verify

Në fund të verifikimit do të shihni numrin e gabimeve. Nëse ato janë 0, atëherë disku e kaloi provimin. Për të përjashtuar një rast të favorshëm për disku, eksperimenti mund të përsëritet disa herë.

S4500 ynë nuk tregoi gabime në humbjen e energjisë, kështu që mund të konkludohet se ai është i gatshëm për ngarkesa me një numër të madh thirrjesh fsync.

Përfundim

Kur zgjidhni disqe ose konfigurime të tëra të gatshme, është e rëndësishme të mbani parasysh specifikën e detyrave që duhet të zgjidhen. Në pamje të parë, duket e qartë se NVMe, që është SSD me ndërfaqe PCIe, është më i shpejtë se SSD "klasik" SATA. Sidoqoftë, siç e kuptuam sot, në kushte specifike dhe me detyra të caktuara, kjo mund të mos jetë e vërtetë.

Si i testoni komponentët e serverëve kur i merrni me qira nga ofruesi IaaS?
Na pret në komente.

Burimi: habr.com