Kasi ya kuhifadhi inafaa kwa etcd? Hebu tuulize fio

Hadithi fupi kuhusu fio na nk

Utendaji wa nguzo nk kwa kiasi kikubwa inategemea utendaji wa hifadhi yake. etcd husafirisha baadhi ya vipimo kwa Prometheusili kutoa taarifa ya utendaji ya hifadhi inayohitajika. Kwa mfano, kipimo cha wal_fsync_duration_seconds. Nyaraka za etcd zinasema: Ili kuhifadhi kuzingatiwa kuwa haraka vya kutosha, asilimia 99 ya kipimo hiki lazima iwe chini ya milisekunde. Ikiwa unapanga kuendesha nguzo ya etcd kwenye mashine za Linux na unataka kutathmini ikiwa hifadhi yako ni ya haraka vya kutosha (kama vile SSD), unaweza kutumia fio ni zana maarufu ya kujaribu shughuli za I/O. Tekeleza amri ifuatayo, ambapo data ya jaribio ni saraka chini ya sehemu ya uhifadhi:

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

Unahitaji tu kuangalia matokeo na uangalie kuwa asilimia 99 ya muda fdatasync chini ya 10 ms. Ikiwa ndivyo, una hifadhi ya haraka ipasavyo. Hapa kuna mfano wa matokeo:

  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]

maelezo

• Tumebinafsisha chaguzi za --size na --bs kwa hali yetu mahususi. Ili kupata matokeo muhimu kutoka kwa fio, toa maadili yako mwenyewe. Wapi kupata yao? Soma jinsi tulivyojifunza kusanidi fio.
• Wakati wa kupima, mzigo wote wa I/O unatoka kwa fio. Katika hali halisi, kunaweza kuwa na maombi mengine ya uandishi yanayokuja kwenye hifadhi kando na yale yanayohusiana na wal_fsync_duration_seconds. Mzigo wa ziada utaongeza thamani ya wal_fsync_duration_seconds. Kwa hivyo ikiwa asilimia 99 inakaribia milisekunde, hifadhi yako inaishiwa na kasi.
• Chukua toleo fio sio chini ya 3.5 (zilizotangulia hazionyeshi asilimia ya muda ya fdatasync).
• Hapo juu ni kipande kidogo cha matokeo kutoka kwa fio.

Hadithi ndefu kuhusu fio na nk

WAL ni nini nk

Kawaida hifadhidata hutumiwa andika-mbele logi; etcd hutumia pia. Hatutajadili logi ya kuandika-mbele (WAL) kwa undani hapa. Inatosha kwetu kujua kwamba kila mwanachama wa kikundi cha etcd huihifadhi katika hifadhi inayoendelea. etcd huandika kila operesheni ya thamani ya ufunguo (kama vile sasisho) kwa WAL kabla ya kuitumia kwenye duka. Ikiwa mmoja wa washiriki wa hifadhi ataacha kufanya kazi na kuwasha upya kati ya vijipicha, inaweza kurejesha miamala ndani ya nchi tangu picha ya mwisho ya maudhui ya WAL.

Wakati mteja anaongeza ufunguo kwenye hifadhi ya thamani ya ufunguo au kusasisha thamani ya ufunguo uliopo, etcd hurekodi utendakazi katika WAL, ambayo ni faili ya kawaida katika hifadhi inayoendelea. etcd LAZIMA uwe na uhakika kabisa kwamba ingizo la WAL lilitokea kabla ya kuendelea na usindikaji. Kwenye Linux, simu moja ya mfumo haitoshi kwa hili. kuandika, kwani maandishi halisi kwa hifadhi halisi yanaweza kuchelewa. Kwa mfano, Linux inaweza kuhifadhi ingizo la WAL kwenye kashe kwenye kumbukumbu ya kernel (kama vile kache ya ukurasa) kwa muda. Na ili data iandikwe kwa usahihi kwa uhifadhi unaoendelea, simu ya mfumo wa fdatasync inahitajika baada ya kuandika, na etcd huitumia tu (kama unavyoweza kuona katika matokeo ya kazi. kamba, ambapo 8 ni maelezo ya faili ya WAL):

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

