Основи на наблюдението на PostgreSQL. Алексей Лесовски

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

В този доклад Алексей Лесовски ще говори за ключовите точки на postgres статистиките, какво означават те и защо трябва да бъдат включени в мониторинга; за това какви диаграми трябва да има в мониторинга, как да ги добавите и как да интерпретирате. Докладът ще бъде полезен за администратори на бази данни, системни администратори и разработчици, които се интересуват от отстраняване на неизправности в Postgres.

Казвам се Алексей Лесовски, представлявам Data Egret.

Няколко думи за себе си. Започнах отдавна като системен администратор.

Администрирах различни видове Linux, правех различни неща, свързани с Linux, т.е. виртуализация, мониторинг, работех с проксита и т.н. Но в един момент започнах да се занимавам повече с бази данни, PostgreSQL. Много го харесах. И в един момент започнах да се занимавам с PostgreSQL по-голямата част от работното си време. И така постепенно станах PostgreSQL DBA.

И през цялата си кариера винаги съм се интересувал от темите за статистика, мониторинг, телеметрия. И когато бях системен администратор, работих много усилено върху Zabbix. И написа малък набор от скриптове като zabbix-разширения. Той беше доста популярен по своето време. И там беше възможно да се наблюдават много различни важни неща, не само Linux, но и различни компоненти.

Сега вече правя PostgreSQL. Вече пиша друго нещо, което ви позволява да работите със статистики на PostgreSQL. Нарича се pgCenter (статия на Хабре - Postgres stat без нерви и напрежение).

Малко въведение. Какви са ситуациите с нашите клиенти, с нашите клиенти? Има някакъв инцидент, свързан с базата данни. И когато базата данни вече е възстановена, идва началникът на отдела или ръководителят на разработката и казва: „Приятели, трябва да наблюдаваме базата данни, защото се случи нещо лошо и е необходимо това да не се случва в бъдеще.“ И тук започва интересният процес на избор на система за наблюдение или адаптиране на съществуваща система за наблюдение, така че да можете да наблюдавате вашата база данни - PostgreSQL, MySQL или някои други. И колегите започват да предлагат: „Чух, че има такава и такава база данни. Нека го използваме." Колегите започват да се карат помежду си. И в крайна сметка се оказва, че избираме някаква база данни, но мониторингът на PostgreSQL е доста слабо представен в нея и винаги трябва да довършим нещо. Вземете някои хранилища от GitHub, клонирайте ги, адаптирайте скриптове, по някакъв начин ги настройте. И накрая изпада в някаква ръчна работа.

Затова в този доклад ще се опитам да ви дам малко знания за това как да изберете мониторинг не само за PostgreSQL, но и за базата данни. И да даде знанията, които ще ви позволят да завършите наблюдението си, за да извлечете някаква полза от него, така че да можете да наблюдавате вашата база данни с полза, за да предотвратите всякакви предстоящи извънредни ситуации, които могат да възникнат навреме.

И тези идеи, които ще бъдат в този отчет, те могат да бъдат директно адаптирани към всяка база данни, било то СУБД или noSQL. Следователно не само PostgreSQL тук, но ще има много рецепти как да направите това в PostgreSQL. Ще има примери за заявки, примери за обекти, които PostgreSQL има за наблюдение. И ако вашата СУБД има същите неща, които ви позволяват да ги поставите в мониторинг, можете също да ги адаптирате, да ги добавите и всичко ще бъде наред.

няма да докладвам
говорим за това как да доставяме и съхраняваме показатели. Няма да кажа нищо за последващата обработка на данни и предоставянето им на потребителя. А за алармирането няма да кажа нищо.
Но в хода на историята ще покажа различни екранни снимки на съществуващи мониторинги, по някакъв начин ще ги критикувам. Въпреки това ще се опитам да не назовавам марки, за да не създавам реклама или антиреклама на тези продукти. Следователно всички съвпадения са случайни и остават във вашето въображение.

Първо, нека разберем какво е мониторинг. Мониторингът е много важно нещо. Всеки разбира това. Но в същото време наблюдението не е свързано с бизнес продукт и не засяга пряко печалбите на компанията, така че наблюдението винаги се дава на остатъчна основа. Ако имаме време, тогава се занимаваме с мониторинг, ако няма време, тогава ОК, ще го поставим в изоставането и някой ден ще се върнем към тези задачи.

Затова от нашата практика, когато идваме при клиенти, мониторингът често е недоразвит и няма интересни неща, които биха ни помогнали да работим по-добре с базата данни. И следователно мониторингът винаги трябва да бъде завършен.

