Основи за следење на PostgreSQL. Алексеј Лесовски

Ви предлагам да се запознаете со транскриптот од извештајот на Алексеј Лесовски од Data Egret „Основи на PostgreSQL мониторинг“

Во овој извештај, Алексеј Лесовски ќе зборува за клучните точки на постгрес статистиката, што тие значат и зошто тие треба да бидат вклучени во мониторингот; за тоа кои графикони треба да бидат во мониторингот, како да се додадат и како да се толкуваат. Извештајот ќе биде корисен за администраторите на базата на податоци, системските администратори и програмерите кои се заинтересирани за отстранување проблеми на Postgres.

Јас се викам Алексеј Лесовски, го застапувам Дата Егрет.

Неколку зборови за себе. Почнав одамна како системски администратор.

Администрирав секакви различни Линукс, правев разни работи поврзани со Линукс, т.е. виртуелизација, следење, работев со прокси итн. Но, во одреден момент станав повеќе вклучен во базите на податоци, PostgreSQL. Навистина ми се допадна. И во одреден момент, почнав да се занимавам со PostgreSQL поголемиот дел од моето работно време. И така постепено станав PostgreSQL DBA.

И во текот на мојата кариера отсекогаш ме интересираа темите статистика, мониторинг, телеметрија. И кога бев системски администратор, работев многу напорно на Zabbix. И напиша мал сет на скрипти како zabbix-екстензии. Тој беше доста популарен во своето време. И таму беше можно да се следат многу различни важни работи, не само Linux, туку и различни компоненти.

Сега веќе правам PostgreSQL. Веќе пишувам уште една работа што ви овозможува да работите со статистиката на PostgreSQL. Тоа се нарекува pgCenter (напис на Хабре - Постгрес статистика без нерви и напнатост).

Мал вовед. Какви се состојбите со нашите клиенти, со нашите клиенти? Има некаква несреќа поврзана со базата на податоци. И кога базата е веќе обновена, доаѓа шефот на одделот или раководителот за развој и вели: „Пријатели, треба да ја следиме базата на податоци, бидејќи се случи нешто лошо и неопходно е тоа да не се случи во иднина“. И тука започнува интересниот процес на избор на систем за следење или прилагодување на постоечки систем за следење за да можете да ја следите вашата база на податоци - PostgreSQL, MySQL или некои други. И колегите почнуваат да нудат: „Слушнав дека постои таква и таква база на податоци. Ајде да го искористиме“. Колегите почнуваат да се расправаат меѓу себе. И на крајот, излегува дека избираме некаква база на податоци, но следењето на PostgreSQL е прилично слабо застапено во него и секогаш треба да завршиме нешто. Земете неколку складишта од GitHub, клонирајте ги, приспособете ги скриптите, некако подесете ги. И на крајот испаѓа во некаква рачна работа.

Затоа, во овој извештај ќе се обидам да ви дадам одредено знаење за тоа како да изберете мониторинг не само за PostgreSQL, туку и за базата на податоци. И да го дадете знаењето што ќе ви овозможи да го завршите вашиот мониторинг за да извлечете некоја корист од тоа, за да можете да ја следите вашата база на податоци со корист за да спречите какви било претстојни итни ситуации што може да се појават навреме.

И оние идеи што ќе бидат во овој извештај, тие можат директно да се прилагодат на која било база на податоци, било да е тоа DBMS или noSQL. Затоа, не само PostgreSQL овде, туку ќе има многу рецепти за тоа како да го направите ова во PostgreSQL. Ќе има примери на прашања, примери на ентитети кои PostgreSQL ги има за следење. И ако вашиот DBMS ги има истите работи што ви дозволуваат да ги ставите во мониторинг, можете исто така да ги приспособите, да ги додадете и ќе биде во ред.

Нема да пријавам
зборувајте за тоа како да се испорача и складира метриката. Нема да кажам ништо за пост-обработка на податоците и нивно обезбедување на корисникот. И нема да кажам ништо за алармирање.
Но, во текот на приказната, ќе покажам различни слики од екранот на постоечките мониторинг, некако ќе ги критикувам. Сепак, ќе се обидам да не именувам брендови за да не создавам рекламирање или антирекламирање за овие производи. Затоа, сите коинциденции се случајни и остануваат на вашата имагинација.

Прво, да разбереме што е следење. Мониторингот е многу важна работа што треба да се има. Секој го разбира ова. Но, во исто време, следењето не е поврзано со деловен производ и не влијае директно на профитот на компанијата, така што на мониторингот секогаш му се дава време на преостаната основа. Ако имаме време, тогаш се занимаваме со мониторинг, ако нема време, тогаш во ред, ќе го ставиме во заостанатото и некогаш ќе се вратиме на овие задачи.

Затоа, од нашата практика, кога ќе дојдеме до клиенти, мониторингот е често недоволно развиен и нема интересни работи што би ни помогнале да ја завршиме подобрата работа со базата на податоци. И затоа следењето секогаш треба да се заврши.