Kwa bahati mbaya, kuandika kwa hifadhi inayoendelea haifanyiki mara moja. Ikiwa simu ya fdatasync ni polepole, utendakazi wa mfumo wa etcd utateseka. Nyaraka za etcd zinasemakwamba hifadhi inachukuliwa kuwa ya haraka vya kutosha ikiwa, katika asilimia ya 99, simu za fdatasync huchukua chini ya 10ms kuandikia faili ya WAL. Kuna vipimo vingine muhimu vya kuhifadhi, lakini katika chapisho hili tunazungumza tu kuhusu kipimo hiki.

Inakadiria hifadhi na fio

Ikiwa unahitaji kutathmini ikiwa hifadhi yako inafaa kwa etcd, tumia fio, zana maarufu sana ya kupima I/O. Ikumbukwe kwamba shughuli za disk zinaweza kuwa tofauti sana: synchronous na asynchronous, madarasa mengi ya simu za mfumo, nk Matokeo yake, fio ni vigumu kabisa kutumia. Ina vigezo vingi, na michanganyiko tofauti ya maadili yao hutoa mizigo ya kazi ya I/O tofauti sana. Ili kupata takwimu za kutosha za etcd, unapaswa kuhakikisha kuwa mzigo wa kuandika mtihani kutoka kwa fio uko karibu iwezekanavyo na mzigo halisi kutoka etcd wakati wa kuandika faili za WAL.

Kwa hivyo, fio inapaswa, kwa kiwango cha chini, kuunda mzigo wa safu ya mfululizo wa maandishi kwa faili, kila maandishi yatakuwa na simu ya mfumo. kuandikaikifuatiwa na simu ya mfumo wa fdatasync. Mfululizo huandika kwa fio zinahitaji --rw=write chaguo. Kwa fio kutumia mfumo wa kuandika simu wakati wa kuandika, badala ya andika, unapaswa kubainisha --ioengine=sync parameta. Mwishowe, ili kupiga simu fdatasync baada ya kila uandishi, unahitaji kuongeza --fdatasync=1 paramu. Chaguzi zingine mbili katika mfano huu (--size na -bs) ni maalum kwa hati. Katika sehemu inayofuata, tutakuonyesha jinsi ya kuziweka.

Kwa nini fio na jinsi tulijifunza kuiweka

Katika chapisho hili, tunaelezea kesi halisi. Tuna nguzo Mabernet v1.13 ambayo tulifuatilia na Prometheus. etcd v3.2.24 ilipangishwa kwenye SSD. Vipimo vya Etcd vilionyesha ucheleweshaji wa fdatasync juu sana, hata wakati nguzo haikufanya chochote. Vipimo vilikuwa vya ajabu na hatukujua vilimaanisha nini. Nguzo hiyo ilijumuisha mashine za kawaida, ilikuwa ni lazima kuelewa shida ilikuwa nini: katika SSD za kimwili au kwenye safu ya virtualization. Kwa kuongeza, mara nyingi tulifanya mabadiliko kwenye maunzi na usanidi wa programu, na tulihitaji njia ya kutathmini matokeo yao. Tunaweza kuendesha etcd katika kila usanidi na kuangalia metriki za Prometheus, lakini hiyo ni shida sana. Tulikuwa tunatafuta njia rahisi ya kutathmini usanidi maalum. Tulitaka kuangalia ikiwa tunaelewa metriki za Prometheus kutoka etcd kwa usahihi.

