Af hverju er NVMe minn hægari en SSD?

Í þessari grein munum við skoða nokkur blæbrigði I / O undirkerfisins og áhrif þeirra á frammistöðu.

Fyrir nokkrum vikum lenti ég í spurningu hvers vegna NVMe á einum netþjóni er hægari en SATA á öðrum. Ég skoðaði eiginleika netþjónanna og áttaði mig á því að þetta var bragðspurning: NVMe var frá notendahlutanum og SSD var frá miðlarahlutanum.

Augljóslega er ekki rétt að bera saman vörur frá mismunandi flokkum í mismunandi umhverfi, en þetta er ekki tæmandi tæknilegt svar. Við munum kynna okkur grunnatriðin, gera tilraunir og svara spurningunni.

Hvað er fsync og hvar er það notað

Til að flýta fyrir vinnu með drifum eru gögn í biðminni, það er geymd í rokgjörnu minni þar til hentugt tækifæri gefst til að vista innihald biðminni á drifinu. Tækifærisviðmið eru ákvörðuð af stýrikerfi og aksturseiginleikum. Komi til rafmagnsleysis tapast öll gögn í biðminni.

Það eru nokkur verkefni þar sem þú þarft að vera viss um að breytingarnar í skránni séu skrifaðar á drifið og liggi ekki í millibuffi. Þessa tryggingu er hægt að fá með því að nota POSIX-samhæft fsync kerfiskall. Fsync kallið þvingar fram skrif frá biðminni á drifið.

Sýnum fram á áhrif stuðpúða með tilbúnu dæmi í formi stutts C forrits.

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

Athugasemdir útskýra röð aðgerða í forritinu vel. Textinn „svarið við aðalspurningunni um lífið, alheiminn og allt það“ verður í biðminni af stýrikerfinu og ef þú endurræsir netþjóninn með því að ýta á Reset hnappinn meðan á „útreikningum stendur“ verður skráin tóm. Í okkar dæmi er textatap ekki vandamál, svo fsync er ekki þörf. Gagnagrunnar deila ekki þessari bjartsýni.

Gagnasöfn eru flókin forrit sem vinna með margar skrár á sama tíma, þannig að þeir vilja vera vissir um að gögnin sem þeir skrifa verði geymd á drifinu, þar sem samkvæmni gagna innan gagnagrunnsins fer eftir því. Gagnagrunnarnir eru hannaðir til að skrá öll lokin viðskipti og vera tilbúin fyrir rafmagnsleysi hvenær sem er. Þessi hegðun skyldar þig til að nota fsync stöðugt í miklu magni.

Hvað hefur áhrif á tíða notkun fsync

Með venjulegu I/O reynir stýrikerfið að hámarka disksamskipti, þar sem ytri drif eru hægust í minnisstigveldinu. Þess vegna reynir stýrikerfið að skrifa eins mikið af gögnum og mögulegt er í einum aðgangi að drifinu.

Við skulum sýna fram á áhrif þess að nota fsync með ákveðnu dæmi. Við höfum eftirfarandi SSD diska sem prófunaraðila:

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

Prófanir eru gerðar á Intel® Xeon® W-2255 sem keyrir Ubuntu 20.04. Til að prófa diska er sysbench 1.0.18 notað. Diskarnir eru með einni skipting sem er sniðin sem ext4. Undirbúningur fyrir prófið er að búa til 100 GB skrár:

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

Hlaupapróf:

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

Niðurstöður prófsins eru sýndar í töflunni.

Próf
Intel® S4500
Samsung 970 EVO+

Lesið án fsync, MiB/s
5734.89
9028.86

Skrifaðu án fsync, MiB/s
3823.26
6019.24

Lestur með fsync, MiB/s
37.76
3.27

Upptaka með fsync, MiB/s
25.17
2.18

Það er auðvelt að sjá að NVMe frá biðlarahlutanum leiðir örugglega þegar stýrikerfið sjálft ákveður hvernig á að vinna með diska og tapar þegar fsync er notað. Þetta vekur upp tvær spurningar:

1. Af hverju fer leshraði yfir líkamlega bandbreidd hlekksins í prófinu án fsync?
2. Af hverju er SSD netþjónahluti betri í að meðhöndla mikinn fjölda fsync beiðna?

Svarið við fyrstu spurningunni er einfalt: sysbench býr til núllfylltar skrár. Þannig var prófið framkvæmt yfir 100 gígabætum af núllum. Þar sem gögnin eru mjög einsleit og fyrirsjáanleg koma ýmsar stýrikerfisstillingar við sögu og þær flýta verulega fyrir framkvæmdinni.

Ef þú efast um allar niðurstöður sysbench, þá geturðu notað 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

Próf
Intel® S4500
Samsung 970 EVO+

Lesið án fsync, MiB/s
45.5
178

Skrifaðu án fsync, MiB/s
30.4
119

Lestur með fsync, MiB/s
32.6
20.9

Upptaka með fsync, MiB/s
21.7
13.9

Þróunin í átt að frammistöðulækkun í NVMe þegar fsync er notað er greinilega sýnileg. Þú getur haldið áfram að seinni spurningunni.

Hagræðing eða blöff

Áður sögðum við að gögnin væru geymd í biðminni, en tilgreindum ekki í hvaða, þar sem það var ekki mikilvægt. Jafnvel núna munum við ekki kafa ofan í ranghala stýrikerfa og útgreina tvær almennar gerðir biðminni:

• forrit;
• vélbúnaður.

Hugbúnaðarbiðminnið vísar til biðminni sem eru í stýrikerfinu og vélbúnaðarbiðminnið vísar til rokgjarns minnis diskastýringarinnar. Fsync kerfiskallið sendir skipun til drifsins um að skrifa gögn úr biðminni þess í aðalgeymsluna, en það hefur enga leið til að stjórna réttri framkvæmd skipunarinnar.

Þar sem SSD skilar betri árangri er hægt að gera tvær forsendur:

• diskurinn er hannaður fyrir álag af svipaðri áætlun;
• diskurinn "bluffar" og hunsar skipunina.

Hægt er að taka eftir óheiðarlegri hegðun drifsins ef þú framkvæmir próf með rafmagnsleysi. Þú getur athugað þetta með handriti. diskchecker.pl, það var búin til í 2005 ári.

Þetta handrit krefst tveggja líkamlegra véla - „þjónn“ og „viðskiptavinur“. Viðskiptavinurinn skrifar lítið magn af gögnum á drifið sem verið er að prófa, kallar fsync og sendir þjóninum upplýsingar um það sem var skrifað.

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

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

Eftir að hafa keyrt handritið er nauðsynlegt að gera „viðskiptavininn“ af orku og ekki skila afli í nokkrar mínútur. Mikilvægt er að aftengja prófunaraðilann rafmagni en ekki bara framkvæma harða lokun. Eftir nokkurn tíma er hægt að tengja þjóninn og hlaða honum inn í stýrikerfið. Eftir að stýrikerfið hefur verið ræst þarftu að byrja aftur diskchecker.pl, en með rökum staðfesta.

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

Í lok athugunarinnar muntu sjá fjölda villna. Ef þeir eru 0, þá stóðst diskurinn prófið. Til að útiloka samsetningu aðstæðna sem heppnast fyrir diskinn er hægt að endurtaka tilraunina nokkrum sinnum.

S4500 okkar sýndi engar villur vegna rafmagnsleysis, sem þýðir að það er tilbúið fyrir álag með fullt af fsync símtölum.

Ályktun

Þegar þú velur diska eða heilar tilbúnar stillingar ættirðu að hafa í huga sérstöðu verkefna sem þarf að leysa. Við fyrstu sýn virðist augljóst að NVMe, það er SSD með PCIe tengi, er hraðari en „klassísk“ SATA SSD. Hins vegar, eins og við höfum skilið í dag, getur það ekki verið raunin við sérstakar aðstæður og við ákveðin verkefni.

Hvernig prófar þú miðlaraíhluti þegar þú leigir frá IaaS þjónustuaðila?
Við bíðum eftir þér í athugasemdunum.

Heimild: www.habr.com