Базите на податоци се толку сложени работи што исто така треба да ги следите, бидејќи базите на податоци се складиште на информации. И информациите се многу важни за компанијата, не можат да се изгубат на ниту еден начин. Но, во исто време, базите на податоци се многу сложени парчиња софтвер. Тие се составени од многу компоненти. И многу од овие компоненти треба да се следат.

Ако зборуваме конкретно за PostgreSQL, тогаш може да се претстави како таква шема, која се состои од голем број компоненти. Овие компоненти комуницираат едни со други. И во исто време, PostgreSQL го има таканаречениот потсистем за собирач на статистика, кој ви овозможува да собирате статистика за работата на овие потсистеми и да обезбедите интерфејс на администраторот или корисникот за да може да ги прегледа овие статистики.

Оваа статистика е претставена во форма на одреден сет на функции и погледи (поглед). Тие можат да се наречат и табели. Односно, користејќи обичен psql клиент, можете да се поврзете со базата на податоци, да ги изберете овие функции и прикази и да добиете одредени бројки за работата на потсистемите PostgreSQL.

Можете да ги додадете овие бројки во вашиот омилен систем за следење, да цртате графикони, да додавате функции и да добивате аналитика на долг рок.

Но, во овој извештај нема да ги опфатам сите овие функции без исклучок, бидејќи може да потрае цел ден. Ќе се осврнам буквално на две, три или четири работи и ќе ви кажам како тие помагаат да се подобри следењето.

И ако зборуваме за следење на базата на податоци, што треба да се следи? Пред сè, треба да ја следиме достапноста, бидејќи базата на податоци е услуга која обезбедува пристап до податоците на клиентите и треба да ја следиме достапноста, а исто така да обезбедиме некои нејзини квалитативни и квантитативни карактеристики.

Исто така, треба да ги следиме клиентите кои се поврзуваат со нашата база на податоци, бидејќи тие можат да бидат и нормални клиенти и штетни клиенти кои можат да и наштетат на базата на податоци. Тие исто така треба да се следат и следат.

Кога клиентите се поврзуваат со базата на податоци, очигледно е дека почнуваат да работат со нашите податоци, затоа треба да следиме како клиентите работат со податоците: со кои табели, во помала мера со кои индекси. Односно, треба да го оцениме обемот на работа што го создаваат нашите клиенти.

Но, обемот на работа, се разбира, се состои и од барања. Апликациите се поврзуваат со базата на податоци, пристапуваат до податоците користејќи прашања, па затоа е важно да се процени какви прашања имаме во базата на податоци, да се следи нивната адекватност, да не се искривени, дека некои опции треба да се препишат и направат за да работат побрзо и со подобри перформанси.

И бидејќи зборуваме за базата на податоци, базата на податоци е секогаш процеси во позадина. Процесите во заднина ги одржуваат перформансите на базата на податоци на добро ниво, така што тие бараат одредена количина ресурси за самите да работат. И во исто време, тие можат да се преклопуваат со ресурсите за барања на клиентот, така што алчната работа на заднинските процеси може директно да влијае на перформансите на барањата на клиентите. Затоа, тие исто така треба да се следат и следат за да нема нарушувања во однос на процесите во позадина.

И тоа е сè во однос на следењето на базата на податоци останува во системската метрика. Но, имајќи предвид дека во најголем дел целата наша инфраструктура оди во облаците, системската метрика на индивидуален домаќин секогаш бледнее во позадина. Но, во базите на податоци, тие сè уште се релевантни и, се разбира, исто така е неопходно да се следат системските метрики.

Со системската метрика, сè е повеќе или помалку во ред, сите модерни системи за следење веќе ги поддржуваат овие метрики, но генерално, некои компоненти сè уште не се доволни и некои работи треба да се додадат. И јас ќе ги допрам, неколку слајдови ќе бидат за нив.

Првата точка на планот е пристапноста. Што е пристапност? Достапноста според моето разбирање е способноста на базата да опслужува врски, односно базата е подигната, таа како услуга прифаќа врски од клиенти. И оваа пристапност може да се процени според некои карактеристики. Овие карактеристики се многу погодни за прикажување на контролните табли.

Секој знае што се контролни табли. Ова е моментот кога погледнавте на екранот, кој ги сумираше потребните информации. И веќе можете веднаш да одредите дали има проблем во базата или не.
Соодветно на тоа, достапноста на базата на податоци и другите клучни карактеристики секогаш треба да се стават на контролните табли, така што оваа информација е при рака, секогаш со вас. Некои дополнителни детали кои веќе помагаат во истрагата на инциденти, во истрагата на некои итни ситуации, тие веќе треба да се постават на секундарните контролни табли или да се сокријат во врските за пронаоѓање што водат до системи за следење од трета страна.

Пример за еден познат систем за следење. Ова е многу кул систем за следење. Собира многу податоци, но од моја гледна точка има чуден концепт на контролни табли. Има врска „Креирај контролна табла“. Но, кога креирате контролна табла, креирате листа со две колони, листа на графикони. И кога треба да погледнете нешто, почнувате да кликате, да лизгате, да ја барате саканата табела со глувчето. И за ова е потребно време, односно нема контролни табли како такви. Има само листи на графикони.

