🥇Jinsi ya kuangalia diski na fio kwa utendakazi wa kutosha kwa etcd

Kumbuka. tafsiri.: Makala haya ni matokeo ya utafiti mdogo uliofanywa na wahandisi wa Wingu wa IBM katika kutafuta suluhu la tatizo halisi linalohusiana na uendeshaji wa hifadhidata ya etcd. Kazi kama hiyo ilikuwa muhimu kwetu, hata hivyo, mwendo wa kutafakari na vitendo vya waandishi vinaweza kuvutia katika muktadha mpana.

Muhtasari mfupi wa makala yote: fio na nk

Utendaji wa nguzo ya etcd inategemea sana kasi ya hifadhi ya msingi. etcd husafirisha vipimo mbalimbali vya Prometheus ili kufuatilia utendakazi. Mmoja wao ni wal_fsync_duration_seconds. Katika nyaraka za nk inasemahifadhi hiyo inaweza kuchukuliwa kuwa haraka vya kutosha ikiwa asilimia 99 ya kipimo hiki haizidi ms 10...

Ikiwa unazingatia kusanidi nguzo ya etcd kwenye mashine za Linux na unataka kuangalia ikiwa viendeshi (kama vile SSD) vina kasi ya kutosha, tunapendekeza utumie kijaribu maarufu cha I/O kinachoitwa. fio. Inatosha kutekeleza amri ifuatayo (saraka test-data lazima iko kwenye kizigeu kilichowekwa cha kiendeshi kilichojaribiwa):

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

Inabakia tu kuangalia matokeo na kuangalia ikiwa asilimia ya 99 inafaa fdatasync katika 10 ms. Ikiwa ndivyo, basi kiendeshi chako kinafanya kazi haraka vya kutosha. Hapa kuna pato la mfano:

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]

Vidokezo vichache:

Katika mfano hapo juu, tumerekebisha vigezo --size и --bs kwa kesi maalum. Ili kupata matokeo ya maana kutoka fio, taja maadili yanayofaa kwa kesi yako ya utumiaji. Jinsi ya kuwachagua itajadiliwa hapa chini.
Wakati wa majaribio tu fio hupakia mfumo mdogo wa diski. Katika maisha halisi, kuna uwezekano kwamba michakato mingine itaandika kwa diski (mbali na ile inayohusiana na wal_fsync_duration_seconds) Mzigo huu wa ziada unaweza kuongezeka wal_fsync_duration_seconds. Kwa maneno mengine, ikiwa asilimia ya 99 kutoka kwa majaribio na fio, chini kidogo ya 10 ms, kuna uwezekano mkubwa kwamba utendaji wa uhifadhi hautoshi.
Kwa mtihani utahitaji toleo fio sio chini ya 3.5, kwa sababu matoleo ya zamani hayajumlishi matokeo fdatasync kwa namna ya percentiles.
Hitimisho hapo juu ni sehemu ndogo tu kutoka kwa hitimisho la jumla fio.

Zaidi kuhusu fio na nk

Maneno machache kuhusu WAL nk

Kwa ujumla, hifadhidata hutumiwa ukataji miti makini (andika-mbele ukataji miti, WAL). etcd pia imeathirika. Majadiliano ya WAL ni zaidi ya upeo wa makala haya, lakini kwa madhumuni yetu, unachohitaji kujua ni kwamba kila mwanachama wa kikundi cha etcd huhifadhi WAL katika hifadhi inayoendelea. etcd huandika baadhi ya shughuli za uhifadhi wa thamani-msingi (kama vile masasisho) kwa WAL kabla ya kuzitekeleza. Ikiwa nodi itaacha kufanya kazi na kuwashwa tena kati ya vijipicha, etcd inaweza kurejesha shughuli za malipo tangu picha iliyotangulia kulingana na yaliyomo kwenye WAL.

