🥇Ինչպես ստուգել սկավառակները fio-ով բավարար կատարման համար etcd

Նշում. թարգմ.Այս հոդվածը IBM Cloud-ի ինժեներների կողմից իրականացված մինի-հետազոտության արդյունքն է՝ etcd տվյալների բազայի շահագործման հետ կապված իրական խնդրի լուծում գտնելու համար: Նմանատիպ խնդիր մեզ համար արդիական էր, սակայն հեղինակների մտորումների ու գործողությունների ընթացքը կարող է հետաքրքիր լինել ավելի լայն համատեքստում։

Ամբողջ հոդվածի համառոտ ամփոփում. fio և այլն

etcd կլաստերի կատարումը մեծապես կախված է հիմքում ընկած պահեստավորման արագությունից: etcd-ն արտահանում է Պրոմեթևսի տարբեր չափումներ՝ կատարողականը վերահսկելու համար: Դրանցից մեկն է wal_fsync_duration_seconds. Փաստաթղթերում և այլն այն ասում էոր պահեստավորումը կարելի է համարել բավականաչափ արագ, եթե այս չափման 99-րդ տոկոսը չի գերազանցում 10 մվ…

Եթե դուք մտածում եք Linux մեքենաների վրա etcd կլաստերի ստեղծման մասին և ցանկանում եք ստուգել, թե արդյոք կրիչներն (օրինակ՝ SSD-ները) բավականաչափ արագ են, խորհուրդ ենք տալիս օգտագործել հանրաճանաչ I/O փորձարկիչը, որը կոչվում է. ՖԻՈ. Բավական է գործարկել հետևյալ հրամանը (տեղեկատու test-data պետք է տեղակայված լինի փորձարկված սկավառակի տեղադրված միջնորմում).

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

Մնում է միայն նայել արդյունքին և ստուգել, թե արդյոք 99-րդ տոկոսը համապատասխանում է fdatasync 10 ms-ում Եթե այո, ապա ձեր սկավառակը բավական արագ է աշխատում: Ահա ելքի օրինակ.

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]

Մի քանի նշում.

Վերոնշյալ օրինակում մենք ճշգրտել ենք պարամետրերը --size и --bs կոնկրետ դեպքի համար։ Իմաստալից արդյունք ստանալու համար fio, նշեք ձեր օգտագործման դեպքին համապատասխան արժեքներ: Ինչպես ընտրել դրանք, կքննարկվի ստորև:
Միայն թեստավորման ժամանակ fio բեռնում է սկավառակի ենթահամակարգը: Իրական կյանքում, հավանական է, որ այլ գործընթացներ գրվեն սկավառակի վրա (բացի դրանց հետ կապված wal_fsync_duration_seconds) Այս լրացուցիչ բեռը կարող է մեծանալ wal_fsync_duration_seconds. Այլ կերպ ասած, եթե 99-րդ տոկոսը փորձարկումից հետ fio, միայն 10 ms-ից մի փոքր պակաս, մեծ հավանականություն կա, որ պահեստավորման աշխատանքը բավարար չէ:
Թեստի համար ձեզ անհրաժեշտ կլինի տարբերակը fio 3.5-ից ոչ ցածր, քանի որ հին տարբերակները չեն միավորում արդյունքները fdatasync տոկոսների տեսքով։
Վերոնշյալ եզրակացությունը ընդամենը մի փոքր հատված է ընդհանուր եզրակացությունից fio.

Ավելին fio-ի և այլնի մասին

Մի քանի խոսք WAL-ների մասին և այլն

Ընդհանուր առմամբ, տվյալների բազաները օգտագործում են պրոակտիվ անտառահատումներ (նախօրոք գրանցում, WAL): etcd-ը նույնպես ազդում է: WAL-ի քննարկումը դուրս է այս հոդվածի շրջանակներից, բայց մեր նպատակների համար այն, ինչ դուք պետք է իմանաք, այն է, որ etcd կլաստերի յուրաքանչյուր անդամ պահում է WAL-ը մշտական պահեստում: etcd-ը գրում է բանալի-արժեքի պահպանման որոշ գործողություններ (օրինակ՝ թարմացումները) WAL-ում՝ դրանք կատարելուց առաջ: Եթե հանգույցը խափանում է և վերագործարկվում է snapshot-ների միջև, etcd-ը կկարողանա վերականգնել գործարքները նախորդ նկարից սկսած՝ WAL-ի բովանդակության հիման վրա:

Այսպիսով, ամեն անգամ, երբ հաճախորդը բանալի է ավելացնում KV խանութին կամ թարմացնում է գոյություն ունեցող բանալու արժեքը, etcd-ն ավելացնում է գործողության նկարագրությունը WAL-ին, որը մշտական ֆայլ է մշտական խանութում: etcd ՊԵՏՔ Է 100% վստահ լինել, որ WAL գրառումն իրականում պահպանվել է նախքան շարունակելը: Linux-ում դրան հասնելու համար բավական չէ օգտագործել համակարգային զանգը write, քանի որ ֆիզիկական կրիչների վրա գրելու գործողությունը կարող է հետաձգվել: Օրինակ, Linux-ը կարող է որոշ ժամանակ պահել WAL գրառումը հիշողության միջուկի քեշում (օրինակ՝ էջի քեշում): Ապահովելու համար, որ տվյալները գրված են լրատվամիջոցների վրա, գրելուց հետո պետք է կանչվի համակարգային զանգ fdatasync - սա հենց այն է, ինչ անում է etcd-ը (ինչպես կարող եք տեսնել հետևյալ ելքում strace; Այստեղ 8 - 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>

Ցավոք, մշտական պահեստում գրելը որոշ ժամանակ է պահանջում: fdatasync-ի զանգերի երկարատև կատարումը կարող է ազդել etcd-ի աշխատանքի վրա: Պահեստային փաստաթղթերում նշված է, որ բավարար կատարման համար անհրաժեշտ է, որ բոլոր զանգերի տևողության 99-րդ տոկոսը fdatasync երբ WAL ֆայլում գրելը 10 ms-ից պակաս էր: Կան պահեստավորման հետ կապված այլ չափումներ, բայց այս հոդվածը կկենտրոնանա դրա վրա:

Ֆիոյի հետ պահեստավորման գնահատում

Դուք կարող եք գնահատել, թե արդյոք որոշակի պահեստը հարմար է etcd-ի հետ օգտագործելու համար՝ օգտագործելով կոմունալ ծրագիրը ՖԻՈ — հանրաճանաչ I/O փորձարկիչ: Հիշեք, որ սկավառակի I/O-ն կարող է տեղի ունենալ տարբեր ձևերով՝ համաժամեցում/ասինացում, շատ տարբեր syscall դասեր և այլն: Մետաղադրամի մյուս կողմն այն է fio չափազանց դժվար է օգտագործել: Կոմունալն ունի բազմաթիվ պարամետրեր, և դրանց արժեքների տարբեր համակցությունները հանգեցնում են բոլորովին այլ արդյունքների: Etdd-ի ողջամիտ գնահատական ստանալու համար դուք պետք է համոզվեք, որ fio-ի կողմից ստեղծված գրելու բեռնվածությունը հնարավորինս մոտ է etcd-ի WAL ֆայլի գրման բեռնվածությանը.

Սա նշանակում է, որ առաջացած fio բեռնվածությունը պետք է լինի առնվազն ֆայլի անընդմեջ գրությունների շարք, որտեղ յուրաքանչյուր գրություն բաղկացած է համակարգային զանգից writeորին հաջորդում է fdatasync.
Հաջորդական գրությունը միացնելու համար դուք պետք է նշեք դրոշը --rw=write.
Որ fio գրել է զանգերի միջոցով write (այլ համակարգային զանգերի փոխարեն, օրինակ, pwrite), օգտագործեք դրոշը --ioengine=sync.
Վերջապես դրոշը --fdatasync=1 ապահովում է, որ յուրաքանչյուր write պետք է fdatasync.
Մեր օրինակի մյուս երկու պարամետրերն են. --size и --bs - կարող է տարբեր լինել՝ կախված օգտագործման կոնկրետ դեպքից: Հաջորդ բաժինը նկարագրելու է դրանց կոնֆիգուրացիան:

Ինչու մենք ընտրեցինք fio-ն և ինչպես սովորեցինք այն կարգավորել

Այս գրառումը գալիս է մեր հանդիպած իրական դեպքից։ Մենք ունեինք կլաստեր Kubernetes v1.13-ում Պրոմեթևսի մոնիտորինգով: SSD-ները օգտագործվել են որպես etcd v3.2.24-ի պահեստ: Etcd չափումները ցույց են տվել չափազանց բարձր ուշացումներ fdatasync, նույնիսկ երբ կլաստերը պարապ էր։ Մեզ համար այս չափումները շատ կասկածելի էին թվում, և մենք վստահ չէինք, թե կոնկրետ ինչ են դրանք ներկայացնում: Բացի այդ, կլաստերը բաղկացած էր վիրտուալ մեքենաներից, ուստի հնարավոր չեղավ ասել՝ ուշացումը պայմանավորված է վիրտուալիզացիայից, թե SSD-ն էր մեղավոր։

Բացի այդ, մենք հաշվի առանք տարբեր փոփոխություններ ապարատային և ծրագրային ապահովման կազմաձևում, ուստի մեզ անհրաժեշտ էր դրանք գնահատելու միջոց: Իհարկե, հնարավոր կլիներ գործարկել etcd-ը յուրաքանչյուր կոնֆիգուրացիայի մեջ և դիտարկել համապատասխան Պրոմեթևսի չափումները, բայց դա զգալի ջանք կպահանջի: Մեզ անհրաժեշտ էր կոնկրետ կոնֆիգուրացիան գնահատելու պարզ միջոց: Մենք ուզում էինք ստուգել մեր պատկերացումները Պրոմեթևսի չափումների վերաբերյալ, որոնք գալիս են etcd-ից:

Սա պահանջում էր լուծել երկու խնդիր.

Նախ, ինչպիսի՞ն է WAL ֆայլերին գրելիս etcd-ի կողմից առաջացած I/O բեռը: Ինչ համակարգային զանգեր են օգտագործվում: Որքա՞ն է ռեկորդային բլոկների չափը:
Երկրորդ, ասենք, որ վերը նշված հարցերի պատասխաններն ունենք։ Ինչպես վերարտադրել համապատասխան բեռը fio? Ամենից հետո fio — չափազանց ճկուն օգտակարություն՝ պարամետրերի առատությամբ (սա հեշտ է ստուգել, օրինակ. այստեղ - մոտ. թարգմ.).

Մենք երկու խնդիրն էլ լուծեցինք նույն հրամանի վրա հիմնված մոտեցմամբ lsof и strace:

Հետ lsof դուք կարող եք դիտել բոլոր ֆայլերի նկարագրիչները, որոնք օգտագործվում են գործընթացում, ինչպես նաև այն ֆայլերը, որոնց նրանք վերաբերում են:
Հետ strace դուք կարող եք վերլուծել արդեն իսկ գործող գործընթաց կամ գործարկել գործընթաց և դիտել այն: Հրամանը ցուցադրում է այս գործընթացով կատարված բոլոր համակարգային զանգերը և, անհրաժեշտության դեպքում, դրա հետնորդները: Վերջինս կարևոր է ճեղքվող գործընթացների համար, և այլն:

Առաջին բանը, որ մենք արեցինք, օգտագործելն էր strace ուսումնասիրել etcd սերվերը Kubernetes կլաստերում, երբ այն անգործուն էր:

Այսպիսով, պարզվեց, որ WAL ձայնագրման բլոկները շատ խիտ խմբավորված են, մեծամասնության չափը 2200-2400 բայթի սահմաններում էր: Ահա թե ինչու այս հոդվածի սկզբում հրամանն օգտագործում է դրոշը --bs=2300 (bs յուրաքանչյուր գրելու բլոկի չափն է բայթերով fio).

Խնդրում ենք նկատի ունենալ, որ etcd գրելու բլոկների չափերը կարող են տարբեր լինել՝ կախված տարբերակից, տեղակայումից, պարամետրերի արժեքներից և այլն: - դա ազդում է տևողության վրա fdatasync. Եթե ունեք նմանատիպ օգտագործման դեպք, վերլուծեք հետ strace ձեր etcd գործընթացները՝ արդի արժեքներ ստանալու համար:

Այնուհետև պարզ և համապարփակ պատկերացում կազմելու համար, թե ինչպես է etcd-ն աշխատում ֆայլային համակարգի հետ, մենք այն սկսեցինք տակից strace դրոշներով -ffttT. Սա հնարավորություն տվեց գրավել երեխայի գործընթացները և յուրաքանչյուրի արդյունքը գրել առանձին ֆայլում: Բացի այդ, մանրամասն տեղեկատվություն է ստացվել յուրաքանչյուր համակարգային զանգի մեկնարկի ժամանակի և տևողության մասին:

Մենք նաև օգտագործեցինք հրամանը lsofելքի մասին ձեր պատկերացումները հաստատելու համար strace այն առումով, թե որ ֆայլի նկարագրիչը ինչ նպատակով է օգտագործվել: Ես ստացա եզրակացությունը strace, նման է վերը նշվածին: Համաժամացման ժամանակներով վիճակագրական մանիպուլյացիաները հաստատեցին, որ մետրիկը wal_fsync_duration_seconds etcd matches զանգերից fdatasync WAL ֆայլի նկարագրիչներով:

հետ ստեղծելու համար fio աշխատանքային ծանրաբեռնվածությունը, որը նման է etcd-ից, ուսումնասիրվել է կոմունալ ծառայության փաստաթղթերը և ընտրվել են մեր առաջադրանքի համար հարմար պարամետրերը: Մենք ստուգել ենք, որ ճիշտ համակարգային զանգերն ընթացքի մեջ են և հաստատել ենք դրանց տևողությունը՝ գործարկելով fio - ից strace (ինչպես դա արվեց և այլնի դեպքում):

Առանձնահատուկ ուշադրություն է դարձվել պարամետրի արժեքի որոշմանը --size. Այն ներկայացնում է ընդհանուր I/O բեռը, որը առաջացել է fio կոմունալ ծառայության կողմից: Մեր դեպքում սա լրատվամիջոցին գրված բայթերի ընդհանուր թիվն է: Այն ուղիղ համեմատական է զանգերի քանակին write (և fdatasync) Կոնկրետի համար bs զանգերի քանակը fdatasync հավասար է size / bs.

Քանի որ մեզ հետաքրքրում էր տոկոսը, մենք ցանկանում էինք, որ նմուշների թիվը բավական մեծ լինի, որպեսզի վիճակագրորեն նշանակալի լինի: Եվ դա որոշեց 10^4 (որը համապատասխանում է 22 ՄԲ չափին) բավական կլինի։ Պարամետրերի ավելի փոքր արժեքներ --size ավելի ընդգծված աղմուկ էր տալիս (օրինակ՝ զանգեր fdatasync, որոնք սովորականից շատ ավելի երկար են տևում և ազդում 99-րդ տոկոսի վրա):

Ձեզնից է կախված

Հոդվածը ցույց է տալիս, թե ինչպես օգտագործել fio Կարելի է դատել, թե etcd-ով օգտագործելու համար նախատեսված մեդիան բավական արագ է: Այժմ դա կախված է ձեզանից: Ծառայության մեջ կարող եք ուսումնասիրել վիրտուալ մեքենաները SSD-ի վրա հիմնված պահեստով IBM Cloud- ը.

PS թարգմանչից

Պատրաստի օգտագործման պատյաններով fio Այլ առաջադրանքների համար տե՛ս փաստաթղթավորում կամ ուղղակիորեն դեպի նախագծի շտեմարաններ (դրանք շատ ավելին են, քան նշված է փաստաթղթում):

PPS թարգմանիչից

Կարդացեք նաև մեր բլոգում.

Source: www.habr.com

Ինչպես ստուգել սկավառակները fio-ով և այլն բավարար կատարման համար