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

Në këtë artikull, ne do të shqyrtojmë disa nga nuancat e nënsistemit I / O dhe ndikimin e tyre në performancën.

Disa javë më parë u përballa me një pyetje pse NVMe në një server është më i ngadalshëm se SATA në një tjetër. Shikova karakteristikat e serverëve dhe kuptova se ishte një pyetje mashtrimi: NVMe ishte nga segmenti i përdoruesve dhe SSD ishte nga segmenti i serverit.

Natyrisht, nuk është e saktë të krahasohen produkte nga segmente të ndryshme në mjedise të ndryshme, por kjo nuk është një përgjigje teknike shteruese. Ne do të studiojmë bazat, do të kryejmë eksperimente dhe do t'i përgjigjemi pyetjes së parashtruar.

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

Për të përshpejtuar punën me disqet, të dhënat ruhen në tampon, domethënë ruhen në memorie të paqëndrueshme derisa të shfaqet një mundësi e përshtatshme për të ruajtur përmbajtjen e tamponit në disk. Kriteret e mundësisë përcaktohen nga sistemi operativ dhe karakteristikat e diskut. Në rast të një ndërprerjeje të energjisë, të gjitha të dhënat në tampon do të humbasin.

Ekzistojnë një numër detyrash në të cilat duhet të siguroheni që ndryshimet në skedar janë shkruar në disk dhe nuk qëndrojnë në një tampon të ndërmjetëm. Kjo siguri mund të merret duke përdorur thirrjen e sistemit fsync në përputhje me POSIX. Thirrja fsync detyron një shkrim nga buffer në diskun.

Le të demonstrojmë efektin e buferëve me një shembull artificial në formën e një programi të shkurtër 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ë fshihet nga sistemi operativ dhe nëse rinisni serverin duke shtypur butonin Reset gjatë "llogaritjeve", skedari do të jetë bosh. Në shembullin tonë, humbja e tekstit nuk është problem, kështu që fsync nuk është i nevojshëm. Bazat e të dhënave nuk e ndajnë këtë optimizëm.

Bazat e të dhënave janë programe komplekse që punojnë me shumë skedarë në të njëjtën kohë, kështu që ata duan të jenë të sigurt se të dhënat që shkruajnë do të ruhen në disk, pasi konsistenca e të dhënave brenda bazës së të dhënave varet nga kjo. Bazat e të dhënave janë krijuar për të regjistruar të gjitha transaksionet e përfunduara dhe për të qenë gati për një ndërprerje të energjisë në çdo moment. Kjo sjellje ju detyron të përdorni fsync vazhdimisht në sasi të mëdha.

Çfarë ndikon në përdorimin e shpeshtë të fsync

Me I/O normale, sistemi operativ përpiqet të optimizojë komunikimin e diskut, pasi disqet e jashtme janë më të ngadaltë në hierarkinë e memories. Prandaj, sistemi operativ përpiqet të shkruajë sa më shumë të dhëna të jetë e mundur në një qasje në disk.

Le të demonstrojmë ndikimin e përdorimit të fsync me një shembull specifik. Ne kemi SSD-të e mëposhtme si lëndë testimi:

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

Testet kryhen në një sistem operativ Intel® Xeon® W-2255. Ubuntu 20.04 Prill. Sysbench 1.0.18 u përdor për testimin e diskut. Një ndarje e vetme, e formatuar si ext4, u krijua në disqe. Përgatitja për testin përfshin krijimin e skedarëve 100 GB:

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

Testet e vrapimit:

# Без 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 testit janë paraqitur në tabelë.

Provë
Intel® S4500
Samsung 970 EVO+

Lexo pa fsync, MiB/s
5734.89
9028.86

Shkruani pa fsync, MiB/s
3823.26
6019.24

Leximi me fsync, MiB/s
37.76
3.27

Regjistrimi me fsync, MiB/s
25.17
2.18

Është e lehtë të shihet se NVMe nga segmenti i klientit udhëheq me besim kur vetë sistemi operativ vendos se si të punojë me disqe, dhe humbet kur përdoret fsync. Kjo ngre dy pyetje:

