Предлажем да прочитате транскрипт извештаја Алексеја Лесовског из Дата Егрет-а „Основе праћења ПостгреСКЛ-а“
У овом извештају, Алексеј Лесовски ће говорити о кључним тачкама пост-грес статистике, шта оне значе и зашто би требало да буду присутне у праћењу; о томе који графикони треба да буду у мониторингу, како их додати и како их тумачити. Извештај ће бити користан администраторима база података, систем администраторима и програмерима који су заинтересовани за решавање проблема са Постгресом.
Моје име је Алексеј Лесовски, представљам компанију Дата Егрет.
Неколико речи о себи. Почео сам давно као систем администратор.
Администрирао сам разне врсте Линук система, радио на разним стварима везаним за Линук, тј. виртуелизацију, надгледање, радио са проксијима, итд. Али у једном тренутку сам почео више да радим са базама података, ПостгреСКЛ. Стварно ми се допао. И у неком тренутку сам почео да радим на ПостгреСКЛ-у већину свог радног времена. И тако сам постепено постао ПостгреСКЛ ДБА.
И током моје каријере увек су ме занимале теме статистике, мониторинга и телеметрије. А када сам био систем администратор, веома сам блиско сарађивао са Заббик-ом. И написао сам мали сет сценарија као што је . Био је прилично популаран у своје време. И тамо је било могуће пратити веома различите важне ствари, не само Линук, већ и разне компоненте.
Сада радим на ПостгреСКЛ-у. Већ пишем још једну ствар која вам омогућава да радите са ПостгреСКЛ статистиком. Зове се (чланак на Хабреу - ).
Мала уводна напомена. Какве ситуације имају наши купци, наши клијенти? Постоји нека врста незгоде у вези са базом података. А када је база података већ рестаурирана, долази шеф одељења или шеф развоја и каже: „Пријатељи, треба да пратимо базу података, јер се нешто лоше десило и треба да спречимо да се то дешава у будућности. И ту почиње занимљив процес избора система за праћење или прилагођавања постојећег система за праћење како бисте могли да пратите своју базу података – ПостгреСКЛ, МиСКЛ или неке друге. И колеге почињу да предлажу: „Чуо сам да постоји таква и таква база података. Хајде да га искористимо." Колеге почињу да се свађају. И на крају се испостави да бирамо неку врсту базе података, али је ПостгреСКЛ праћење у њој представљено прилично лоше и увек морамо нешто да додамо. Узмите нека спремишта са ГитХуб-а, клонирајте их, прилагодите скрипте и некако их прилагодите. И на крају се заврши као нека врста ручног рада.
Због тога ћу у овом говору покушати да вам дам неко знање о томе како да изаберете праћење не само за ПостгреСКЛ, већ и за базу података. И дајте вам знање које ће вам омогућити да завршите своје праћење како бисте извукли неку корист од тога, тако да можете са користима надгледати своју базу података, како бисте брзо спречили било које предстојеће ванредне ситуације које могу настати.
А идеје које ће бити у овом извештају могу се директно прилагодити било којој бази података, било да је то ДБМС или ноСКЛ. Према томе, не постоји само ПостгреСКЛ, већ ће постојати много рецепата како то учинити у ПостгреСКЛ-у. Биће примери упита, примери ентитета које ПостгреСКЛ има за праћење. А ако ваш ДБМС има исте ствари које вам омогућавају да их ставите у надзор, можете их и прилагодити, додати и биће добро.
Нећу бити у извештају
разговарајте о томе како да испоручите и сачувате метрику. О накнадној обради података и представљању кориснику нећу ништа рећи. И нећу рећи ништа о узбуњивању.
Али како прича буде напредовала, показаћу различите снимке постојећег надгледања и некако их критиковати. Али ипак, покушаћу да не именујем брендове како не бих стварао рекламирање или анти-рекламу за ове производе. Стога су све случајности случајне и препуштене су вашој машти.
Прво, хајде да схватимо шта је надгледање. Мониторинг је веома важна ствар. Ово сви разумеју. Али у исто време, праћење се не односи на пословни производ и не утиче директно на профит компаније, тако да се време увек издваја за праћење на резидуалној основи. Ако имамо времена, онда радимо мониторинг; ако немамо времена, онда ћемо то ставити у заостатак и једног дана ћемо се вратити овим задацима.
Дакле, из наше праксе, када дођемо до клијената, праћење је често непотпуно и нема занимљивости које би нам помогле да боље радимо са базом података. И стога праћење увек треба да се заврши.
Базе података су тако сложене ствари које такође треба пратити, јер су базе података складиште информација. А информације су веома важне за компанију, не могу се изгубити ни на који начин. Али у исто време, базе података су веома сложени делови софтвера. Састоје се од великог броја компоненти. И многе од ових компоненти треба пратити.
Ако говоримо конкретно о ПостгреСКЛ-у, онда се он може представити у облику шеме која се састоји од великог броја компоненти. Ове компоненте међусобно делују. А у исто време, ПостгреСКЛ има такозвани подсистем Статс Цоллецтор, који вам омогућава да прикупите статистику о раду ових подсистема и обезбедите неку врсту интерфејса администратору или кориснику како би он могао да види ове статистике.
Ове статистике су представљене у облику одређеног скупа функција и погледа. Могу се назвати и столовима. То јест, користећи обичан пскл клијент, можете се повезати са базом података, изабрати ове функције и приказе и добити неке специфичне бројеве о раду ПостгреСКЛ подсистема.
Можете додати ове бројеве свом омиљеном систему за праћење, нацртати графиконе, додати функције и добити аналитику на дужи рок.
Али у овом извештају нећу у потпуности покривати све ове функције, јер би то могло да потраје цео дан. Дословно ћу се осврнути на две, три или четири ствари и рећи вам како оне помажу да праћење буде боље.
А ако говоримо о праћењу базе података, шта онда треба пратити? Пре свега, потребно је да пратимо доступност, јер је база података сервис који клијентима омогућава приступ подацима и потребно је да пратимо доступност, као и да обезбедимо неке од њених квалитативних и квантитативних карактеристика.
Такође морамо да пратимо клијенте који се повезују на нашу базу података, јер они могу бити и нормални и штетни клијенти који могу да нашкоде бази података. Такође их треба пратити и пратити њихове активности.
Када се клијенти повежу са базом података, очигледно је да почињу да раде са нашим подацима, тако да морамо да пратимо како клијенти раде са подацима: са којим табелама, а у мањој мери, са којим индексима. То јест, треба да проценимо оптерећење које стварају наши клијенти.
Али оптерећење се такође састоји, наравно, од захтева. Апликације се повезују на базу података, приступају подацима помоћу упита, па је важно да проценимо које упите имамо у бази, да пратимо њихову адекватност, да нису криво написани, да неке опције треба преписати и направити тако да раде брже и са бољим перформансама.
А пошто говоримо о бази података, база података је увек процес у позадини. Позадински процеси помажу у одржавању перформанси базе података на добром нивоу, тако да им је потребна одређена количина ресурса за рад. У исто време, они се могу преклапати са ресурсима захтева клијената, тако да похлепни позадински процеси могу директно утицати на перформансе захтева клијената. Стога их такође треба пратити и пратити како не би дошло до изобличења у погледу позадинских процеса.
И све ово у смислу праћења базе података остаје у системској метрици. Али с обзиром на то да се већина наше инфраструктуре сели у облаке, системске метрике појединачног хоста увек бледе у позадини. Али у базама података они су и даље релевантни и, наравно, такође је потребно пратити системске метрике.
Са системским метрикама све је мање-више у реду, сви савремени системи за праћење већ подржавају ове метрике, али генерално, неке компоненте још увек нису довољне и неке ствари треба додати. Дотакнућу се и њих, биће неколико слајдова о њима.
Прва тачка плана је приступачност. Шта је приступачност? Доступност по мом схватању је способност базе да сервисира везе, односно база се подиже, она као сервис прихвата везе од клијената. А ова приступачност се може оценити одређеним карактеристикама. Веома је згодно приказати ове карактеристике на контролној табли.
Сви знају шта су контролне табле. Тада сте бацили један поглед на екран на коме су сажете потребне информације. И одмах можете утврдити да ли постоји проблем у бази података или не.
Сходно томе, доступност базе података и друге кључне карактеристике увек треба да буду приказане на контролним таблама тако да вам ове информације буду при руци и увек доступне. Неки додатни детаљи који већ помажу у истрази инцидената, када се истражују неке ванредне ситуације, већ морају бити постављени на секундарне контролне табле, или сакривени у дриллдовн линковима који воде до система за праћење треће стране.
Пример једног познатог система за праћење. Ово је веома кул систем за праћење. Она прикупља много података, али са моје тачке гледишта, она има чудан концепт контролне табле. Постоји веза за „креирање контролне табле“. Али када креирате контролну таблу, креирате листу од две колоне, листу графикона. А када треба нешто да погледате, почнете да кликнете мишем, скролујете, тражите жељени графикон. А за ово је потребно време, тј. не постоје контролне табле као такве. Постоје само листе графикона.
Шта треба да додате на ове контролне табле? Можете почети са таквом карактеристиком као што је време одзива. ПостгреСКЛ има приказ пг_стат_статементс. Подразумевано је онемогућен, али је један од важних системских погледа који увек треба омогућити и користити. Он чува информације о свим покренутим упитима који су извршени у бази података.
Сходно томе, можемо поћи од чињенице да можемо узети укупно време извршења свих захтева и поделити га са бројем захтева користећи горња поља. Али ово је просечна температура у болници. Можемо да почнемо од других поља – минимално време извршења упита, максимално и медијана. Можемо чак и да направимо перцентиле; ПостгреСКЛ има одговарајуће функције за ово. И можемо добити неке бројке које карактеришу време одговора наше базе података за већ завршене захтеве, односно не извршавамо лажни захтев 'одабери 1' и гледамо време одговора, већ анализирамо време одговора за већ завршене захтеве и извлачимо или засебна фигура, или на основу ње градимо графикон.
Такође је важно пратити број грешака које тренутно генерише систем. А за ово можете користити приказ пг_стат_датабасе. Фокусирамо се на поље кацт_роллбацк. Ово поље приказује не само број враћања у базу података, већ узима у обзир и број грешака. Релативно говорећи, можемо приказати ову цифру на нашој контролној табли и видети колико грешака тренутно имамо. Ако има много грешака, онда је ово добар разлог да погледате у логове и видите какве су то грешке и зашто настају, а затим уложите и решите их.
Можете додати такву ствар као што је тахометар. То су број трансакција у секунди и број захтева у секунди. Релативно говорећи, можете користити ове бројеве као тренутне перформансе ваше базе података и посматрати да ли постоје врхунци у захтевима, врхунци у трансакцијама, или, обрнуто, да ли је база података недовољно учитана јер је неки бацкенд отказао. Важно је да увек гледате ову цифру и запамтите да је за наш пројекат оваква перформанса нормална, али вредности изнад и испод су већ неке врсте проблематичне и неразумљиве, што значи да треба да погледамо зашто су ови бројеви тако високо.
Да бисмо проценили број трансакција, поново можемо да се позовемо на приказ пг_стат_датабасе. Можемо да саберемо број урезивања и број враћања и добијемо број трансакција у секунди.
Да ли сви разумеју да се неколико захтева може уклопити у једну трансакцију? Стога се ТПС и КПС мало разликују.
Број захтева у секунди се може добити из пг_стат_статементс и једноставно израчунати збир свих испуњених захтева. Јасно је да упоредимо тренутну вредност са претходном, одузмемо је, добијемо делту и добијемо количину.
По жељи можете додати додатне метрике, које такође помажу у процени доступности наше базе података и надгледању да ли је било застоја.
Један од ових показатеља је време непрекидног рада. Али продужење рада у ПостгреСКЛ-у је мало незгодно. Рећи ћу ти зашто. Када се ПостгреСКЛ покрене, време непрекидног рада почиње да извештава. Али ако је у неком тренутку, на пример, неки задатак био покренут ноћу, дошао је ООМ-убица и насилно прекинуо ПостгреСКЛ подређени процес, онда у овом случају ПостгреСКЛ прекида везу свих клијената, ресетује област подељене меморије и почиње опоравак од последњи контролни пункт. И док траје овај опоравак са контролне тачке, база података не прихвата везе, односно ова ситуација се може оценити као застој. Али бројач радног времена неће бити ресетован, јер узима у обзир време покретања постмастера од првог тренутка. Стога се такве ситуације могу прескочити.
Такође треба пратити број радника усисивача. Да ли сви знају шта је аутовакуум у ПостгреСКЛ-у? Ово је занимљив подсистем у ПостгреСКЛ-у. О њој је написано много чланака, направљено много извештаја. Постоји много дискусија о вакууму и о томе како би требало да функционише. Многи то сматрају неопходним злом. Али то је тако. Ово је нека врста аналога сакупљача смећа који чисти застареле верзије редова које нису потребне ниједној трансакцији и ослобађа простор у табелама и индексима за нове редове.
Зашто га морате пратити? Зато што вакуум понекад много боли. То троши велику количину ресурса и захтеви клијената почињу да трпе као резултат.
И треба га пратити кроз пг_стат_ацтивити приказ, о чему ћу говорити у следећем одељку. Овај приказ приказује тренутну активност у бази података. И кроз ову активност можемо пратити број усисивача који тренутно раде. Можемо да пратимо вакууме и видимо да ако смо прекорачили границу, онда је то разлог да погледамо поставке ПостгреСКЛ-а и некако оптимизујемо рад усисивача.
Још једна ствар у вези са ПостгреСКЛ-ом је да је ПостгреСКЛ-у веома мука од дугих трансакција. Нарочито од трансакција које дуго стоје и не раде ништа. Ово је такозвана стат неактивна у трансакцији. Таква трансакција држи браве и спречава рад вакуума. И као резултат тога, столови набубре и повећавају се у величини. А упити који раде са овим табелама почињу да раде спорије, јер морате да избаците све старе верзије редова из меморије на диск и назад. Стога, време, трајање најдужих трансакција, најдужи захтеви за вакуум такође треба да се прате. А ако видимо неке процесе који раде веома дуго, већ више од 10-20-30 минута за ОЛТП оптерећење, онда треба да обратимо пажњу на њих и насилно их укинемо, или оптимизујемо апликацију тако да не зову се и не виси тако дуго. За аналитичко оптерећење нормално је 10-20-30 минута, има и дужих.
Затим имамо опцију са повезаним клијентима. Када смо већ направили контролну таблу и објавили кључне метрике доступности на њој, можемо тамо додати и додатне информације о повезаним клијентима.
Информације о повезаним клијентима су важне јер су, из перспективе ПостгреСКЛ-а, клијенти различити. Има добрих и лоших клијената.
Једноставан пример. Под клијентом разумем апликацију. Апликација се повезала са базом података и одмах почиње да шаље своје захтеве тамо, база података их обрађује и извршава и враћа резултате клијенту. То су добри и коректни клијенти.
Постоје ситуације када се клијент повезао, он држи везу, али не ради ништа. Налази се у стању мировања.
Али има лоших клијената. На пример, исти клијент се повезао, отворио трансакцију, урадио нешто у бази података и затим ушао у код, на пример, да приступи спољном извору или да тамо обради примљене податке. Али он није закључио трансакцију. И трансакција виси у бази података и држи се у брави на линији. Ово је лоше стање. А ако изненада нека апликација негде унутар себе пропадне са изузетком, онда трансакција може остати отворена веома дуго. А ово директно утиче на перформансе ПостгреСКЛ-а. ПостгреСКЛ ће бити спорији. Стога је важно благовремено пратити такве клијенте и насилно прекинути њихов рад. И потребно је да оптимизујете своју апликацију како се такве ситуације не би дешавале.
Други лоши клијенти су клијенти који чекају. Али они постају лоши због околности. На пример, једноставна трансакција у стању мировања: може да отвори трансакцију, да закључа неке линије, а затим негде у коду неће успети, остављајући трансакцију која виси. Доћи ће други клијент и затражити исте податке, али ће наићи на закључавање, јер та висећа трансакција већ држи браве на неким траженим редовима. А друга трансакција ће чекати да се прва трансакција заврши или је администратор присилно затвори. Због тога се трансакције на чекању могу акумулирати и испунити ограничење везе са базом података. А када је лимит пун, апликација више не може да ради са базом података. Ово је већ ванредна ситуација за пројекат. Због тога, лоше клијенте треба пратити и благовремено реаговати.
Још један пример праћења. А овде већ постоји пристојна контролна табла. Горе су информације о везама. ДБ прикључак – 8 комада. И то је све. Немамо информације о томе који клијенти су активни, који клијенти само не раде, не раде ништа. Нема информација о трансакцијама на чекању и везама на чекању, односно ово је бројка која показује број веза и то је то. А онда погодите сами.
Сходно томе, да бисте додали ове информације надзору, потребно је да приступите системском приказу пг_стат_ацтивити. Ако проводите доста времена у ПостгреСКЛ-у, онда је ово веома добар поглед који би требало да вам постане пријатељ, јер приказује тренутну активност у ПостгреСКЛ-у, односно шта се у њему дешава. За сваки процес постоји посебна линија која приказује информације о овом процесу: са ког хоста је успостављена веза, под којим корисником, под којим именом, када је трансакција покренута, који захтев је тренутно покренут, који захтев је последњи пут извршен. И, сходно томе, можемо проценити стање клијента помоћу поља стат. Релативно говорећи, можемо груписати по овом пољу и добити оне статистике које се тренутно налазе у бази података и број конекција које имају ову статистику у бази. А већ примљене бројеве можемо послати на наш мониторинг и на основу њих нацртати графиконе.
Такође је важно проценити трајање трансакције. Већ сам рекао да је важно проценити трајање вакуума, али трансакције се процењују на исти начин. Постоје поља кацт_старт и куери_старт. Они, релативно говорећи, показују време почетка трансакције и време почетка захтева. Узимамо функцију нов() која приказује тренутну временску ознаку и одузимамо временску ознаку трансакције и захтева. И добијамо трајање трансакције, трајање захтева.
Ако видимо дуге трансакције, требало би да их већ завршимо. За ОЛТП оптерећење, дуге трансакције су већ дуже од 1-2-3 минута. За ОЛАП радно оптерећење, дуге трансакције су нормалне, али ако им је потребно више од два сата да се заврше, то је такође знак да негде имамо искривљење.
Када се клијенти повежу са базом података, почињу да раде са нашим подацима. Они приступају табелама, приступају индексима да би добили податке из табеле. И важно је проценити како клијенти комуницирају са овим подацима.
Ово је неопходно да бисмо проценили наше оптерећење и грубо разумели који су столови за нас „најтоплији“. На пример, ово је потребно у ситуацијама када желимо да поставимо „вруће“ столове на неку врсту брзог ССД меморије. На пример, неке архивске табеле које нисмо дуго користили можемо преместити у неку врсту „хладне” архиве, на САТА дискове и оставити их да живе тамо, приступаће им се по потреби.
Ово је такође корисно за откривање аномалија након издавања и примене. Рецимо да је пројекат објавио неку нову функцију. На пример, додали смо нову функционалност за рад са базом података. А ако нацртамо графиконе коришћења табеле, лако можемо открити ове аномалије на овим графиконима. На пример, ажурирајте низове или избришите низове. Биће врло видљиво.
Такође можете открити аномалије у „плутајућој“ статистици. Шта то значи? ПостгреСКЛ има веома јак и веома добар планер упита. А програмери посвећују доста времена његовом развоју. Како он ради? Да би направио добре планове, ПостгреСКЛ прикупља статистику о дистрибуцији података у табелама у одређеном временском интервалу и са одређеном фреквенцијом. Ово су најчешће вредности: број јединствених вредности, информације о НУЛЛ у табели, много информација.
На основу ове статистике, планер конструише неколико упита, бира најоптималнији и користи овај план упита да изврши сам упит и врати податке.
И дешава се да статистика "плута". Подаци о квалитету и квантитету су се некако променили у табели, али статистика није прикупљена. А формирани планови можда нису оптимални. А ако се наши планови испостави да су неоптимални на основу прикупљеног мониторинга, на основу табела, моћи ћемо да видимо ове аномалије. На пример, негде су се подаци квалитативно променили и уместо индекса почео је да се користи секвенцијални пролаз кроз табелу, тј. ако упит треба да врати само 100 редова (постоји ограничење од 100), онда ће се за овај упит извршити комплетна претрага. А ово увек има веома лош утицај на перформансе.
И то можемо видети у праћењу. И већ погледајте овај упит, покрените објашњење за њега, прикупите статистику, направите нови додатни индекс. И већ одговорите на овај проблем. Зато је важно.
Још један пример праћења. Мислим да су га многи препознали јер је веома популаран. Ко то користи у својим пројектима ? Ко користи овај производ у комбинацији са Прометхеусом? Чињеница је да у стандардном спремишту овог надзора постоји контролна табла за рад са ПостгреСКЛ - Прометеј. Али постоји један лош детаљ.
Постоји неколико графикона. А бајтови су означени као јединица, тј. има 5 графикона. То су Убаци податке, Ажурирај податке, Избриши податке, Преузми податке и Врати податке. Јединица мерења су бајтови. Али ствар је у томе што статистика у ПостгреСКЛ-у враћа податке у тупле (редовима). И, сходно томе, ови графикони су веома добар начин да потцените своје оптерећење неколико пута, десетине пута, јер торка није бајт, торка је стринг, има много бајтова и увек је променљиве дужине. То јест, израчунавање радног оптерећења у бајтовима коришћењем тупле-а је нереалан задатак или веома тежак. Стога, када користите контролну таблу или уграђени надзор, увек је важно да разумете да исправно ради и да вам враћа исправно процењене податке.
Како доћи до статистике о овим табелама? У ту сврху, ПостгреСКЛ има одређену породицу погледа. А главни поглед је . Корисничке_табеле - ово значи табеле креиране у име корисника. Насупрот томе, постоје системски погледи које користи сам ПостгреСКЛ. А ту је и табела сажетка Аллтаблес, која укључује и системске и корисничке. Можете почети од било којег од њих који вам се највише свиђа.
Користећи горња поља можете проценити број уметања, ажурирања и брисања. Пример контролне табле који сам користио користи ова поља за процену карактеристика радног оптерећења. Стога, можемо и градити на њима. Али вреди запамтити да су ово торке, а не бајтови, тако да не можемо то да радимо само у бајтовима.
На основу ових података можемо да направимо такозване ТопН табеле. На пример, Топ-5, Топ-10. И можете пратити оне вруће столове који се рециклирају више од других. На пример, 5 „врућих“ табела за уметање. А користећи ове ТопН табеле, процењујемо наше радно оптерећење и можемо да проценимо низове оптерећења након било каквих издања, ажурирања и примене.
Такође је важно проценити величину табеле, јер понекад програмери уводе нову функцију, а наше табеле почињу да се повећавају у својим великим величинама, јер су одлучили да додају додатну количину података, али нису предвидели како ће то утичу на величину базе података. Такви случајеви нас такође изненађују.
А сада мало питање за вас. Које питање се поставља када приметите оптерећење вашег сервера базе података? Које је следеће питање које имате?
Али у ствари се поставља следеће питање. Које захтеве изазива оптерећење? Односно, није занимљиво гледати процесе који су узроковани оптерећењем. Јасно је да ако хост има базу података, онда је база података тамо покренута и јасно је да ће се тамо одлагати само базе података. Ако отворимо Топ, видећемо тамо листу процеса у ПостгреСКЛ-у који нешто раде. Врху неће бити јасно шта раде.
Сходно томе, морате пронаћи оне упите који изазивају највеће оптерећење, јер упити за подешавање, по правилу, доносе више профита од подешавања ПостгреСКЛ-а или конфигурације оперативног система, или чак подешавања хардвера. По мојој процени, то је отприлике 80-85-90%. И ово се ради много брже. Брже је исправити захтев него исправити конфигурацију, заказати поновно покретање, посебно ако се база података не може поново покренути, или додати хардвер. Лакше је преписати упит негде или додати индекс да бисте добили бољи резултат из овог упита.
Сходно томе, потребно је пратити захтеве и њихову адекватност. Узмимо још један пример праћења. И овде се чини да постоји одличан надзор. Постоје информације о репликацији, постоје информације о пропусности, блокирању, коришћењу ресурса. Све је у реду, али нема информација о захтевима. Није јасно који упити се покрећу у нашој бази података, колико дуго трају, колико је ових упита. Увек морамо да имамо ове информације у нашем надзору.
А да бисмо добили ове информације, можемо користити модул пг_стат_статементс. На основу тога можете направити различите графиконе. На пример, можете добити информације о најчешћим упитима, односно о оним упитима који се најчешће извршавају. Да, након распоређивања такође је веома корисно погледати га и разумети да ли постоји пораст захтева.
Можете пратити најдуже упите, односно оне упите за које је потребно најдуже да се заврше. Они раде на процесору, троше И/О. Ово такође можемо проценити помоћу поља тотал_тиме, меан_тиме, блк_врите_тиме и блк_реад_тиме.
Можемо да проценимо и надгледамо најтеже захтеве у смислу коришћења ресурса, оне који читају са диска, који раде са меморијом или, обрнуто, стварају неку врсту оптерећења писања.
Можемо да проценимо најиздашније захтеве. Ово су упити који враћају велики број редова. На пример, ово може бити неки захтев где су заборавили да поставе ограничење. И једноставно враћа цео садржај табеле или упита кроз упитне табеле.
Такође можете пратити упите који користе привремене датотеке или привремене табеле.
И још увек имамо позадинске процесе. Позадински процеси су првенствено контролне тачке или се називају и контролне тачке, то су аутовакуум и репликација.
Још један пример праћења. На левој страни је картица Одржавање, идите на њу и надајте се да ћете видети нешто корисно. Али овде је само време рада вакуума и прикупљања статистике, ништа више. Ово је веома лоша информација, тако да увек морамо да имамо информације о томе како функционишу позадински процеси у нашој бази података и да ли има проблема у њиховом раду.
Када посматрамо контролне тачке, треба да запамтимо да контролне тачке испуштају прљаве странице из области подељене меморије на диск, а затим креирају контролну тачку. И ова контролна тачка се онда може користити као место за опоравак ако је ПостгреСКЛ изненада прекинут у хитном случају.
Сходно томе, да бисте избацили све „прљаве“ странице на диск, потребно је да урадите одређену количину писања. И, по правилу, на системима са великом количином меморије, ово је много. А ако вршимо контролне тачке врло често у кратком интервалу, онда ће перформансе диска значајно пасти. А захтеви клијената ће патити због недостатка ресурса. Они ће се такмичити за ресурсе и недостајаће им продуктивност.
Сходно томе, преко пг_стат_бгвритер користећи наведена поља можемо пратити број контролних тачака који се јављају. А ако имамо пуно контролних тачака у одређеном временском периоду (за 10-15-20 минута, за пола сата), на пример, 3-4-5, онда то већ може бити проблем. И већ морате погледати у базу података, погледати у конфигурацији, шта узрокује такво обиље контролних тачака. Можда је у току нека врста великог снимања. Већ можемо да проценимо оптерећење, јер смо већ додали графиконе оптерећења. Већ можемо да подесимо параметре контролне тачке и да се уверимо да они не утичу много на перформансе упита.
Поново се враћам на аутовакуум јер је то таква ствар, као што сам рекао, која лако може да сабере перформансе диска и упита, тако да је увек важно проценити количину аутовакума.
Број аутовакумаша у бази података је ограничен. Подразумевано их има три, тако да ако увек имамо три радника који раде у бази података, то значи да наш аутовакуум није конфигурисан, морамо да подигнемо границе, ревидирамо подешавања аутовакума и уђемо у конфигурацију.
Важно је да проценимо које усисиваче имамо. Или је покренут од корисника, ДБА је дошао и ручно покренуо неку врсту вакуума, и то је створило оптерећење. Имамо неку врсту проблема. Или је ово број усисивача који одврћу бројач трансакција. За неке верзије ПостгреСКЛ-а ово су веома тешки усисивачи. И лако могу да саберу перформансе јер читају целу табелу, скенирају све блокове у тој табели.
И, наравно, трајање вакуума. Ако имамо дуготрајне усисиваче који раде веома дуго, онда то значи да поново треба да обратимо пажњу на конфигурацију усисивача и можда преиспитамо њена подешавања. Јер може настати ситуација када усисивач ради на столу дуго (3-4 сата), али за време рада усисивача, велика количина мртвих редова је успела да се поново акумулира у табели. И чим се усисавање заврши, треба поново да усиса овај сто. И долазимо у ситуацију – бескрајни вакуум. И у овом случају, вакуум не ради свој посао, а табеле постепено почињу да набубре у величини, иако обим корисних података у њему остаје исти. Због тога, током дугих вакуума, увек гледамо конфигурацију и покушавамо да је оптимизујемо, али у исто време тако да перформансе захтева клијената не трпе.
Данас практично не постоји ПостгреСКЛ инсталација која нема стриминг репликацију. Репликација је процес премештања података са главног на реплику.
Репликација у ПостгреСКЛ-у се врши преко евиденције трансакција. Чаробњак генерише дневник трансакција. Евиденција трансакција путује преко мрежне везе до реплике, а затим се репродукује на реплици. То је једноставно.
Сходно томе, пг_стат_реплицатион поглед се користи за праћење кашњења репликације. Али са њом није све једноставно. У верзији 10, поглед је претрпео неколико промена. Прво, нека поља су преименована. И нека поља су додата. У верзији 10 појавила су се поља која вам омогућавају да процените кашњење репликације у секундама. Веома је удобно. Пре верзије 10, било је могуће проценити кашњење репликације у бајтовима. Ова опција остаје у верзији 10, односно можете изабрати шта вам је згодније - процените кашњење у бајтовима или процените кашњење у секундама. Многи људи раде обоје.
Али ипак, да бисте проценили кашњење репликације, морате знати позицију дневника у трансакцији. И ове позиције евиденције трансакција су тачно у пг_стат_реплицатион приказу. Релативно говорећи, можемо узети две тачке у евиденцији трансакција користећи функцију пг_клог_лоцатион_дифф(). Израчунајте делта између њих и добијте кашњење репликације у бајтовима. Веома је згодно и једноставно.
У верзији 10, ова функција је преименована у пг_вал_лсн_дифф(). Генерално, у свим функцијама, погледима и услужним програмима где се појавила реч „клог“, она је замењена вредношћу „вал“. Ово се односи и на погледе и на функције. Ово је таква иновација.
Плус, у верзији 10, додате су линије које посебно показују заостајање. То су кашњење у писању, кашњење у испирању, кашњење у поновном репродукцији. Односно, важно је пратити ове ствари. Ако видимо да имамо кашњење у репликацији, онда морамо да истражимо зашто се појавио, одакле је дошао и да решимо проблем.
Скоро све је у реду са системским метрикама. Када почне било какво праћење, почиње са системским метрикама. Ово је одлагање процесора, меморије, размене, мреже и диска. Међутим, многи параметри нису тамо подразумевано.
Ако је све у реду са процесом рециклирања, онда постоје проблеми са рециклирањем диска. По правилу, програмери за праћење додају информације о пропусности. Може бити у иопс или бајтовима. Али заборављају на кашњење и коришћење диск уређаја. Ово су важнији параметри који нам омогућавају да проценимо колико су наши дискови оптерећени и колико су спори. Ако имамо велико кашњење, онда то значи да постоје неки проблеми са дисковима. Ако имамо високу искоришћеност, то значи да се дискови не сналазе. Ово су боље карактеристике од пропусности.
Штавише, ове статистике се такође могу добити из система датотека /проц, као што се ради за процесоре за рециклажу. Не знам зашто се ове информације не додају праћењу. Али ипак, важно је да ово имате у свом надзору.
Исто важи и за мрежне интерфејсе. Постоје информације о мрежној пропусности у пакетима, у бајтовима, али ипак нема информација о кашњењу нити информација о коришћењу, мада је и ово корисна информација.
Свако праћење има недостатке. И какав год мониторинг да будете предузели, он увек неће испунити неке критеријуме. Али ипак се развијају, додају се нове функције и нове ствари, па изаберите нешто и завршите.
А да бисте завршили, увек морате имати представу о томе шта дате статистике значе и како их можете користити за решавање проблема.
И неколико кључних тачака:
- Увек треба да пратите доступност и да имате контролне табле како бисте брзо проценили да ли је све у реду са базом података.
- Увек морате да имате представу о томе који клијенти раде са вашом базом података како бисте искоријенили лоше клијенте и оборили их.
- Важно је проценити како ови клијенти раде са подацима. Морате имати идеју о свом послу.
- Важно је проценити како се ово радно оптерећење формира, уз помоћ којих упита. Можете да процените упите, можете да их оптимизујете, преправите, направите индексе за њих. Врло је важно.
- Позадински процеси могу негативно утицати на захтеве клијената, па је важно пратити да не користе превише ресурса.
- Системске метрике вам омогућавају да правите планове за скалирање и повећање капацитета ваших сервера, тако да је важно да их такође пратите и процените.
Ако сте заинтересовани за ову тему, онда можете пратити ове везе.
- ово је званична документација сакупљача статистике. Постоји опис свих статистичких прегледа и опис свих поља. Можете их читати, разумети и анализирати. И на основу њих направите своје графиконе и додајте их свом надзору.
Примери захтева:
Ово је наше корпоративно складиште и моје. Они садрже примере упита. Тамо нема упита из одабраних* из серије. Већ постоје готови упити са спојевима, користећи занимљиве функције које вам омогућавају да претворите необрађене бројеве у читљиве, погодне вредности, односно то су бајтови, време. Можете их покупити, погледати, анализирати, додати у свој мониторинг, изградити своје праћење на основу њих.
pitanja
Питање: Рекли сте да нећете рекламирати брендове, али сам и даље радознао - какве контролне табле користите у својим пројектима?
Одговор: Разликује се. Дешава се да дођемо до купца и он већ има свој надзор. И саветујемо купца о томе шта треба додати њиховом праћењу. Најгора ситуација је са Заббиком. Зато што нема могућност изградње ТопН графикона. Ми сами користимо , јер смо се консултовали са овим момцима о надгледању. Они су надгледали ПостгреСКЛ на основу наших техничких спецификација. Пишем свој пројекат за кућне љубимце, који прикупља податке преко Прометеја и приказује их . Мој задатак је да направим свој извозник у Прометеју и онда све рендерујем у Графани.
Питање: Да ли постоје аналози АВР извештаја или... агрегације? Знате ли за овако нешто?
Одговор: Да, знам шта је АВР, то је кул ствар. Тренутно постоје различити бицикли који имплементирају приближно следећи модел. У одређеном временском интервалу, неке основне линије се записују у исти ПостгреСКЛ или у засебно складиште. Можете их прогуглати на интернету, тамо су. Један од програмера такве ствари седи на форуму скл.ру у теми ПостгреСКЛ. Можете га ухватити тамо. Да, постоје такве ствари, могу се користити. Плус у свом Такође пишем нешто што вам омогућава да урадите исту ствар.
ПС1 Ако користите постгрес_екпортер, коју контролну таблу користите? Има их неколико. Они су већ застарели. Можда ће заједница направити ажурирани шаблон?
ПС2 Уклоњен пганализе јер је то власничка СааС понуда која се фокусира на праћење перформанси и аутоматске предлоге за подешавање.
Само регистровани корисници могу учествовати у анкети. , Добродошао си.
Које постгрескл надгледање (са контролном таблом) које сами хостујете сматрате најбољим?
-
100%Заббик + додаци од Алексеја Лесовског или заббик 4.4 или либзбкпгскл + заббик либзбкпгскл + заббик3
-
100%https://github.com/lesovsky/pgcenter0
-
100%https://github.com/pg-monz/pg_monz0
-
100%https://github.com/cybertec-postgresql/pgwatch22
-
100%https://github.com/postgrespro/mamonsu2
-
100%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0
-
100%пганализе је власнички СааС - не могу да га избришем1
-
100%https://github.com/powa-team/powa1
-
100%https://github.com/darold/pgbadger0
-
100%https://github.com/darold/pgcluu0
-
100%https://github.com/zalando/PGObserver0
-
100%https://github.com/spotify/postgresql-metrics1
Гласало је 10 корисника. Уздржано је било 26 корисника.
Извор: ввв.хабр.цом