Што треба да се додаде на овие контролни табли? Можете да започнете со таква карактеристика како време на одговор. PostgreSQL го има погледот pg_stat_statements. Стандардно е оневозможено, но е еден од важните системски прикази што секогаш треба да се овозможат и користат. Ги зачувува информациите за сите прашања кои се извршуваат што биле извршени во базата на податоци.

Според тоа, можеме да тргнеме од фактот дека можеме да го земеме вкупното време на извршување на сите барања и да го поделиме со бројот на барања користејќи ги горенаведените полиња. Но, ова е толку просечна температура во болницата. Можеме да изградиме и други полиња - минималното време за извршување на барањето, максимумот и медијаната. И можеме дури и да изградиме перцентили, PostgreSQL ги има соодветните функции за ова. И можеме да добиеме некои бројки што го карактеризираат времето на одговор на нашата база на податоци за веќе пополнети барања, т.е. не го извршуваме лажното барање „избери 1“ и го гледаме времето на одговор, туку го анализираме времето на одговор за веќе пополнети барања и цртаме или посебна фигура, или врз основа на неа градиме график.

Исто така, важно е да се следи бројот на грешки што системот моментално ги создава. И за ова можете да го користите погледот pg_stat_database. Го насочуваме полето xact_rollback. Ова поле не само што го прикажува бројот на враќања што се случуваат во базата на податоци, туку го зема предвид и бројот на грешки. Релативно кажано, можеме да ја прикажеме оваа бројка на нашата контролна табла и да видиме колку грешки имаме во моментот. Ако има многу грешки, тогаш ова е веќе добра причина да ги погледнете дневниците и да видите какви грешки се тие и зошто се појавуваат, а потоа да инвестирате и да ги решите.

Можете да додадете такво нешто како тахометар. Тоа се бројот на трансакции во секунда и бројот на барања во секунда. Релативно кажано, можете да ги користите овие бројки како тековни перформанси на вашата база на податоци и да набљудувате дали има врвови во барањата, врвови во трансакциите или, обратно, базата на податоци е недоволно оптоварена затоа што некој вид на задниот дел паднал. Важно е секогаш да ја гледаме оваа бројка и да запомниме дека за нашиот проект таквата изведба е нормална, а вредностите горе и долу се веќе некакви проблематични и неразбирливи, што значи дека треба да погледнеме зошто таквите бројки .

За да го процениме бројот на трансакции, повторно можеме да се повикаме на приказот pg_stat_database. Можеме да го додадеме бројот на обврзувања и бројот на враќања за да го добиеме бројот на трансакции во секунда.

Секој разбира дека неколку барања можат да се вклопат во една трансакција? Затоа, TPS и QPS се малку различни.

Бројот на барања во секунда може да се добие од pg_stat_statements и едноставно да се пресмета збирот на сите извршени барања. Јасно е дека ја споредуваме сегашната вредност со претходната, одземаме, ја добиваме делтата, ја добиваме количината.

Доколку сакате, можете да додадете дополнителни метрики, кои исто така помагаат да се процени достапноста на нашата база на податоци и да се следи дали имало прекини.

Една од овие метрики е времето на работа. Но, времето на работа во PostgreSQL е малку незгодно. Ќе ти кажам зошто. Кога ќе се стартува PostgreSQL, тој започнува да известува за време на работа. Но, ако во одреден момент, на пример, некоја задача се извршуваше ноќе, дојде OOM-убиец и насилно го прекина процесот на дете на PostgreSQL, тогаш во овој случај PostgreSQL ја прекинува врската на сите клиенти, ја ресетира отсечената мемориска област и го започнува обновувањето од последниот контролен пункт. И додека трае ова закрепнување од контролната точка, базата на податоци не прифаќа врски, односно оваа ситуација може да се оцени како прекин. Но, ова нема да го ресетира бројачот за време на работа, бидејќи го зема предвид времето на стартување на поштарот од првиот момент. Затоа, таквите ситуации може да се прескокнат.

Исто така, треба да го следите бројот на работници со правосмукалка. Секој знае што е автовакуум во PostgreSQL? Ова е интересен потсистем во PostgreSQL. За тоа се напишани многу написи, направени се многу извештаи. Многу дискусии за вакуум, како треба да функционира. Многумина го сметаат за неопходно зло. Но, тоа е. Ова е некој вид собирач на ѓубре што ги чисти застарените верзии на редови кои не се потребни за ниту една трансакција и ослободува простор во табелите и индексите за нови редови.

Зошто треба да се следи? Затоа што вакуумот понекогаш многу боли. Тоа троши голема количина на ресурси и барањата на клиентите почнуваат да страдаат од ова.

И тоа треба да се следи преку приказот pg_stat_activity, за кој ќе зборувам во следниот дел. Овој приказ ја прикажува тековната активност во базата на податоци. И преку оваа активност, можеме да го следиме бројот на правосмукалки што работат во моментов. Можеме да ги следиме вакуумите и да видиме дека ако сме ја надминале границата, тогаш ова е повод да ги погледнеме поставките на PostgreSQL и некако да ја оптимизираме работата на вакуумот.

