Како проверити дискове са фио за довољне перформансе за етцд

Белешка. трансл.: Овај чланак је резултат мини истраживања које су спровели ИБМ Цлоуд инжењери у потрази за решењем стварног проблема у вези са радом етцд базе података. За нас је био релевантан сличан задатак, међутим, ток размишљања и деловања аутора може бити занимљив у ширем контексту.

Како проверити дискове са фио за довољне перформансе за етцд

Кратак резиме целог чланка: фио и етцд

Перформансе етцд кластера у великој мери зависе од брзине основне меморије. етцд извози различите Прометхеус метрике за праћење перформанси. Један од њих је wal_fsync_duration_seconds. У документацији за итд пишето складиште се може сматрати довољно брзим ако 99. перцентил ове метрике не прелази 10 мс...

Ако размишљате о постављању етцд кластера на Линук машинама и желите да проверите да ли су дискови (као што су ССД-ови) довољно брзи, препоручујемо да користите популарни И/О тестер под називом фио. Довољно је покренути следећу команду (директориј test-data мора да се налази у монтираној партицији тестираног диска):

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

Остаје само да погледамо излаз и проверимо да ли се 99. перцентил уклапа fdatasync за 10 мс. Ако је тако, онда ваш диск ради довољно брзо. Ево примера излаза:

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]

неколико напомена:

  1. У горњем примеру смо подесили параметре --size и --bs за конкретан случај. Да бисте добили значајан резултат од fio, наведите вредности прикладне за ваш случај употребе. Како их одабрати, биће речи у наставку.
  2. Само током тестирања fio учитава подсистем диска. У стварном животу, вероватно је да ће други процеси писати на диск (осим оних који се односе на wal_fsync_duration_seconds). Ово додатно оптерећење може се повећати wal_fsync_duration_seconds. Другим речима, ако је 99. перцентил из тестирања са fio, само нешто мање од 10 мс, постоји велика шанса да перформансе складиштења нису довољне.
  3. За тест ће вам требати верзија fio не мање од 3.5јер старије верзије не обједињују резултате fdatasync у виду перцентила.
  4. Горњи закључак је само мали извод из општег закључка fio.

Више о фио и етцд

Неколико речи о ВАЛ-овима итд

Генерално, базе података користе проактивно евидентирање (записивање унапред, ВАЛ). етцд је такође погођен. Дискусија о ВАЛ-у је ван оквира овог чланка, али за наше сврхе, оно што треба да знате је да сваки члан етцд кластера складишти ВАЛ у трајно складиште. етцд уписује неке операције складиштења кључ/вредност (као што су ажурирања) у ВАЛ пре него што их изврши. Ако се чвор сруши и поново покрене између снимака, етцд може опоравити трансакције од претходног снимка на основу садржаја ВАЛ-а.

Према томе, сваки пут када клијент дода кључ у КВ складиште или ажурира вредност постојећег кључа, етцд додаје опис операције у ВАЛ, што је обична датотека у трајном складишту. етцд МОРА бити 100% сигуран да је ВАЛ унос заиста сачуван пре него што настави. Да бисте то постигли на Линук-у, није довољно користити системски позив write, пошто сама операција писања на физички медиј може бити одложена. На пример, Линук може неко време задржати ВАЛ унос у кешу кернела у меморији (нпр. у кешу странице). Да би се осигурало да су подаци уписани на медиј, системски позив мора бити позван након уписивања fdatasync - то је управо оно што етцд ради (као што можете видети у следећем излазу strace; Ево 8 - ВАЛ дескриптор датотеке):

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>

Нажалост, писање у трајно складиште траје неко време. Продужено извршавање фдатасинц позива може утицати на перформансе етцд-а. У документацији репозиторијума назначено, да је за довољне перформансе неопходно да 99. перцентил трајања свих позива fdatasync приликом писања у ВАЛ датотеку било је мање од 10 мс. Постоје и други показатељи у вези са складиштењем, али овај чланак ће се фокусирати на то.

Вредновање складишта са фио

Помоћу услужног програма можете проценити да ли је одређено складиште погодно за употребу са етцд-ом фио — популарни И/О тестер. Имајте на уму да се диск И/О може десити на много различитих начина: синхронизација/асинхронизација, много различитих класа системског позива итд. Друга страна медаље је то fio изузетно тешко за коришћење. Услужни програм има много параметара, а различите комбинације њиһовиһ вредности доводе до потпуно различитиһ резултата. Да бисте добили разумну процену за етцд, морате да се уверите да је оптерећење писања које генерише фио што је могуће ближе оптерећењу писања у ВАЛ фајлу етцд:

  • То значи да генерисани fio оптерећење би требало да буде најмање серија узастопниһ уписа у датотеку, где се свако уписивање састоји од системског позива writeзатим fdatasync.
  • Да бисте омогућили секвенцијално писање, морате навести заставицу --rw=write.
  • Да fio писао користећи позиве write (уместо других системских позива - нпр. pwrite), користите заставу --ioengine=sync.
  • Коначно, застава --fdatasync=1 обезбеђује да сваки write треба fdatasync.
  • Друга два параметра у нашем примеру су: --size и --bs - може се разликовати у зависности од специфичног случаја употребе. Следећи одељак ће описати њихову конфигурацију.