Базите данни са толкова сложни неща, които също трябва да наблюдавате, защото базите данни са хранилище на информация. А информацията е много важна за компанията, не може да се загуби по никакъв начин. Но в същото време базите данни са много сложни софтуерни части. Те са съставени от много компоненти. И много от тези компоненти трябва да бъдат наблюдавани.

Ако говорим конкретно за PostgreSQL, тогава той може да бъде представен като такава схема, която се състои от голям брой компоненти. Тези компоненти взаимодействат помежду си. И в същото време PostgreSQL има така наречената подсистема Stats Collector, която ви позволява да събирате статистика за работата на тези подсистеми и да предоставяте интерфейс на администратора или потребителя, така че той да може да преглежда тези статистики.

Тази статистика се представя под формата на набор от функции и изгледи (изглед). Могат да се нарекат и маси. Тоест, като използвате обикновен 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 прекратява връзката на всички клиенти, нулира областта на шардираната памет и започва възстановяване от последната контролна точка. И докато трае това възстановяване от контролната точка, базата данни не приема връзки, тоест тази ситуация може да се оцени като престой. Но това няма да нулира брояча на времето за работа, тъй като той взема предвид времето, в което postmaster е стартиран от първия момент. Следователно подобни ситуации могат да бъдат пропуснати.

Трябва също така да наблюдавате броя на работещите с прахосмукачки. Всеки знае какво е автовакуум в PostgreSQL? Това е интересна подсистема в PostgreSQL. За това са написани много статии, направени са много доклади. Много дискусии за вакуума, как трябва да работи. Мнозина го смятат за необходимо зло. Но е. Това е някакъв вид събирач на боклук, който почиства остарели версии на редове, които не са необходими на никоя от транзакциите, и освобождава място в таблиците и индексите за нови редове.

Защо трябва да се наблюдава? Защото вакуумът понякога много боли. Консумира голямо количество ресурси и клиентските заявки започват да страдат от това.

И трябва да се наблюдава чрез изгледа pg_stat_activity, за който ще говоря в следващия раздел. Този изглед показва текущата дейност в базата данни. И чрез тази дейност можем да проследим броя на вакуумите, които работят в момента. Можем да наблюдаваме вакуумите и да видим, че ако сме превишили лимита, това е повод да погледнем в настройките на PostgreSQL и по някакъв начин да оптимизираме работата на вакуума.

Друга особеност на PostgreSQL е, че PostgreSQL е много болен от дълги транзакции. Особено от транзакции, които висят дълго време и не правят нищо. Това са така наречените stat idle-in-transaction. Такава транзакция държи ключалки, предотвратява работата на вакуума. И в резултат - масите се издуват, увеличават се. И заявките, които работят с тези таблици, започват да работят по-бавно, защото трябва да прехвърлите всички стари версии на редове от паметта на диска и обратно. Следователно времето, продължителността на най-дългите транзакции, най-дългите заявки за вакуум също трябва да бъдат наблюдавани. И ако видим някои процеси, които се изпълняват много дълго време, повече от 10-20-30 минути за OLTP натоварване, тогава трябва да им обърнем внимание и да ги принудим да приключат или да оптимизираме приложението, така че те не се наричат ​​и не висят толкова дълго. За аналитично натоварване е нормално 10-20-30 минути, има и по-дълги.

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

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

Прост пример. Под клиент имам предвид приложението. Приложението се е свързало с базата данни и веднага започва да изпраща своите заявки там, базата данни ги обработва и изпълнява и връща резултатите на клиента. Това са добри и коректни клиенти.

Има ситуации, при които клиентът е свързан, поддържа връзката, но не прави нищо. В неактивно състояние е.

Но има лоши клиенти. Например същият клиент се свърза, отвори транзакция, направи нещо в базата данни и след това влезе в кода, например за достъп до външен източник или за обработка на получените данни там. Но в същото време той не затвори сделката. И транзакцията виси в базата данни и държи ключалката на линията. Това е лошо състояние. И ако внезапно приложението някъде вътре в него попадне по изключение (Exception), тогава транзакцията може да остане отворена за много дълго време. И това пряко влияе върху производителността на 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), тогава ще бъде извършено пълно изброяване за тази заявка. А това винаги се отразява много зле на представянето.

И можем да го видим в мониторинга. И вече погледнете тази заявка, изпълнете обяснение за нея, съберете статистика, изградете нов допълнителен индекс. И вече отговори на този проблем. Затова е важно.