Друга карактеристика на PostgreSQL е дека PostgreSQL е многу болен од долги трансакции. Особено, од трансакции кои висат долго време и не прават ништо. Тоа се таканаречените stat idle-in-transaction. Таквата трансакција држи брави, го спречува вакуумот да работи. И како резултат - масите се издува, тие се зголемуваат во големина. И прашањата што работат со овие табели, тие почнуваат да работат побавно, затоа што треба да ги лопате сите стари верзии на редови од меморија до диск и назад. Затоа, треба да се следи и времето, времетраењето на најдолгите трансакции, најдолгите барања за вакуум. И ако видиме некои процеси кои се извршуваат многу долго време, повеќе од 10-20-30 минути за оптоварување OLTP, тогаш треба да обрнеме внимание на нив и да ги принудиме да завршат, или да ја оптимизираме апликацијата така што не се викаат и не висат толку долго. За аналитичко оптоварување, 10-20-30 минути е нормално, има и подолги.

Следно, имаме опција со поврзани клиенти. Кога веќе ќе формираме контролна табла, ќе објавиме клучни метрики за пристапност на неа, можеме да додадеме и дополнителни информации за поврзаните клиенти таму.

Информациите за поврзаните клиенти се важни бидејќи, од гледна точка на PostgreSQL, постојат различни типови на клиенти. Има добри клиенти и има лоши клиенти.

Едноставен пример. Под клиент, мислам на апликацијата. Апликацијата се поврза со базата на податоци и веднаш почнува да ги испраќа своите барања таму, базата ги обработува и ги извршува, а резултатите ги враќа на клиентот. Овие се добри и правилни клиенти.

Има ситуации кога клиентот е поврзан, ја одржува врската, но не прави ништо. Тоа е во неактивен состојба.

Но, има лоши клиенти. На пример, истиот клиент се поврза, отвори трансакција, направи нешто во базата на податоци, а потоа влезе во кодот, на пример, за да пристапи до надворешен извор или да ги обработи примените податоци таму. Но, во исто време, тој не ја затвори трансакцијата. И трансакцијата виси во базата на податоци и ја држи бравата на линијата. Ова е лоша состојба. И ако одеднаш апликацијата некаде во неа падне со исклучок (Исклучок), тогаш трансакцијата може да остане отворена многу долго време. И ова директно влијае на перформансите на PostgreSQL. PostgreSQL ќе работи побавно. Затоа, важно е навреме да се следат таквите клиенти и насилно да се прекине нивната работа. И треба да ја оптимизирате вашата апликација за да нема такви ситуации.

Други лоши клиенти чекаат клиенти. Но, тие стануваат лоши поради околностите. На пример, едноставна трансакција во мирување: може да отвори трансакција, да преземе брави на некои линии, а потоа ќе падне некаде во кодот, оставајќи виси трансакција. Ќе дојде друг клиент, ќе ги побара истите податоци, но ќе наиде на заклучување, бидејќи таа висечка трансакција веќе држи брави на некои неопходни редови. И втората трансакција ќе виси во исчекување кога првата трансакција ќе биде завршена или нејзиниот администратор насилно ќе ја затвори. Така, трансакциите што чекаат може да се акумулираат и да го преполнат лимитот за поврзување со базата на податоци. И кога границата е полна, апликацијата повеќе не може да работи со базата на податоци. Ова е веќе вонредна ситуација за проектот. Затоа, лошите клиенти треба да се следат и да се реагира навремено.

Друг пример за следење. И тука е пристојна контролна табла. Има информации за врски одозгора. DB врска - 8 парчиња. И тоа е се. Немаме информации кои клиенти се активни, кои клиенти се само неактивен, не прават ништо. Нема информации за висечки трансакции и нерешени врски, т.е. ова е таква бројка што го покажува бројот на врски и тоа е тоа. А потоа погодете сами.

Соодветно, за да ги додадете овие информации во мониторингот, треба да се повикате на системскиот приказ на pg_stat_activity. Ако поминувате многу време во PostgreSQL, тогаш ова е многу добар поглед кој треба да ви стане пријател, бидејќи ја прикажува моменталната активност во PostgreSQL, односно што се случува во него. За секој процес има посебна линија која прикажува информации за овој процес: од кој хост е направена врската, под кој корисник, под кое име, кога е започната трансакцијата, кое барање моментално се извршува, кое барање е извршено последно. И, соодветно, можеме да ја оцениме состојбата на клиентот според полето stat. Релативно кажано, можеме да групираме според ова поле и да ги добиеме оние статистики што се сега во базата на податоци и бројот на врски што се со оваа статистика во базата на податоци. А веќе добиените броеви можеме да ги испратиме на нашиот мониторинг и да цртаме графикони на нив.
Исто така е важно да се оцени времетраењето на трансакцијата. Веќе реков дека е важно да се процени времетраењето на вакуумите, но трансакциите исто така се оценуваат на ист начин. Постојат полиња xact_start и query_start. Тие, релативно кажано, го покажуваат времето на започнување на трансакцијата и времето на започнување на барањето. Ја земаме функцијата now() која го прикажува тековниот временски печат и ја одземаме трансакцијата и бараме временски ознаки. И го добиваме времетраењето на трансакцијата, времетраењето на барањето.