Kwa hivyo, kila wakati mteja anaongeza ufunguo kwenye duka la KV au kusasisha thamani ya ufunguo uliopo, nkd huongeza maelezo ya operesheni kwa WAL, ambayo ni faili ya kawaida katika duka inayoendelea. etcd LAZIMA uwe na uhakika wa 100% kuwa ingizo la WAL limehifadhiwa kabla ya kuendelea. Ili kufikia hili kwenye Linux, haitoshi kutumia simu ya mfumo write, kwa kuwa operesheni ya kuandika yenyewe kwa vyombo vya habari vya kimwili inaweza kuchelewa. Kwa mfano, Linux inaweza kuweka ingizo la WAL katika akiba ya kernel ya kumbukumbu (km, kwenye akiba ya ukurasa) kwa muda. Ili kuhakikisha kuwa data imeandikwa kwa vyombo vya habari, simu ya mfumo lazima itumike baada ya kuandika fdatasync - hivi ndivyo etcd hufanya (kama unaweza kuona katika matokeo yafuatayo strace; Hapa 8 Maelezo ya faili ya 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>

Kwa bahati mbaya, kuandika kwa hifadhi inayoendelea huchukua muda. Utekelezaji wa muda mrefu wa simu za fdatasync unaweza kuathiri utendakazi wa etcd. Katika nyaraka za hifadhi imeonyeshwa, kwamba kwa utendakazi wa kutosha ni muhimu kwamba asilimia 99 ya muda wa simu zote fdatasync wakati wa kuandika kwa faili ya WAL ilikuwa chini ya 10 ms. Kuna vipimo vingine vinavyohusiana na uhifadhi, lakini makala haya yatazingatia hiyo.

Kuthamini uhifadhi na fio

Unaweza kutathmini ikiwa hifadhi fulani inafaa kutumika na etcd kwa kutumia matumizi fio — kijaribu maarufu cha I/O. Kumbuka kwamba diski I/O inaweza kutokea kwa njia nyingi tofauti: kusawazisha/async, madarasa mengi tofauti ya syscall, na kadhalika. Upande wa pili wa sarafu ni huo fio ngumu sana kutumia. Huduma ina vigezo vingi, na mchanganyiko tofauti wa maadili yao husababisha matokeo tofauti kabisa. Ili kupata makisio yanayofaa kwa etcd, unahitaji kuhakikisha kuwa mzigo wa uandishi unaozalishwa na fio uko karibu iwezekanavyo na etcd's WAL faili ya kuandika mzigo:

Hii ina maana kwamba yanayotokana fio mzigo unapaswa angalau kuwa safu ya uandishi mfululizo kwa faili, ambapo kila maandishi yana simu ya mfumo. writeIkifuatiwa na fdatasync.
Ili kuwezesha uandishi unaofuatana, lazima ubainishe bendera --rw=write.
Hiyo fio aliandika kwa kutumia simu write (badala ya simu zingine za mfumo - kwa mfano, pwrite), tumia bendera --ioengine=sync.
Hatimaye, bendera --fdatasync=1 inahakikisha kwamba kila write lazima fdatasync.
Vigezo vingine viwili katika mfano wetu ni: --size и --bs - inaweza kutofautiana kulingana na kesi maalum ya matumizi. Sehemu inayofuata itaelezea usanidi wao.

Kwa nini tulichagua fio na jinsi tulijifunza jinsi ya kuiweka

Dokezo hili linatokana na kesi halisi tuliyokumbana nayo. Tulikuwa na kikundi kwenye Kubernetes v1.13 chenye ufuatiliaji kwenye Prometheus. SSD zilitumika kama hifadhi kwa etcd v3.2.24. Vipimo vya Etcd vilionyesha ucheleweshaji wa juu sana fdatasync, hata wakati nguzo ilikuwa bila kazi. Kwetu, vipimo hivi vilionekana kuwa vya kutiliwa shaka sana, na hatukujua ni nini hasa viliwakilisha. Kwa kuongezea, nguzo hiyo ilikuwa na mashine za kawaida, kwa hivyo haikuwezekana kusema ikiwa kucheleweshwa kulitokana na uboreshaji au SSD ndiyo iliyosababisha lawama.

Kwa kuongeza, tulizingatia mabadiliko mbalimbali katika usanidi wa maunzi na programu, kwa hivyo tulihitaji njia ya kuyatathmini. Bila shaka, itawezekana kuendesha etcd katika kila usanidi na kuangalia metriki zinazolingana za Prometheus, lakini hiyo ingehitaji juhudi kubwa. Tulichohitaji ni njia rahisi ya kutathmini usanidi maalum. Tulitaka kujaribu uelewa wetu wa metriki za Prometheus zinazotoka nk.

Hii ilihitaji kutatua shida mbili:

Kwanza, mzigo wa I/O unaotolewa na etcd wakati wa kuandika kwa faili za WAL unaonekanaje? Je, simu za mfumo gani zinatumika? Ukubwa wa vitalu vya rekodi ni ngapi?
Pili, tuseme tuna majibu ya maswali hapo juu. Jinsi ya kuzaliana mzigo unaolingana na fio? Baada ya yote fio - matumizi rahisi sana na wingi wa vigezo (hii ni rahisi kuthibitisha, kwa mfano, hapa - takriban. tafsiri.).

Tulitatua shida zote mbili kwa mbinu sawa ya msingi wa amri lsof и strace:

Pamoja na lsof unaweza kuona maelezo yote ya faili yanayotumiwa na mchakato, pamoja na faili wanazorejelea.
Pamoja na strace unaweza kuchambua mchakato ambao tayari unaendeshwa au endesha mchakato na uitazame. Amri inaonyesha simu zote za mfumo zinazofanywa na mchakato huu na, ikiwa ni lazima, wazao wake. Mwisho ni muhimu kwa michakato ambayo ni uma, na etcd ni mchakato mmoja kama huo.

Jambo la kwanza tulilofanya ni kutumia strace kukagua seva ya etcd kwenye nguzo ya Kubernetes wakati ilikuwa haina kazi.

Kwa hivyo iligundulika kuwa vizuizi vya rekodi za WAL vimepangwa kwa vikundi vingi, saizi ya wengi ilikuwa katika anuwai ya ka 2200-2400. Ndio maana amri iliyo mwanzoni mwa kifungu hiki hutumia bendera --bs=2300 (bs ni saizi ya baiti ya kila kizuizi cha uandishi ndani fio).

Tafadhali kumbuka kuwa saizi ya vizuizi vya uandishi etcd inaweza kutofautiana kulingana na toleo, uwekaji, maadili ya vigezo, n.k. - inathiri muda fdatasync. Ikiwa una kesi kama hiyo ya utumiaji, chambua na strace etcd michakato yako kupata maadili ya kisasa.

Halafu, ili kupata wazo wazi na la kina la jinsi etcd inavyofanya kazi na mfumo wa faili, tuliianzisha kutoka chini. strace na bendera -ffttT. Hii ilifanya iwezekane kunasa michakato ya mtoto na kuandika matokeo ya kila faili tofauti. Kwa kuongeza, maelezo ya kina kuhusu muda wa kuanza na muda wa kila simu ya mfumo ilipatikana.

Pia tulitumia amri lsofili kuthibitisha uelewa wako wa matokeo strace kwa maana ya kielezi cha faili kilitumika kwa madhumuni gani. Nilipata hitimisho strace, sawa na hapo juu. Udanganyifu wa takwimu na nyakati za ulandanishi ulithibitisha kuwa kipimo wal_fsync_duration_seconds kutoka kwa simu zinazolingana na etcd fdatasync na maelezo ya faili ya WAL.

Ili kuzalisha na fio mzigo wa kazi sawa na ule kutoka etcd, nyaraka za matumizi zilisomwa na vigezo vinavyofaa kwa kazi yetu vilichaguliwa. Tumethibitisha kuwa simu sahihi za mfumo zinaendelea na tumethibitisha muda wake kwa kuzikimbia fio ya strace (kama ilivyofanywa katika kesi ya etcd).

Uangalifu hasa ulilipwa kwa kuamua thamani ya parameter --size. Inawakilisha jumla ya mzigo wa I/O unaozalishwa na matumizi ya fio. Kwa upande wetu, hii ni jumla ya idadi ya ka iliyoandikwa kwa vyombo vya habari. Inalingana moja kwa moja na idadi ya simu write (na fdatasync) Kwa maalum bs idadi ya simu fdatasync sawa size / bs.

Kwa kuwa tulivutiwa na asilimia, tulitaka idadi ya sampuli iwe kubwa ya kutosha kuwa muhimu kitakwimu. Na kuamua hivyo 10^4 (ambayo inalingana na ukubwa wa MB 22) itatosha. Vigezo vidogo vya vigezo --size alitoa kelele iliyotamkwa zaidi (kwa mfano, simu fdatasync, ambayo huchukua muda mrefu zaidi kuliko kawaida na kuathiri asilimia 99).

Ni juu yako

Makala inaonyesha jinsi ya kutumia fio mtu anaweza kuhukumu ikiwa media iliyokusudiwa kutumiwa na etcd ni haraka vya kutosha. Sasa ni juu yako! Unaweza kuchunguza mashine pepe ukitumia hifadhi inayotegemea SSD katika huduma Wingu wa IBM.

PS kutoka kwa mtafsiri

Na kesi za matumizi tayari fio Kwa kazi zingine, ona nyaraka au moja kwa moja hazina za mradi (kuna nyingi zaidi kuliko zilizotajwa kwenye nyaraka).

PPS kutoka kwa mtafsiri

Soma pia kwenye blogi yetu:

Chanzo: mapenzi.com

Jinsi ya kuangalia diski na fio kwa utendaji wa kutosha kwa etcd