Lakini kwa hili, matatizo mawili yalipaswa kutatuliwa. Kwanza, mzigo wa I/O ambao etcd huunda wakati wa kuandika kwa WAL unaonekanaje? Je, simu za mfumo gani zinatumika? Ni ukubwa gani wa rekodi? Pili, ikiwa tunajibu maswali haya, tunawezaje kuzaliana mzigo wa kazi sawa na fio? Usisahau kwamba fio ni chombo rahisi sana na chaguzi nyingi. Tulitatua shida zote mbili kwa njia moja - kwa kutumia amri ls ya и kamba. lsof huorodhesha maelezo yote ya faili yanayotumiwa na mchakato na faili zinazohusiana. Na kwa strace, unaweza kuchunguza mchakato tayari unaoendesha, au kuanza mchakato na kuuchunguza. strace huchapisha simu zote za mfumo kutoka kwa mchakato unaochunguzwa (na michakato yake ya mtoto). Mwisho ni muhimu sana, kwani etcd inachukua njia sawa.

Kwanza tulitumia strace kuchunguza etcd seva ya Kubernetes wakati hapakuwa na mzigo kwenye nguzo. Tuliona kwamba karibu rekodi zote za WAL zilikuwa na ukubwa sawa: baiti 2200–2400. Kwa hiyo, katika amri mwanzoni mwa chapisho, tulibainisha parameter -bs=2300 (bs ina maana ya ukubwa wa bytes kwa kila ingizo la fio). Kumbuka kuwa saizi ya ingizo etcd inategemea toleo la etcd, usambazaji, thamani za vigezo, n.k., na huathiri muda wa fdatasync. Ikiwa una hali kama hiyo, chunguza michakato yako ya etcd kwa strace ili kujua nambari kamili.

Halafu, ili kupata wazo nzuri la nini mfumo wa faili wa etcd unafanya, tuliianzisha na strace na chaguzi za -ffttT. Kwa hiyo tulijaribu kuchunguza michakato ya mtoto na kurekodi matokeo ya kila mmoja wao katika faili tofauti, na pia kupata ripoti za kina kuhusu kuanza na muda wa kila simu ya mfumo. Tulitumia lsof kuthibitisha uchanganuzi wetu wa matokeo ya safu na kuona ni kifafanuzi cha faili kilikuwa kinatumika kwa madhumuni gani. Kwa hiyo kwa msaada wa strace, matokeo yaliyoonyeshwa hapo juu yalipatikana. Takwimu za muda wa ulandanishi zilithibitisha kuwa wal_fsync_duration_seconds kutoka etcd inalingana na simu za fdatasync zilizo na vifafanuzi vya faili za WAL.

Tulipitia hati za fio na tukachagua chaguzi za hati yetu ili fio itoe mzigo sawa na etcd. Pia tuliangalia simu za mfumo na muda wake kwa kuendesha fio kutoka kwa strace, sawa na nk.

Tumechagua kwa uangalifu thamani ya --size kigezo ili kuwakilisha mzigo mzima wa I/O kutoka fio. Kwa upande wetu, hii ni jumla ya idadi ya ka iliyoandikwa kwenye hifadhi. Ilibadilika kuwa sawia moja kwa moja na idadi ya simu za mfumo wa kuandika (na fdatasync). Kwa thamani fulani ya bs, nambari ya simu za fdatasync = size/bs. Kwa kuwa tulipendezwa na percentile, ilitubidi kuwa na sampuli za kutosha ili kuwa na uhakika, na tukahesabu kuwa 10^4 ingetutosha (hiyo ni mebibytes 22). Ikiwa --size ni ndogo, wauzaji nje wanaweza kutokea (kwa mfano, simu kadhaa za fdatasync huchukua muda mrefu kuliko kawaida na kuathiri asilimia 99).

Jaribu mwenyewe

Tulikuonyesha jinsi ya kutumia fio na kuona kama hifadhi ina kasi ya kutosha kwa etcd kufanya vizuri. Sasa unaweza kuijaribu mwenyewe kwa kutumia, kwa mfano, mashine pepe zilizo na hifadhi ya SSD ndani Wingu wa IBM.

Chanzo: mapenzi.com