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

Në këtë artikull, ne do të shqyrtojmë disa nuanca të nënësisë së hyrjes-daljes dhe ndikimin e saj në performancë.

Disa javë më parë, u ndesha me pyetjen se pse NVMe në një server ishte më i ngadaltë se SATA në tjetrin. Kontrollova specifikimet e serverëve dhe kuptova se ishte një pyetje e ngatërruar: NVMe ishte nga segmenti përdorues, ndërsa SSD ishte nga segmenti i serverit.

Sigurisht, nuk është e drejtë të krahasosh produkte nga segmente të ndryshme në mjedise të ndryshme, por kjo nuk është një përgjigje teknike gjithëpërfshirëse. Le të studiojmë bazat, të zhvillojmë eksperimente dhe të japim një përgjigje për pyetjen e parashtruar.

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

Për të përshpejtuar punën me aksesorët, të dhënat buferizohen, domethënë ruhen në memorie që zhvillohet nga energjia për sa kohë që nuk paraqitet një rast i përshtatshëm për ruajtjen e përmbajtjes së buferit në aksesor. Kritere të rastit "të përshtatshëm" përcaktohen nga sistemi operativ dhe karakteristikat e aksesorëve. Në rast të mungesës së energjisë, të gjitha të dhënat në bufer do të humbasin.

Ekzistojnë disa detyra në të cilat është e nevojshme të jesh i sigurt se ndryshimet në një skedar janë të shkruara në aksesor, dhe nuk janë të ruajtura në bufer të ndërmjetëm. Kjo siguri mund të arrihet duke përdorur thirrjen sistemike fsync, e cila nxit një shkruarje të detyrueshme nga buferi në aksesor.

Do të demonstrojmë ndikimin e buferave me një shembull të thjeshtë 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 rindez serverin duke shtypur butonin Reset gjatë "llogaritjeve", skedari do të mbetet bosh. Në shembullin tonë, humbja e tekstit nuk është një problem, kështu që fsync nuk është e nevojshme. Baza të dhënash nuk ndajnë një optimizëm të tillë.

Të dhënat e bazës janë programe të komplikuara, që punojnë njëkohësisht me shumë skedare, kështu që duan të jenë të sigurt se të dhënat që shkruajnë do të ruhen në aksesor, sepse kjo ndikon në qëndrueshmërinë e të dhënave brenda BD-së. Baza të dhënash janë projektuar të shkruajnë të gjitha transaksionet e përfunduara dhe të jenë të gatshme për të humbur energjinë në çdo moment. Kjo sjell nevojën për të përdorur fsync shpesh në sasi të mëdha.

Si ndikon përdorimi i shpeshtë i fsync?

Në hyrjen-daljen e zakonshme, sistemi operativ përpiqet të optimizojë komunikimin me disqet, pasi në hierarkinë e memories, aksesorët e jashtëm janë më të ngadalshëm. Prandaj, sistemi operativ përpiqet që në një kërkesë për në aksesor të shkruajë sa më shumë të dhëna të jetë e mundur.

Do të demonstrojmë ndikimin e përdorimit të fsync me një shembull konkret. Kemi këta disqe SSD si subjekte të eksperimentit:

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 disqeve përdoret sysbench 1.0.18. Në disqe është krijuar një ndarje e formatizuar si ext4. Përgatitja për testin përfshin krijimin e skedarëve me një madhësi prej 100 GB:

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

Nisja e 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

Rezultatet e testeve janë paraqitur 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 përdoruesve është në krye të listës kur sistemi operativ vendos vetë se si të punojë me disqet, por humbet kur përdoret fsync. Nga kjo lindin dy pyetje:

Pse në testin pa fsync shpejtësia e leximit kalon kapacitetin fizik të kanaleve?
Pse SSD nga segmenti i serverit përpunon më mirë një mori kërkesash fsync?

Përgjigja për pyetjen e parë është e thjeshtë: sysbench gjeneron skedarë të mbushur me zero. Kështu, testi u zhvillua mbi 100 gigabajt zero. Duke qenë se të dhënat janë shumë të njëllojta dhe të parashikueshme, hyjnë në veprim optimizime të ndryshme të sistemit operativ, dhe ato e përshpejtojnë ndjeshëm ekzekutimin.

Nëse vërejtjet mbi rezultatet e sysbenchit janë të dyshimta, mund të përdorni 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

Trendi i rënies së performancës së NVMe gjatë përdorimit të fsync është i dukshëm. Mund të kalojmë në përgjigjen për pyetjen e dytë.

Optimizim apo mashtrim?

Më parë folëm se të dhënat ruhen në bufer, por nuk specifikuam se në cilin, pasi nuk ishte thelbësore. Edhe tani nuk do të thellohemi në hollësitë e sistemeve operative dhe do të dallojmë dy lloje të përgjithshme të buferave:

programor;
harduer.

Nën buferin e softuerit kuptojmë buferët që ekzistojnë në sistemin operativ, ndërsa nën buferin harduerik kuptojmë memorien e varur nga energjia të kontrolluesit të diskut. Thirrja në sistem fsync i dërgon diskut një komandë për të shkruar të dhënat nga buferi në ruajtjen kryesore, por nuk mund të kontrollojë saktësinë e ekzekutimit të komandës.

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

disku është projektuar për ngarkesa të tilla;
disku "blefon" dhe injoron komandën.

Sjellja e padrejtë e diskut mund të vërehet nëse kryhet një provë me humbjen e energjisë. Kjo mund të kontrollohet me skenarin diskchecker.pl, i cili ishte u krijua në vitin 2005.

Ky skenar kërkon dy makina fizike — "server" dhe "klient". Klienti shkruan një sasi të vogël të dhënash në diskun e testuar, thërret fsync dhe i dërgon serverit informacionin se çfarë është shkruar.

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

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

Pas nisjes së skenarit, është e nevojshme të shkëputet energjia nga "klienti" dhe të mos kthehet për disa minuta. Është e rëndësishme të shkëputet disku nga energjia, dhe jo thjesht të bëhet një ndalese e ashpër. Pas kalimit të disa çastesh, serveri mund të lidhet dhe të ngarkohet në OS. Pas ngarkimit të OS, është e nevojshme të përseritet diskchecker.pl, por me argumentin verify.

./diskchecker.pl -s  verify

Në fund të provës do të shihni numrin e gabimeve. Nëse ato janë 0, atëherë diskun e kaloi provimin. Për të përjashtuar fatin e mirë për diskun, eksperimenti mund të përsëritet disa herë.

S4500 ynë nuk tregoi gabime në humbjen e energjisë, pra mund të themi se ai është gati për ngarkesa me një numër të madh thirrjesh fsync.

Përfundimi

Kur zgjidhni disqe ose konfigurata të tëra të gatshme, duhet të mbani parasysh specifikën e detyrave që duhen zgjidhur. Në pamje të parë duket e qartë se NVMe, pra SSD me ndërfaqen PCIe, është më i shpejtë se SATA SSD "klasik". Megjithatë, 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 ofruesit IaaS?
Presim komentet tuaja.

Burimi: habr.com