Ако видиме долги трансакции, веќе треба да ги завршиме. За оптоварување OLTP, долгите трансакции се веќе повеќе од 1-2-3 минути. За оптоварување OLAP, долгите трансакции се нормални, но ако тие работат повеќе од два часа, тогаш ова е исто така знак дека некаде имаме искривување.

Откако клиентите ќе се поврзат со базата на податоци, тие почнуваат да работат со нашите податоци. Тие пристапуваат до табели, пристапуваат до индекси за да добијат податоци од табела. И важно е да се оцени како клиентите работат со овие податоци.

Ова е неопходно за да се оцени нашиот обем на работа и грубо да се разбере кои табели ги имаме „најжешките“. На пример, ова е неопходно во ситуации кога сакаме да поставиме „жешки“ маси на некој вид брзо складирање на SSD. На пример, некои архивски табели што не сме ги користеле долго време, може да се пренесат во некаква „ладна“ архива, на SATA дискови и да ги оставиме да живеат таму, ќе им се пристапи по потреба.

Исто така е корисен за откривање аномалии по какви било објавувања и распоредувања. Да речеме дека проектот испорача некоја нова функција. На пример, додадовме нова функционалност за работа со базата на податоци. И ако изградиме графикони за употреба на табели, лесно можеме да ги откриеме овие аномалии на овие графикони. На пример, ажурирајте рафали или бришете рафали. Тоа ќе биде многу видливо.

Исто така е можно да се детектираат аномалии на „пловечка“ статистика. Што значи тоа? PostgreSQL има многу силен и многу добар планер за прашања. И програмерите посветуваат многу време на неговиот развој. Како работи тој? Со цел да се изградат добри планови, PostgreSQL собира статистика за дистрибуцијата на податоците во табели со одреден временски интервал, со одредена периодичност. Ова се најчестите вредности: број на единствени вредности, информации за NULL во табелата, многу информации.

Врз основа на овие статистики, планерот гради неколку барања, го избира најоптималниот и го користи овој план за пребарување за да го изврши самото барање и да врати податоци.

И се случува статистиката да „плови“. Податоците за квалитетот и квантитетот некако се променија во табелата, но статистиката не беше прибирана. И формираните планови можеби не се оптимални. И доколку нашите планови се покажат неоптимални во однос на прибирањето на мониторингот, според табелите ќе можеме да ги видиме овие аномалии. На пример, некаде податоците се сменија квалитативно и наместо индексот, почна да се користи секвенцијално поминување низ табелата, т.е. ако барањето треба да врати само 100 редови (има ограничување од 100), тогаш ќе се изврши целосно набројување за ова барање. И ова секогаш има многу лош ефект врз перформансите.

И тоа можеме да го видиме во мониторингот. И веќе погледнете го ова барање, објаснете за него, собирајте статистика, изградете нов дополнителен индекс. И веќе одговори на овој проблем. Затоа е важно.

Друг пример за следење. Мислам дека многу луѓе го препознаваат затоа што е многу популарен. Кој користи во своите проекти Прометеј? И кој го користи овој производ заедно со Прометеј? Факт е дека во стандардното складиште на овој мониторинг има контролна табла за работа со PostgreSQL - postgres_exporter Прометеј. Но, тука има еден лош детал.

Постојат неколку графикони. И бајтите се наведени како единство, односно има 5 графикони. Тоа се Внеси податоци, Ажурирај податоци, Избриши податоци, Земи податоци и Врати податоци. Бајтите се наведени како единечна димензија. Но, факт е дека статистиката во PostgreSQL ги враќа податоците во торки (редови). И, соодветно, овие графикони се многу добар начин да го потцените вашиот обем на работа неколку пати, десетици пати, бидејќи торката не е бајт, торката е низа, има многу бајти и секогаш е со променлива должина. Односно, пресметувањето на обемот на работа во бајти со помош на торки е нереална или многу тешка задача. Затоа, кога користите контролна табла или вграден мониторинг, секогаш е важно да разберете дека работи правилно и ви ги враќа правилно проценетите податоци.

Како да добиете статистика на овие табели? За да го направите ова, PostgreSQL има семејство на погледи. А главниот поглед е pg_stat_user_tables. User_tables - тоа значи дека табелите се креирани во име на корисникот. Спротивно на тоа, постојат системски прегледи, кои се користат од самиот PostgreSQL. И постои резиме табела Alltables, која вклучува и систем и корисник. Можете да почнете од кој било од нив што најмногу ви се допаѓа.

Горенаведените полиња може да се користат за да се процени бројот на вметнувања, ажурирања и бришења. Примерната контролна табла што ја користев ги користи овие полиња за да ги процени карактеристиките на обемот на работа. Затоа, и ние можеме да се надоврзуваме на нив. Но, вреди да се запамети дека ова се торки, а не бајти, така што не можеме да го земеме и да го направиме бајти.

