Kial mia NVMe estas pli malrapida ol SSD?

En ĉi tiu artikolo, ni rigardos kelkajn el la nuancoj de la I/O-subsistemo kaj ilian efikon al rendimento.

Antaŭ kelkaj semajnoj mi renkontis demandon, kial NVMe sur unu servilo estas pli malrapida ol SATA sur alia. Mi rigardis la karakterizaĵojn de la serviloj kaj rimarkis, ke ĝi estas ruza demando: NVMe estis de la uzantsegmento, kaj SSD estis de la servila segmento.

Evidente, ne estas ĝuste kompari produktojn de malsamaj segmentoj en malsamaj medioj, sed ĉi tio ne estas ĝisfunda teknika respondo. Ni studos la bazojn, faros eksperimentojn kaj donos respondon al la starigita demando.

Kio estas fsync kaj kie ĝi estas uzata

Por akceli laboron kun diskoj, datumoj estas bufritaj, tio estas, stokitaj en volatila memoro ĝis oportuna okazo prezentiĝas por konservi la enhavon de la bufro al la disko. Ŝancaj kriterioj estas determinitaj de la mastruma sistemo kaj veturilkarakterizaĵoj. Okaze de elektropaneo, ĉiuj datumoj en la bufro estos perditaj.

Estas kelkaj taskoj en kiuj vi devas esti certa, ke la ŝanĝoj en la dosiero estas skribitaj al la disko, kaj ne kuŝas en meza bufro. Ĉi tiu certigo povas esti akirita uzante la POSIX-konforman fsync sistemvokon. La fsync-voko devigas skribon de la bufro al la stirado.

Ni pruvu la efikon de bufroj kun artefarita ekzemplo en formo de mallonga C-programo.

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

Komentoj bone klarigas la sinsekvon de agoj en la programo. La teksto "la respondo al la ĉefa demando pri la vivo, la universo kaj ĉio tio" estos bufrita de la operaciumo, kaj se vi rekomencos la servilon premante la butonon Restarigi dum "kalkuloj", la dosiero estos malplena. En nia ekzemplo, tekstperdo ne estas problemo, do fsync ne necesas. Datumbazoj ne kunhavas ĉi tiun optimismon.

Datumbazoj estas kompleksaj programoj, kiuj funkcias kun multaj dosieroj samtempe, do ili volas certigi, ke la datumoj, kiujn ili skribas, estos konservitaj sur la disko, ĉar de tio dependas la konsistenco de datumoj ene de la datumbazo. La datumbazoj estas dizajnitaj por registri ĉiujn finitajn transakciojn kaj esti pretaj por elektropaneo en ajna momento. Ĉi tiu konduto devigas vin uzi fsync konstante en grandaj kvantoj.

Kio influas la oftan uzon de fsync

Kun normala I/O, la operaciumo provas optimumigi disko-komunikadon, ĉar eksteraj diskoj estas la plej malrapidaj en la memorhierarkio. Tial, la operaciumo provas skribi tiom da datumoj kiel eble en unu aliro al la stirado.

Ni pruvu la efikon de uzado de fsync kun specifa ekzemplo. Ni havas la sekvajn SSD-ojn kiel testbjektojn:

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

Testoj estas faritaj sur Intel® Xeon® W-2255 funkcianta Ubuntu 20.04. Por testi diskojn, sysbench 1.0.18 estas uzata. La diskoj havas ununuran subdiskon formatitan kiel ext4. Prepari por la testo estas krei 100 GB-dosierojn:

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

Kurado de provoj:

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

La testrezultoj estas prezentitaj en la tabelo.

Testo
Intel® S4500
Samsung 970 EVO+

Legu sen fsync, MiB/s
5734.89
9028.86

Skribu sen fsync, MiB/s
3823.26
6019.24

Legado per fsync, MiB/s
37.76
3.27

Registrado kun fsync, MiB/s
25.17
2.18

Estas facile vidi, ke NVMe de la klienta segmento memfide kondukas kiam la operaciumo mem decidas kiel labori kun diskoj, kaj perdas kiam fsync estas uzata. Ĉi tio levas du demandojn:

