🥇Si të kontrolloni disqet me fio për performancë të mjaftueshme për etcd

Shënim. përkth.: Ky artikull është rezultat i një mini-kërkimi të kryer nga inxhinierët e IBM Cloud në kërkim të një zgjidhjeje për një problem real që lidhet me funksionimin e bazës së të dhënave etcd. Një detyrë e ngjashme ishte e rëndësishme për ne, megjithatë, rrjedha e reflektimeve dhe veprimeve të autorëve mund të jetë interesante në një kontekst më të gjerë.

Përmbledhje e shkurtër e të gjithë artikullit: fio dhe etj

Performanca e një grupi etcd varet shumë nga shpejtësia e ruajtjes themelore. etcd eksporton metrika të ndryshme të Prometheus për të monitoruar performancën. Një prej tyre është wal_fsync_duration_seconds. Në dokumentacionin për etj thuhetse ruajtja mund të konsiderohet mjaft e shpejtë nëse përqindja e 99-të e kësaj metrike nuk i kalon 10 ms…

Nëse po mendoni të konfiguroni një grup etjd në makinat Linux dhe dëshironi të provoni nëse disqet (siç janë disqet SSD) janë mjaft të shpejtë, ju rekomandojmë të përdorni testuesin popullor I/O të quajtur Fio. Mjafton të ekzekutoni komandën e mëposhtme (drejtoria test-data duhet të vendoset në ndarjen e montuar të diskut të testuar):

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Mbetet vetëm për të parë rezultatin dhe për të kontrolluar nëse përqindja e 99-të përshtatet fdatasync në 10 ms. Nëse po, atëherë disku juaj po punon mjaft shpejt. Këtu është një shembull i prodhimit:

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

Disa shënime:

Në shembullin e mësipërm, ne kemi rregulluar parametrat --size и --bs për një rast konkret. Për të marrë një rezultat domethënës nga fio, specifikoni vlerat e përshtatshme për rastin tuaj të përdorimit. Si t'i zgjidhni ato do të diskutohet më poshtë.
Vetëm gjatë testimit fio ngarkon nënsistemin e diskut. Në jetën reale, ka të ngjarë që procese të tjera të shkruajnë në disk (përveç atyre që lidhen me wal_fsync_duration_seconds). Kjo ngarkesë shtesë mund të rritet wal_fsync_duration_seconds. Me fjalë të tjera, nëse përqindja e 99-të nga testimi me fio, vetëm pak më pak se 10 ms, ka shumë mundësi që performanca e ruajtjes të mos jetë e mjaftueshme.
Për provën do t'ju duhet versioni fio jo më pak se 3.5, sepse versionet e vjetra nuk grumbullojnë rezultatet fdatasync në formën e përqindjeve.
Përfundimi i mësipërm është vetëm një fragment i vogël nga përfundimi i përgjithshëm fio.

Më shumë rreth fio dhe etj

Disa fjalë për WAL-të etj

Në përgjithësi, bazat e të dhënave përdorin prerje proaktive (Regjistrimi paraprak, WAL). ndikohet edhe etjd. Një diskutim i WAL është përtej qëllimit të këtij artikulli, por për qëllimet tona, ajo që duhet të dini është se çdo anëtar i grupit etcd ruan WAL në ruajtje të vazhdueshme. etcd shkruan disa operacione të ruajtjes së vlerës së çelësit (të tilla si përditësimet) në WAL përpara se t'i ekzekutojë ato. Nëse një nyje rrëzohet dhe riniset midis fotografive të çastit, etjd do të jetë në gjendje të rikuperojë transaksionet që nga fotografia e mëparshme bazuar në përmbajtjen e WAL.

Kështu, sa herë që një klient shton një çelës në dyqanin KV ose përditëson vlerën e një çelësi ekzistues, etjd shton përshkrimin e operacionit në WAL, i cili është një skedar i rregullt në dyqanin e vazhdueshëm. etjd DUHET të jetë 100% i sigurt se hyrja WAL është ruajtur në të vërtetë përpara se të vazhdoni. Për ta arritur këtë në Linux, nuk mjafton të përdorni thirrjen e sistemit write, pasi vetë operacioni i shkrimit në media fizike mund të vonohet. Për shembull, Linux mund të mbajë një hyrje në WAL në një memorie të fshehtë të kernelit në memorie (siç është cache e faqeve) për ca kohë. Për të siguruar që të dhënat të shkruhen në media, duhet të thirret një thirrje sistemi pas shkrimit fdatasync - kjo është pikërisht ajo që bën etcd (siç mund ta shihni në daljen e mëposhtme strace; Këtu 8 - Përshkruesi i skedarit WAL):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Fatkeqësisht, shkrimi në ruajtje të vazhdueshme kërkon pak kohë. Ekzekutimi i zgjatur i thirrjeve fdatasync mund të ndikojë në performancën e etcd. Në dokumentacionin e ruajtjes treguar, që për performancë të mjaftueshme është e nevojshme që përqindja e 99-të e kohëzgjatjes së të gjitha thirrjeve fdatasync kur shkrimi në një skedar WAL ishte më pak se 10 ms. Ka metrika të tjera të lidhura me ruajtjen, por ky artikull do të fokusohet në atë.