Врз основа на овие податоци, можеме да ги изградиме таканаречените TopN-табели. На пример, Топ-5, Топ-10. И можете да ги следите оние жешки маси што се користат повеќе од другите. На пример, 5 „жешки“ маси за вметнување. И според овие TopN-табели, го проценуваме нашиот обем на работа и можеме да ги процениме рафалите на обемот на работа по какви било изданија и ажурирања и распоредувања.

Исто така, важно е да се процени големината на табелата, бидејќи понекогаш програмерите пуштаат нова функција, а нашите табели почнуваат да се зголемуваат во нивните големи димензии, бидејќи тие одлучија да додадат дополнителна количина на податоци, но не предвидеа како ќе влијае на големината на базата на податоци. Ваквите случаи и нас нè изненадуваат.

И сега едно мало прашање за вас. Кое е прашањето кога ќе забележите оптоварување на серверот на базата на податоци? Кое е вашето следно прашање?

Но, вистинското прашање е следново. Какви барања предизвикува товарот? Односно, не е интересно да се гледаат процесите што ги предизвикува оптоварувањето. Јасно е дека ако домаќинот е со база на податоци, тогаш базата работи таму и јасно е дека само базите на податоци ќе бидат отстранети таму. Ако го отвориме Top, ќе видиме таму список на процеси на PostgreSQL што прават нешто. Од Топ нема да биде јасно што прават.

Соодветно на тоа, треба да ги пронајдете оние барања што предизвикуваат најмногу оптоварување, бидејќи подесувањето на барањето, по правило, дава поголем профит од конфигурацијата на PostgreSQL или подесувањето на оперативниот систем, па дури и подесувањето на хардверот. Според мојата проценка, ова е околу 80-85-90%. И ова се прави многу побрзо. Побрзо е да се поправи барањето отколку да се коригира конфигурацијата, да се закаже рестартирање, особено ако базата на податоци не може да се рестартира или да се додаде хардвер. Полесно е да го преработите барањето некаде или да додадете индекс за да добиете подобар резултат од ова барање.

Соодветно на тоа, неопходно е да се следат барањата и нивната адекватност. Да земеме уште еден пример за следење. И тука, исто така, се чини дека е одличен мониторинг. Има информации за репликација, има информации за пропусната моќ, блокирањето, искористувањето на ресурсите. Се е во ред, но нема информации за барањата. Не е јасно кои прашања се извршуваат во нашата база на податоци, колку долго се извршуваат, колку од овие прашања. Треба секогаш да ги имаме овие информации во мониторингот.

И за да ги добиеме овие информации, можеме да го користиме модулот pg_stat_statements. Врз основа на тоа, можете да изградите различни графики. На пример, можете да добиете информации за најчестите барања, односно за оние барања што се извршуваат најчесто. Да, по распоредувањето, исто така е многу корисно да се погледне и да се разбере дали има некаков пораст на барањата.

Можете да ги следите најдолгите барања, односно оние барања за кои е потребно најдолго да се завршат. Работат на процесорот, трошат I/O. Ова може да го оцениме и со полињата total_time, mean_time, blk_write_time и blk_read_time.

Можеме да ги оцениме и следиме најтешките барања во однос на искористеноста на ресурсите, оние што читаат од дискот, оние што работат со меморија или, напротив, создаваат некаков вид оптоварување за запишување.

Можеме да ги оцениме најдарежливите барања. Ова се прашања кои враќаат голем број редови. На пример, тоа може да биде некој вид барање каде што заборавиле да постават ограничување. И само ја враќа целата содржина на табелата или барањето на бараните табели.

Исто така, можете да ги следите барањата што користат привремени датотеки или привремени табели.

И ние сè уште имаме процеси во позадина. Позадинските процеси се првенствено контролни точки или се нарекуваат и контролни точки, тоа се автовакуум и репликација.

Друг пример за следење. Има табот Одржување лево, одете до него и надевајте се дека ќе видите нешто корисно. Но, тука, само времето на вакум и собирање статистики, ништо друго. Ова е многу слаба информација, така што секогаш треба да имате информации за тоа како функционираат заднинските процеси во нашата база на податоци и дали има некакви проблеми од нивната работа.

Кога ги гледаме контролните пунктови, треба да се запомни дека нашите контролни пунктови ги мијат „валканите“ страници од делот за распарчена меморија до дискот, а потоа создаваат контролен пункт. И овој контролен пункт веќе може да се користи како место за време на закрепнувањето, ако PostgreSQL одеднаш беше прекинат во итен случај.

Според тоа, за да ги исфрлите сите „валкани“ страници на дискот, треба да направите одредена количина на пишување. И, како по правило, на системи со голема количина на меморија, ова е многу. И ако правиме контролни точки многу често во некој краток интервал, тогаш перформансите на дискот многу ќе попуштаат. И барањата на клиентите ќе страдаат од недостаток на ресурси. Тие ќе се натпреваруваат за ресурси и немаат продуктивност.