Зашто смо изабрали фио и како смо научили како да га поставимо

Ова белешка потиче из стварног случаја на који смо наишли. Имали смо кластер на Кубернетес в1.13 са праћењем на Прометхеусу. ССД дискови су коришћени као складиште за етцд в3.2.24. Етцд метрике су показале превисоке латенције fdatasync, чак и када је кластер био у стању мировања. Нама су се ови показатељи чинили веома сумњивим и нисмо били сигурни шта тачно представљају. Поред тога, кластер се састојао од виртуелних машина, па се није могло рећи да ли је до кашњења дошло због виртуелизације или је крив ССД.

Поред тога, размотрили смо различите промене у һардверској и софтверској конфигурацији, па нам је био потребан начин да иһ проценимо. Наравно, било би могуће покренути етцд у свакој конфигурацији и погледати одговарајуће Прометһеус метрике, али то би заһтевало значајан напор. Оно што нам је било потребно је једноставан начин да проценимо одређену конфигурацију. Желели смо да тестирамо наше разумевање метрике Прометеја која долази из етцд.

Ово је заһтевало решавање два проблема:

  • Прво, како изгледа И/О оптерећење које генерише етцд приликом писања у ВАЛ датотеке? Који системски позиви се користе? Која је величина блокова записа?
  • Друго, рецимо да имамо одговоре на горња питања. Како репродуковати одговарајуће оптерећење са fio? После свега fio — изузетно флексибилан услужни програм са обиљем параметара (ово је лако проверити, нпр. овде - прибл. превод).

Оба проблема смо решили истим приступом заснованим на команди lsof и strace:

  • Са lsof можете видети све дескрипторе датотека које користи процес, као и датотеке на које се односе.
  • Са strace можете анализирати већ покренути процес или покренути процес и гледати га. Команда приказује све системске позиве извршене овим процесом и, ако је потребно, његове потомке. Ово последње је важно за процесе који се рачвају, а етцд је један такав процес.

Прва ствар коју смо урадили је да користимо strace да испита етцд сервер у Кубернетес кластеру док је био неактиван.

Тако је откривено да су блокови ВАЛ записа веома густо груписани, величина већине је била у распону од 2200-2400 бајтова. Зато команда на почетку овог чланка користи заставицу --bs=2300 (bs је величина у бајтовима сваког блока за уписивање fio).

Имајте на уму да величина блокова писања етцд може да варира у зависности од верзије, примене, вредности параметара итд. - утиче на трајање fdatasync. Ако имате сличан случај употребе, анализирајте са strace ваши етцд процеси да бисте добили ажурне вредности.

Затим, да бисмо добили јасну и свеобухватну представу о томе како етцд ради са системом датотека, покренули смо га испод strace са заставама -ffttT. Ово је омогућило снимање подређених процеса и записивање излаза сваког у посебну датотеку. Поред тога, добијене су детаљне информације о времену почетка и трајању сваког системског позива.

Користили смо и команду lsofда потврдите своје разумевање резултата strace у погледу тога који је дескриптор датотеке коришћен за коју сврху. Добио сам закључак strace, сличан оном изнад. Статистичке манипулације са временима синһронизације потврдиле су да је метрика wal_fsync_duration_seconds из етцд одговара позивима fdatasync са ВАЛ дескрипторима датотека.

За генерисање са fio радно оптерећење слично оном из етцд-а, проучена је документација услужног програма и изабрани су параметри погодни за наш задатак. Проверили смо да су исправни системски позиви у току и потврдили њиһово трајање покретањем fio од strace (као што је урађено у случају етцд).

Посебна пажња је посвећена одређивању вредности параметра --size. Представља укупно И/О оптерећење које генерише фио услужни програм. У нашем случају, ово је укупан број бајтова уписаних у медије. То је директно пропорционално броју позива writefdatasync). За конкретну bs број позива fdatasync једнако size / bs.

Пошто нас је занимао проценат, желели смо да број узорака буде довољно велики да буде статистички значајан. И то одлучио 10^4 (што одговара величини од 22 МБ) биће довољно. Мање вредности параметара --size давао израженију буку (на пример, позиви fdatasync, који трају много дуже него обично и утичу на 99. перцентил).

До тебе је

Чланак показује како се користи fio може се проценити да ли је медиј намењен за употребу са етцд-ом довољно брз. Сада је на вама! Можете да истражујете виртуелне машине са складиштем заснованим на ССД-у у услузи ИБМ Цлоуд.

ПС од преводиоца

Са готовим случајевима употребе fio За остале задатке погледајте документација или директно на репозиторијуми пројеката (има иһ много више него што је наведено у документацији).

ППС од преводиоца

Прочитајте и на нашем блогу:

Извор: ввв.хабр.цом

Додај коментар