Vlerësimi i ruajtjes me fio

Mund të vlerësoni nëse një hapësirë ruajtëse e caktuar është e përshtatshme për t'u përdorur me etcd duke përdorur programin Fio - një testues popullor I/O. Mbani në mend se hyrje/dalja e diskut mund të ndodhë në mënyra të ndryshme: sinkronizimi/asinkronizimi, shumë klasa të ndryshme syscall etj. Ana tjetër e medaljes është ajo fio jashtëzakonisht e vështirë për t'u përdorur. Shërbimi ka shumë parametra, dhe kombinime të ndryshme të vlerave të tyre çojnë në rezultate krejtësisht të ndryshme. Për të marrë një vlerësim të arsyeshëm për etcd, duhet të siguroheni që ngarkesa e shkrimit e krijuar nga fio të jetë sa më afër ngarkesës së shkrimit të skedarit WAL të etcd:

Kjo do të thotë se të gjeneruara fio ngarkesa duhet të jetë të paktën një seri shkrimesh të njëpasnjëshme në skedar, ku çdo shkrim përbëhet nga një thirrje sistemi writee ndjekur nga fdatasync.
Për të aktivizuar shkrimin vijues, duhet të specifikoni flamurin --rw=write.
Që fio shkroi duke përdorur thirrje write (në vend të thirrjeve të tjera të sistemit - për shembull, pwrite), përdorni flamurin --ioengine=sync.
Më në fund, flamuri --fdatasync=1 siguron që çdo write duhet të fdatasync.
Dy parametrat e tjerë në shembullin tonë janë: --size и --bs - mund të ndryshojë në varësi të rastit specifik të përdorimit. Seksioni tjetër do të përshkruajë konfigurimin e tyre.

Pse zgjodhëm fio dhe si mësuam se si ta vendosnim atë

Ky shënim vjen nga një rast real që kemi hasur. Ne kishim një grup në Kubernetes v1.13 me monitorim në Prometheus. SSD-të u përdorën si ruajtje për etcd v3.2.24. Metrikat Etcd treguan vonesa shumë të larta fdatasync, edhe kur grupi ishte i papunë. Neve, këto metrika na dukeshin shumë të dyshimta dhe nuk ishim të sigurt se çfarë përfaqësonin saktësisht. Për më tepër, grupi përbëhej nga makina virtuale, kështu që nuk ishte e mundur të thuhej nëse vonesa ishte për shkak të virtualizimit apo fajin e kishte SSD.

Përveç kësaj, ne konsideruam ndryshime të ndryshme në konfigurimin e harduerit dhe softuerit, kështu që na duhej një mënyrë për t'i vlerësuar ato. Natyrisht, do të ishte e mundur të ekzekutohej etcd në çdo konfigurim dhe të shikoheshin metrikat përkatëse të Prometheus, por kjo do të kërkonte përpjekje të konsiderueshme. Ajo që na duhej ishte një mënyrë e thjeshtë për të vlerësuar një konfigurim specifik. Ne donim të testonim të kuptuarit tonë të metrikës së Prometeut që vjen nga etcd.

Kjo kërkonte zgjidhjen e dy problemeve:

Së pari, si duket ngarkesa I/O e gjeneruar nga etcd kur shkruani në skedarë WAL? Cilat thirrje sistemore përdoren? Sa është madhësia e blloqeve të regjistrimit?
Së dyti, le të themi se kemi përgjigje për pyetjet e mësipërme. Si të riprodhoni ngarkesën përkatëse me fio? Pas te gjithave fio - mjet jashtëzakonisht fleksibël me një bollëk parametrash (kjo është e lehtë për t'u verifikuar, për shembull, këtu - përafërsisht. përkth.).

Ne i zgjidhëm të dy problemet me të njëjtën qasje të bazuar në komandë lsof и strace:

Me lsof ju mund të shikoni të gjithë përshkruesit e skedarëve të përdorur nga procesi, si dhe skedarët të cilëve u referohen.
Me strace mund të analizoni një proces tashmë të ekzekutuar ose të ekzekutoni një proces dhe ta shikoni atë. Komanda shfaq të gjitha thirrjet e sistemit të bëra nga ky proces dhe, nëse është e nevojshme, pasardhësit e tij. Kjo e fundit është e rëndësishme për proceset që janë duke u forcuar, dhe etcd është një proces i tillë.

Gjëja e parë që bëmë ishte përdorimi strace për të ekzaminuar serverin etcd në grupin Kubernetes ndërsa ishte i papunë.

Pra, u zbulua se blloqet e regjistrimit WAL janë të grupuara shumë dendur, madhësia e shumicës ishte në intervalin 2200-2400 bajt. Kjo është arsyeja pse komanda në fillim të këtij artikulli përdor flamurin --bs=2300 (bs është madhësia në bajt e çdo blloku shkrimi në fio).

Ju lutemi vini re se madhësia e blloqeve të shkrimit etcd mund të ndryshojë në varësi të versionit, vendosjes, vlerave të parametrave, etj. - ndikon në kohëzgjatjen fdatasync. Nëse keni një rast të ngjashëm përdorimi, analizoni me strace proceset tuaja etjd për të marrë vlera të përditësuara.

Më pas, për të marrë një ide të qartë dhe gjithëpërfshirëse se si funksionon etcd me sistemin e skedarëve, ne e filluam atë nga poshtë strace me flamuj -ffttT. Kjo bëri të mundur kapjen e proceseve të fëmijëve dhe shkrimin e prodhimit të secilit në një skedar të veçantë. Përveç kësaj, u morën informacion të detajuar në lidhje me kohën e fillimit dhe kohëzgjatjen e çdo telefonate sistemi.

Ne kemi përdorur edhe komandën lsofpër të konfirmuar të kuptuarit tuaj të prodhimit strace për sa i përket përshkrimit të skedarit për cilin qëllim është përdorur. E mora përfundimin strace, i ngjashëm me atë të mësipërm. Manipulimet statistikore me kohët e sinkronizimit konfirmuan se metrika wal_fsync_duration_seconds nga thirrjet etjd përputhet fdatasync me përshkruesit e skedarëve WAL.

Për të gjeneruar me fio një ngarkesë pune e ngjashme me atë nga etcd, u studiua dokumentacioni i shërbimeve dhe u zgjodhën parametrat e përshtatshëm për detyrën tonë. Ne kemi verifikuar që thirrjet e sakta të sistemit janë në proces dhe kemi konfirmuar kohëzgjatjen e tyre duke ekzekutuar fio nga strace (siç është bërë në rastin e etjd).

Vëmendje e veçantë i është kushtuar përcaktimit të vlerës së parametrit --size. Ai përfaqëson ngarkesën totale I/O të gjeneruar nga shërbimi fio. Në rastin tonë, ky është numri i përgjithshëm i bajteve të shkruara në media. Është drejtpërdrejt proporcionale me numrin e thirrjeve write (dhe fdatasync). Për një specifik bs numri i thirrjeve fdatasync është size / bs.

Meqenëse ne ishim të interesuar për përqindjen, ne donim që numri i mostrave të ishte mjaft i madh për të qenë statistikisht i rëndësishëm. Dhe vendosi atë 10^4 (që korrespondon me një madhësi prej 22 MB) do të mjaftojë. Vlerat më të vogla të parametrave --size dha zhurmë më të theksuar (për shembull, thirrje fdatasync, të cilat zgjasin shumë më shumë se zakonisht dhe prekin përqindjen e 99-të).

Varet nga ju

Artikulli tregon se si të përdoret fio mund të gjykohet nëse media e destinuar për përdorim me etcd është mjaft e shpejtë. Tani varet nga ju! Ju mund të eksploroni makina virtuale me ruajtje të bazuar në SSD në shërbim IBM Cloud.

PS nga përkthyesi

Me kuti perdorimi te gatshme fio Për detyra të tjera, shihni dokumentacionin ose direkt tek depot e projekteve (janë shumë më tepër se sa përmenden në dokumentacion).

PPS nga përkthyesi

Lexoni edhe në blogun tonë:

Burimi: www.habr.com

Si të kontrolloni disqet me fio për performancë të mjaftueshme për etj