Друг пример за наблюдение. Мисля, че много хора го разпознават, защото е много популярен. Кой използва в своите проекти Прометей? И кой използва този продукт заедно с Prometheus? Факт е, че в стандартното хранилище на този мониторинг има табло за работа с 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-та версия бяха добавени редове, които конкретно показват забавянето. Това са забавяне при запис, забавяне на промиване, забавяне при повторно възпроизвеждане. Тоест, важно е да се следят тези неща. Ако видим, че имаме забавяне на репликацията, тогава трябва да проучим защо се е появило, откъде идва и да отстраним проблема.

Със системните показатели почти всичко е наред. Когато се ражда някакъв мониторинг, той започва със системни показатели. Това е използването на процесори, памет, суап, мрежа и диск. Но въпреки това много параметри не са там по подразбиране.

Ако всичко е наред с изхвърлянето на процеса, тогава има проблеми с изхвърлянето на диска. Като правило разработчиците на мониторинг добавят информация за честотната лента. Може да бъде в iops или байтове. Но те забравят за латентността и използването на дисковите устройства. Това са по-важни параметри, които ни позволяват да оценим колко са натоварени нашите дискове и колко забавят. Ако имаме висока латентност, това означава, че има проблеми с дисковете. Ако имаме високо натоварване, това означава, че дисковете не могат да се справят. Това са повече качествени характеристики, отколкото честотната лента.

Тези статистики обаче могат да бъдат получени и от файловата система /proc, както се прави за рециклирането на процесора. Защо тази информация не се добавя към мониторинга, не знам. Но все пак е важно да го имате във вашето наблюдение.

Същото важи и за мрежовите интерфейси. Има информация за честотната лента на мрежата в пакети, в байтове, но въпреки това няма информация за латентност и няма информация за използване, въпреки че това също е полезна информация.

Всеки мониторинг има своите недостатъци. И какъвто и вид мониторинг да предприемете, той винаги няма да отговаря на определени критерии. Но въпреки това те се развиват, добавят се нови функции, нови неща, така че изберете нещо и го довършете.

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

И няколко ключови момента:

• Винаги трябва да следите наличността, да имате табла, за да можете бързо да прецените дали всичко е наред с базата.
• Винаги трябва да имате представа какви клиенти работят с вашата база данни, за да отсеете лошите клиенти и да ги застреляте.
• Важно е да се оцени как тези клиенти работят с данни. Трябва да имате представа за натовареността си.
• Важно е да се прецени как се формира това натоварване, с помощта на какви заявки. Можете да оценявате заявки, можете да ги оптимизирате, преработвате, изграждате индекси за тях. Много е важно.
• Фоновите процеси могат да повлияят отрицателно на клиентските заявки, така че е важно да се уверите, че те не използват твърде много ресурси.
• Системните показатели ви позволяват да правите планове за мащабиране, за увеличаване на капацитета на вашите сървъри, така че е важно да ги проследявате и оценявате също.

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

Примери за заявка:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Това е нашето корпоративно хранилище и моето собствено. Имат примерни заявки. Няма запитвания от селект* от серия, нещо там. Вече има готови заявки с обединения, използвайки интересни функции, които ви позволяват да правите четливи, удобни стойности от необработени числа, тоест това са байтове, време. Можете да ги избирате, гледате, анализирате, добавяте към вашите наблюдения, създавате свои собствени наблюдения въз основа на тях.

Въпроси

Въпрос: Казахте, че няма да рекламирате марки, но все още се чудя - какви табла за управление използвате в проектите си?
Отговор: По различни начини. Случва се да дойдем при клиента и той вече има собствен мониторинг. И съветваме клиента какво трябва да добави към неговия мониторинг. Най-лошото е положението със Zabbix. Тъй като няма възможност за изграждане на TopN-графика. Ние самите използваме Okmeterзащото се консултирахме с тези момчета относно мониторинга. Те направиха мониторинг на PostgreSQL въз основа на нашето TOR. Пиша собствен проект за домашни любимци, който събира данни чрез Prometheus и ги въвежда Графана. Моята задача е да направя собствен експортер в Prometheus и след това да нарисувам всичко в Grafana.

Въпрос: Има ли аналози на AWR отчети или ... агрегации? Знаете ли за нещо подобно?
Отговор: Да, знам какво е AWR, това е страхотно нещо. В момента има разнообразие от велосипеди, които изпълняват приблизително следния модел. В определен интервал от време някои базови линии се записват в същия PostgreSQL или в отделно хранилище. Можете да ги потърсите в Google, те са. Един от разработчиците на такова нещо седи във форума на 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