Според тоа, преку pg_stat_bgwriter на наведените полиња, можеме да го следиме бројот на контролни точки што се појавуваат. И ако имаме многу контролни пунктови за одреден временски период (за 10-15-20 минути, за половина час), на пример, 3-4-5, тогаш ова веќе може да биде проблем. И веќе треба да погледнете во базата на податоци, да погледнете во конфигурацијата, што предизвикува такво изобилство на контролни точки. Можеби доаѓа некој голем рекорд. Веќе можеме да го оцениме обемот на работа, бидејќи веќе додадовме графикони за обемот на работа. Веќе можеме да ги измениме параметрите на точката на прекин и да се погрижиме тие да не влијаат многу на перформансите на барањето.

Повторно се враќам на автовакуум бидејќи тоа е нешто, како што реков, што лесно може да ги додаде и перформансите на дискот и барањата, така што секогаш е важно да се измери количината на автовакуум.

Бројот на работници во автовакуум во базата на податоци е ограничен. Стандардно, има три од нив, па ако имаме тројца работници кои постојано работат во базата на податоци, тогаш тоа значи дека нашиот автовакуум е недоволно конфигуриран, треба да ги подигнеме границите, да ги ревидираме поставките за автовакуум и веќе да се качиме во конфигурацијата.
Важно е да се процени кои вакуумски работници работат за нас. Или беше лансиран од корисникот, DBA влезе и лансираше некој вид вакуум со рацете, и тоа создаде оптоварување. Имаме некој проблем. Или ова е бројот на правосмукалки што го одвртуваат бројачот на трансакции. За некои верзии на PostgreSQL, ова се многу тешки вакууми. И тие лесно можат да додадат перформанси затоа што ја одземаат целата табела, ги скенираат сите блокови во оваа табела.

И, се разбира, времетраењето на вакуумите. Ако имаме долги правосмукалки кои работат многу долго, тогаш тоа значи дека повторно треба да обрнеме внимание на конфигурацијата на вакуумот и можеби да ги преиспитаме неговите поставки. Бидејќи може да се појави ситуација кога вакуумот работи на масата долго време (3-4 часа), но за време на работата на вакуумот, голема количина мртви редови повторно успеаја да се акумулираат во табелата. И штом ќе заврши вакуумот, тој треба повторно да ја исчисти оваа маса. И доаѓаме до ситуација - бесконечен вакуум. И во овој случај, вакуумот не се справува со својата работа, а табелите почнуваат постепено да отекуваат во големина, иако количината на корисни податоци во него останува иста. Затоа, во долги вакууми, секогаш ја гледаме конфигурацијата и се обидуваме да ја оптимизираме, но во исто време, за да не страдаат перформансите на барањата на клиентите.

Сега практично нема инсталација PostgreSQL каде што немаше репликација на стриминг. Репликацијата е процес на пренос на податоци од главен во реплика.

Репликацијата во PostgreSQL се организира преку дневник за трансакции. Господарот генерира дневник за трансакции. Дневникот на трансакции на мрежната врска оди до репликата, а потоа се репродуцира на репликата. Сè е едноставно.

Според тоа, приказот pg_stat_replication се користи за следење на доцнењето на репликацијата. Но, не и е лесно. Во верзијата 10, погледот претрпе неколку промени. Прво, некои од полињата се преименувани. А некои од полињата се додадени. Во 10-тата верзија се појавија полиња кои ви овозможуваат да го оцените заостанувањето на репликацијата во секунди. Тоа е многу удобно. Пред верзијата 10, беше можно да се процени доцнењето на репликацијата во бајти. Оваа функција остана во 10-та верзија, односно можете да изберете што е поудобно за вас - проценете го заостанувањето во бајти или проценете го задоцнувањето во секунди. Многумина ги прават и двете.

Меѓутоа, за да го оцените доцнењето на репликацијата, треба да ја знаете позицијата на дневникот во трансакцијата. И овие позиции на дневникот на трансакции се само во приказот pg_stat_replication. Релативно кажано, можеме да ја користиме функцијата pg_xlog_location_diff() за да земеме две точки во дневникот на трансакциите. Пресметајте ја делтата помеѓу нив и добијте го заостанувањето на репликацијата во бајти. Тоа е многу погодно и едноставно.

Во верзијата 10 оваа функција беше преименувана во pg_wal_lsn_diff(). Генерално, во сите функции, прегледи, комунални услуги, каде што се сретнуваше зборот „xlog“, тој беше заменет со вредноста „wal“. Ова е и во погледи и во функции. Ова е таква иновација.

Плус, во 10-тата верзија беа додадени линии кои конкретно го покажуваат заостанувањето. Тоа се задоцнување за пишување, задоцнување на флеш, задоцнување за репродукција. Односно, важно е да се следат овие работи. Ако видиме дека имаме задоцнување на репликацијата, тогаш треба да истражиме зошто се појавило, од каде дошло и да го решиме проблемот.

Со системската метрика, речиси сè е во ред. Кога ќе се роди секое следење, тој започнува со системска метрика. Ова е користење на процесори, меморија, swap, мрежа и диск. Но, сепак, многу параметри не се таму стандардно.