Pse shpejtësia e leximit tejkalon gjerësinë e brezit fizik të lidhjes në test pa fsync?
Pse një segment i serverit SSD është më i mirë në trajtimin e një numri të madh kërkesash fsync?

Përgjigja për pyetjen e parë është e thjeshtë: sysbench gjeneron skedarë të mbushur me zero. Kështu, testi u krye mbi 100 gigabajt zero. Meqenëse të dhënat janë shumë uniforme dhe të parashikueshme, optimizimet e ndryshme të sistemit operativ hyjnë në lojë dhe ato shpejtojnë ndjeshëm ekzekutimin.

Nëse vini në dyshim të gjitha rezultatet e sysbench, atëherë 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

Provë
Intel® S4500
Samsung 970 EVO+

Lexo pa fsync, MiB/s
45.5
178

Shkruani pa fsync, MiB/s
30.4
119

Leximi me fsync, MiB/s
32.6
20.9

Regjistrimi me fsync, MiB/s
21.7
13.9

Tendenca drejt rënies së performancës në NVMe kur përdoret fsync është qartë e dukshme. Mund të vazhdoni me përgjigjen e pyetjes së dytë.

Optimizimi ose bllof

Më herët thamë se të dhënat ruhen në një tampon, por nuk specifikuam se në cilin, pasi nuk ishte i rëndësishëm. Edhe tani ne nuk do të gërmojmë në ndërlikimet e sistemeve operative dhe do të veçojmë dy lloje të përgjithshme të tamponëve:

program;
hardware.

Buferi i softuerit i referohet buferave që janë në sistemin operativ, dhe buferi i harduerit i referohet memorjes së paqëndrueshme të kontrolluesit të diskut. Thirrja e sistemit fsync dërgon një komandë në diskun për të shkruar të dhëna nga buferi i tij në ruajtjen kryesore, por nuk ka asnjë mënyrë për të kontrolluar ekzekutimin e saktë të komandës.

Meqenëse SSD funksionon më mirë, mund të bëhen dy supozime:

disku është projektuar për një ngarkesë të një plani të ngjashëm;
disku "bllof" dhe injoron komandën.

Sjellja e pandershme e diskut mund të vërehet nëse kryeni një provë me një ndërprerje të energjisë. Ju mund ta kontrolloni këtë me një skenar. diskchecker.pl, ajo ishte themeluar 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 nën provë, thërret fsync dhe i dërgon serverit informacione rreth asaj që është shkruar.

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

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

Pas ekzekutimit të skenarit, është e nevojshme të çaktivizoni "klientin" dhe të mos e ktheni energjinë për disa minuta. Është e rëndësishme të shkëputni subjektin e testimit nga energjia elektrike dhe jo vetëm të kryeni një mbyllje të fortë. Pas ca kohësh, serveri mund të lidhet dhe të ngarkohet në OS. Pas nisjes së OS, duhet të filloni përsëri diskchecker.pl, por me argument verifikoj.

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

Në fund të kontrollit, do të shihni numrin e gabimeve. Nëse ato janë 0, atëherë disku e kaloi testin. Për të përjashtuar një kombinim rrethanash që është i suksesshëm për diskun, eksperimenti mund të përsëritet disa herë.

S4500 ynë nuk tregoi gabime në humbjen e energjisë, që do të thotë se është gati për ngarkesa me shumë telefonata fsync.

Përfundim

Kur zgjidhni disqe ose konfigurime të tëra të gatshme, duhet të mbani parasysh specifikat e detyrave që duhet të zgjidhen. Në pamje të parë, duket e qartë se NVMe, domethënë një SSD me një ndërfaqe PCIe, është më i shpejtë se një SATA SSD "klasik". Megjithatë, siç e kemi kuptuar sot, në kushte specifike dhe me detyra të caktuara mund të mos jetë kështu.

Si i testoni komponentët e serverit kur merrni me qira nga një ofrues IaaS?
Ju presim në komente.

Burimi: www.habr.com