Кратка прича о фио и етцд
Перформансе кластера у великој мери зависи од перформанси његовог складиштења. етцд извози неке метрике у да обезбеди жељене информације о перформансама складиштења. На пример, метрика вал_фсинц_дуратион_сецондс. : Да би се складиштење сматрало довољно брзим, 99. перцентил овог показатеља мора бити мањи од 10 мс. Ако планирате да покренете етцд кластер на Линук машинама и желите да процените да ли је ваше складиште довољно брзо (нпр. ССД), можете да користите је популаран алат за тестирање И/О операција. Покрените следећу команду, где је тест-дата директоријум испод тачке монтирања складишта:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestСамо треба да погледате резултате и проверите да ли је 99. перцентил трајања мање од 10 мс. Ако јесте, имате релативно брзо складиште. Ево примера резултата:
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]Белешке
- Прилагодили смо опције --сизе и --бс за наш конкретни сценарио. Да бисте добили користан резултат од фио-а, наведите своје вредности. Где да их набавим? читати .
- Током тестирања, сво И/О оптерећење долази од фио-а. У стварном сценарију, вероватно ће постојати и други захтеви за писање у складиште осим оних који се односе на вал_фсинц_дуратион_сецондс. Додатно оптерећење ће повећати вредност вал_фсинц_дуратион_сецондс. Дакле, ако је 99. перцентил близу 10 мс, ваша меморија је на измаку брзине.
- Узми верзију не мање од 3.5 (претходни не приказују перцентиле трајања фдатасинц).
- Горе је само део резултата са фио.
Дуга прича о фио и етцд
Шта је ВАЛ у итд
Обично користе базе података ; етцд га такође користи. Овде нећемо детаљно расправљати о дневнику уписивања унапред (ВАЛ). Довољно је да знамо да га сваки члан етцд кластера одржава у трајном складишту. етцд уписује сваку операцију кључ/вредност (као што је ажурирање) у ВАЛ пре него што је примени на продавницу. Ако се један од чланова складишта сруши и поново покрене између снимака, може локално да врати трансакције од последњег снимка према ВАЛ садржају.
Када клијент дода кључ у складиште кључ/вредност или ажурира вредност постојећег кључа, етцд бележи операцију у ВАЛ, што је обична датотека у трајном складишту. етцд МОРА бити потпуно сигуран да се ВАЛ унос заиста догодио пре него што настави са обрадом. На Линук-у, један системски позив није довољан за ово. , пошто стварно уписивање у физичку меморију може бити одложено. На пример, Линук може неко време да складишти ВАЛ унос у кеш меморији језгра (као што је кеш страница). А да би подаци били тачно уписани у трајно складиште, потребан је системски позив фдатасинц након писања, а етцд га само користи (као што можете видети у резултату рада , где је 8 дескриптор ВАЛ датотеке):
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>Нажалост, писање у трајно складиште се не дешава одмах. Ако је фдатасинц позив спор, перформансе етцд система ће патити. да се складиште сматра довољно брзом ако је, у 99. перцентилу, фдатасинц позивима потребно мање од 10 мс за писање у ВАЛ датотеку. Постоје и друге корисне метрике за складиштење, али у овом посту говоримо само о овој метрици.
Процена складишта са фио
Ако треба да процените да ли је ваша меморија погодна за етцд, користите фио, веома популаран алат за тестирање И/О оптерећења. Треба имати на уму да операције са диском могу бити веома различите: синхроне и асинхроне, многе класе системских позива итд. Као резултат тога, фио је прилично тешко користити. Има много параметара, а различите комбинације њихових вредности производе веома различита И/О радна оптерећења. Да бисте добили адекватне бројке за етцд, требало би да се уверите да је оптерећење теста писања из фио-а што је могуће ближе стварном оптерећењу из етцд-а приликом писања ВАЛ датотека.
Према томе, фио би, у најмању руку, требало да створи оптерећење у облику серије узастопних уписа у датотеку, свако уписивање ће се састојати од системског позива након чега следи системски позив фдатасинц. Секвенцијално уписивање у фио захтева опцију --рв=врите. Да би фио користио системски позив врите приликом писања, а не , требало би да наведете параметар --иоенгине=синц. Коначно, да бисте позвали фдатасинц након сваког писања, потребно је да додате параметар --фдатасинц=1. Друге две опције у овом примеру (--сизе и -бс) су специфичне за скрипту. У следећем одељку ћемо вам показати како да их подесите.
Зашто баш фио и како смо научили да га подесимо
У овом посту описујемо прави случај. Имамо кластер в1.13 који смо пратили са Прометејем. етцд в3.2.24 је био хостован на ССД-у. Етцд метрике су показале да су фдатасинц латенције превисоке, чак и када кластер није радио ништа. метрика је била чудна и ми заправо нисмо знали шта значе. Кластер се састојао од виртуелних машина, било је потребно разумети у чему је проблем: у физичким ССД-овима или у слоју виртуелизације. Поред тога, често смо правили промене у конфигурацији хардвера и софтвера и био нам је потребан начин да проценимо њихове резултате. Могли бисмо да покренемо етцд у свакој конфигурацији и погледамо Прометхеус метрике, али то је превелика мука. Тражили смо прилично једноставан начин да проценимо одређену конфигурацију. Хтели смо да проверимо да ли смо исправно разумели Прометејеве метрике из етцд-а.
Али за ово су морала бити решена два проблема. Прво, како изгледа И/О оптерећење које етцд ствара приликом писања у ВАЛ? Који системски позиви се користе? Која је величина записа? Друго, ако одговоримо на ова питања, како да репродукујемо слично оптерећење са фио-ом? Не заборавите да је фио веома флексибилан алат са много опција. Оба проблема смо решили једним приступом – коришћењем команди и . лсоф наводи све дескрипторе датотека које користи процес и њихове придружене датотеке. А помоћу страце-а можете испитати већ покренути процес или покренути процес и испитати га. страце штампа све системске позиве из процеса који се испитује (и његових подређених процеса). Ово последње је веома важно, пошто етцд користи сличан приступ.
Прво смо користили страце да истражимо етцд сервер за Кубернетес када није било оптерећења на кластеру. Видели смо да су скоро сви ВАЛ записи били приближно исте величине: 2200–2400 бајтова. Због тога смо у команди на почетку поста навели параметар -бс=2300 (бс означава величину у бајтовима за сваки фио унос). Имајте на уму да величина етцд уноса зависи од етцд верзије, дистрибуције, вредности параметара, итд., и утиче на трајање фдатасинц. Ако имате сличан сценарио, испитајте своје етцд процесе са страце да бисте сазнали тачне бројеве.
Затим, да бисмо добили добру представу о томе шта етцд систем датотека ради, започели смо га са страце и -ффттТ опцијама. Зато смо покушали да испитамо подређене процесе и снимимо излаз сваког од њих у посебну датотеку, као и да добијемо детаљне извештаје о почетку и трајању сваког системског позива. Користили смо лсоф да потврдимо нашу анализу страце излаза и видимо који се дескриптор датотеке користи за коју сврху. Дакле, уз помоћ страце-а, добијени су горе приказани резултати. Статистика времена синхронизације је потврдила да је вал_фсинц_дуратион_сецондс из етцд конзистентан са фдатасинц позивима са ВАЛ дескрипторима датотека.
Прошли смо кроз документацију за фио и изабрали опције за нашу скрипту тако да фио генерише оптерећење слично етцд. Такође смо проверили системске позиве и њихово трајање покретањем фио из страце-а, слично као етцд.
Пажљиво смо одабрали вредност параметра --сизе да представља целокупно И/О оптерећење из фио-а. У нашем случају, ово је укупан број бајтова уписаних у складиште. Показало се да је то директно пропорционално броју системских позива за писање (и фдатасинц). За одређену вредност бс, број фдатасинц позива = сизе/бс. Пошто нас је занимао проценат, морали смо да имамо довољно узорака да бисмо били сигурни, и израчунали смо да би нам било довољно 10^4 (то је 22 мебибајта). Ако је --сизе мањи, може доћи до одступања (на пример, неколико фдатасинц позива траје дуже него обично и утиче на 99. перцентил).
Пробајте и сами
Показали смо вам како да користите фио и видите да ли је складиште довољно брзо да етцд ради добро. Сада то можете сами да испробате користећи, на пример, виртуелне машине са ССД меморијом .
Извор: ввв.хабр.цом