Ако сè е во ред со отстранувањето на процесот, тогаш има проблеми со отстранувањето на дискот. Како по правило, програмерите за следење додаваат информации за пропусниот опсег. Може да биде во iops или бајти. Но, тие забораваат на латентноста и користењето на уредот на дискот. Ова се поважни параметри кои ни овозможуваат да процениме колку се вчитани нашите дискови и колку забавуваат. Ако имаме висока латентност, тогаш тоа значи дека има некои проблеми со дисковите. Ако имаме голема искористеност, тогаш тоа значи дека дисковите не можат да се справат. Ова се повеќе квалитативни карактеристики отколку пропусниот опсег.

Сепак, овие статистики може да се добијат и од датотечен систем /proc, како што се прави за рециклирање на процесорот. Зошто оваа информација не се додава на мониторингот, не знам. Но, сепак е важно да го имате во вашето следење.

Истото важи и за мрежните интерфејси. Има информации за пропусниот опсег на мрежата во пакети, во бајти, но сепак нема информации за латентност и информации за користење, иако ова е исто така корисна информација.

Секој мониторинг има свои недостатоци. И без разлика каков вид на мониторинг ќе преземете, тој секогаш нема да исполни одредени критериуми. Но, сепак, тие се развиваат, се додаваат нови функции, нови работи, па изберете нешто и завршете го.

А за да завршите, мора секогаш да имате идеја што значи дадената статистика и како можете да ги решите проблемите со неа.

И неколку клучни точки:

• Секогаш треба да ја следите достапноста, да имате контролни табли за да можете брзо да процените дека сè е во ред со основата.
• Секогаш треба да имате идеја за тоа што клиентите работат со вашата база на податоци за да ги отстраните лошите клиенти и да ги застрелате.
• Важно е да се оцени како овие клиенти работат со податоците. Треба да имате идеја за обемот на работа.
• Важно е да се оцени како се формира овој обем на работа, со помош на кои прашања. Можете да оценувате прашања, можете да ги оптимизирате, да ги рефакторирате, да изградите индекси за нив. Тоа е многу важно.
• Процесите во заднина може негативно да влијаат на барањата на клиентите, па затоа е важно да бидете сигурни дека тие не користат премногу ресурси.
• Системските метрики ви дозволуваат да правите планови за скалирање, за зголемување на капацитетот на вашите сервери, па затоа е важно и нив да ги следите и оцените.

Доколку ве интересира оваа тема, тогаш можете да ги следите овие линкови.
http://bit.do/stats_collector е официјалната документација од собирачот на статистика. Има опис на сите статистички прикази и опис на сите полиња. Можете да ги прочитате, разберете и анализирате. И врз основа на нив, изградете ваши сопствени графикони, додајте го вашето следење.

Побарајте примери:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Ова е наше корпоративно складиште и мое. Имаат примероци на барања. Нема прашања од избраните* од сериите, нешто таму. Веќе има готови барања со приклучоци, користејќи интересни функции кои ви овозможуваат да направите читливи, удобни вредности од необработени броеви, односно тоа се бајти, време. Можете да ги изберете, да ги гледате, да ги анализирате, да ги додадете во вашите мониторинг, да изградите свои мониторинг врз основа на нив.

прашања

Прашање: Рековте дека нема да рекламирате брендови, но сè уште се прашувам - какви контролни табли користите во вашите проекти?
Одговор: На различни начини. Се случува да дојдеме кај клиентот и тој веќе има свој мониторинг. И ние го советуваме клиентот што треба да се додаде во неговиот мониторинг. Најлоша е ситуацијата со Забикс. Затоа што нема можност да изгради TopN-графика. Ние самите користиме Окметарзатоа што ги консултиравме овие момци за следење. Тие направија следење на PostgreSQL врз основа на нашиот TOR. Пишувам свој проект за милениче, кој собира податоци преку Прометеј и ги црпи Графана. Моја задача е да направам свој извозник во Прометеј и потоа да нацртам сè во Графана.

Прашање: Дали има аналози на извештаите за AWR или ... агрегации? Дали сте свесни за вакво нешто?
Одговор: Да, знам што е AWR, тоа е одлична работа. Во моментов, постојат различни велосипеди кои го имплементираат приближно следниот модел. Во одреден временски интервал, некои основни линии се запишуваат на истиот PostgreSQL или на посебно складирање. Можете да ги гуглате на Интернет, тие се. Еден од развивачите на такво нешто седи на форумот sql.ru во темата PostgreSQL. Можете да го фатите таму. Да, има такви работи, може да се користат. плус во него pgCenter Пишувам и нешто што ти дозволува да го сториш истото.

PS1 Ако користите postgres_exporter, каква контролна табла користите? Има неколку од нив. Тие се веќе застарени. Дали заедницата може да создаде ажуриран образец?

PS2 Отстранет е pganalyze бидејќи е комерцијална понуда на SaaS која се фокусира на следење на перформансите и автоматизирани предлози за подесување.

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Што мислите, кој мониторинг на postgresql кој е поставен самостојно (со контролна табла) е најдобар?

• 30,0%Zabbix + додатоци од Алексеј Лесовски или zabbix 4.4 или libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze е комерцијален SaaS - не може да се избрише1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

Гласаа 10 корисници. 26 корисници беа воздржани.

Извор: www.habr.com