1. Kial la legada rapido superas la fizikan bendolarĝon de la ligo en la testo sen fsync?
2. Kial servila segmento SSD pli bonas pritrakti grandan nombron da fsync-petoj?

La respondo al la unua demando estas simpla: sysbench generas nulplenajn dosierojn. Tiel, la provo estis efektivigita pli ol 100 gigabajtoj da nuloj. Ĉar la datumoj estas tre unuformaj kaj antaŭvideblaj, diversaj OS-optimumigoj ekludas, kaj ili signife akcelas la ekzekuton.

Se vi pridubas ĉiujn rezultojn de sysbench, tiam vi povas uzi 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

Testo
Intel® S4500
Samsung 970 EVO+

Legu sen fsync, MiB/s
45.5
178

Skribu sen fsync, MiB/s
30.4
119

Legado per fsync, MiB/s
32.6
20.9

Registrado kun fsync, MiB/s
21.7
13.9

La tendenco al rendimento falo en NVMe kiam vi uzas fsync estas klare videbla. Vi povas pluiri al la dua demando.

Optimumigo aŭ blufo

Antaŭe ni diris, ke la datumoj estas konservitaj en bufro, sed ne specifis en kiu, ĉar ĝi ne estis grava. Eĉ nun ni ne enprofundiĝos en la komplikaĵojn de operaciumoj kaj eligos du ĝeneralajn specojn de bufroj:

• programo;
• aparataro.

La softvarbufro rilatas al la bufroj kiuj estas en la operaciumo, kaj la hardvarbufro rilatas al la volatila memoro de la diskregilo. La fsync-sistemvoko sendas komandon al la stirado por skribi datumojn de sia bufro al la ĉefa stokado, sed ĝi ne havas manieron kontroli la ĝustan ekzekuton de la komando.

Ĉar la SSD funkcias pli bone, du supozoj povas esti faritaj:

• la disko estas desegnita por ŝarĝo de simila plano;
• la disko "blufas" kaj ignoras la komandon.

Malhonesta konduto de la stirado povas esti rimarkita se vi faras teston kun elektropaneo. Vi povas kontroli ĉi tion per skripto. diskchecker.pl, kiu estis kreita en 2005 jaro.

Ĉi tiu skripto postulas du fizikajn maŝinojn - "servilo" kaj "kliento". La kliento skribas malgrandan kvanton da datumoj al la stirado sub testo, vokas fsync, kaj sendas al la servila informo pri kio estis skribita.

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

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

Post rulado de la skripto, necesas malenergigi la "klienton" kaj ne redoni potencon dum kelkaj minutoj. Gravas malkonekti la testsubjekton de elektro, kaj ne nur fari malmolan haltigon. Post iom da tempo, la servilo povas esti konektita kaj ŝarĝita en la OS. Post ekŝargo de la OS, vi devas komenci denove diskchecker.pl, sed kun argumento kontroli.

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

Ĉe la fino de la kontrolo, vi vidos la nombron da eraroj. Se ili estas 0, tiam la disko trapasis la teston. Por ekskludi kombinaĵon de cirkonstancoj sukcesa por la disko, la eksperimento povas esti ripetita plurajn fojojn.

Nia S4500 ne montris erarojn pri perdo de potenco, kio signifas, ke ĝi estas preta por ŝarĝoj kun multaj fsync-vokoj.

konkludo

Elektante diskojn aŭ tutajn pretajn agordojn, vi devas memori la specifojn de la taskoj, kiuj devas esti solvitaj. Unuavide, ŝajnas evidente, ke NVMe, tio estas, SSD kun interfaco PCIe, estas pli rapida ol "klasika" SATA SSD. Tamen, kiel ni komprenis hodiaŭ, en specifaj kondiĉoj kaj kun certaj taskoj tio eble ne estas la kazo.

Kiel vi testas servilojn dum luado de IaaS-provizanto?
Ni atendas vin en la komentoj.

fonto: www.habr.com