Філасофскі ўступ
Як вядома, існуе ўсяго два метады для рашэння задач:
- Метад аналізу ці метад дэдукцыі, ці ад агульнага да прыватнага.
- Метад сінтэзу ці метад індукцыі, ці ад прыватнага да агульнага.
Для вырашэння праблемы "палепшыць прадукцыйнасць базы дадзеных" гэта можа выглядаць наступным чынам.
Аналіз - Разбіраны праблему на асобныя часткі і вырашаючы іх спрабуем у выніку палепшыць прадукцыйнасці базы дадзеных у цэлым.
На практыцы аналіз выглядае прыкладна так:
- Узнікае праблема (інцыдэнт прадукцыйнасці)
- Збіраны статыстычную інфармацыю аб стане базы дадзеных
- Шукаем вузкія месцы (bottlenecks)
- Вырашаем праблемы з вузкіх месцаў
Вузкія месцы базы даных - інфраструктура (CPU, Memory, Disks, Network, OS), налады (postgresql.conf), запыты:
Інфраструктура: магчымасці ўплыву і змены для інжынера - амаль нулявыя.
Настройкі базы дадзеных: магчымасці для зменаў крыху больш чым у папярэднім выпадку, але як правіла ўсё ж такі даволі цяжкія, асабліва ў аблоках.
запыты да базы даных: адзіная вобласць для манеўраў.
Сінтэз - паляпшаем прадукцыйнасць асобных частак, чакаючы, што ў выніку прадукцыйнасць базы дадзеных палепшыцца.
Лірычны ўступ ці навошта ўсё гэта трэба
Як адбываецца працэс вырашэння інцыдэнтаў прадукцыйнасці, калі прадукцыйнасць базы даных не маніторыцца:
Заказчык -"у нас усё дрэнна, доўга, зрабіце нам добра"
Інжынер-" дрэнна гэта як?"
Заказчык - "вось як цяпер (гадзіна таму, учора, на мінулай справе было), павольна"
Інжынер - "а калі было добра?"
Заказчык – “тыдзень (два тыдні) таму было нядрэнна. “(Гэта пашанцавала)
Заказчык - "а я не памятаю, калі было добра, але цяпер дрэнна" (Звычайны адказ)
У выніку атрымліваецца класічная карціна:
Хто вінаваты і што рабіць?
На першую частку пытання адказаць лягчэй за ўсё - вінаваты заўсёды інжынер DBA.
На другую частку адказаць таксама не занадта складана - трэба ўкараняць сістэму маніторынгу прадукцыйнасці базы дадзеных.
Узнікае першае пытанне - што маніторыць?
Шлях 1. Будзем маніторыць УСЕ
Загрузку CPU, колькасць аперацый дыскавага чытання/запісы, памер выдзеленай памяці, і яшчэ мегатонна розных лічыльнікаў, якія любая больш-менш працоўная сістэма маніторынгу можа падаць.
У выніку атрымліваецца куча графікаў, зводных табліц, і бесперапынныя абвесткі на пошту і 100% занятасць інжынера рашэннем кучы аднолькавых тыкетаў, зрэшты, як правіла са стандартнай фармулёўкай - "Temporary issue." No action need”. Затое, усе занятыя, і заўсёды ёсць, што паказаць замоўцу - праца кіпіць.
Шлях 2. Маніторыць толькі тое, што трэба, а што не трэба, не трэба маніторыць
Можна маніторыць, крыху па-іншаму- толькі сутнасці і падзеі:
- На якія інжынер DBA можа ўплываць
- Для якіх існуе алгарытм дзеянняў пры ўзнікненні падзеі ці змены сутнасці.
Зыходзячы з гэтай здагадкі і ўспамінаючыФіласофскі ўступ» з мэтай пазбегнуць рэгулярнага паўтарэнняЛірычны ўступ ці навошта ўсё гэта трэба» мэтазгодна будзе маніторыць прадукцыйнасць асобных запытаў, для аптымізацыі і аналізу, што ў канчатковым выніку павінна прывесці да паляпшэння хуткадзейнасці ўсёй базы дадзеных.
Але для таго, каб палепшыць цяжкі запыт, які ўплывае на агульную прадукцыйнасць базы дадзеных, трэба спачатку яго знайсці.
Такім чынам, узнікае два ўзаемазвязаныя пытанні:
- які запыт лічыцца цяжкім
- як шукаць цяжкія запыты.
Відавочна, цяжкі запыт гэта запыт які выкарыстоўвае шмат рэсурсаў АС для атрымання выніку.
Пераходзім да другога пытання - як шукаць і затым маніторыць цяжкія запыты?
Якія магчымасці для маніторынгу запытаў ёсць у PostgreSQL?
У параўнанні з Oracle, магчымасцяў няшмат, але ўсё ж сёе-тое зрабіць можна.
PG_STAT_STATEMENTS
Для пошуку і маніторынгу цяжкіх запытаў у PostgreSQL прызначана стандартнае пашырэнне pg_stat_statements.
Пасля ўсталёўкі пашырэння ў мэтавай базе дадзеных з'яўляецца аднайменнае ўяўленне, якое і трэба выкарыстоўваць для мэт маніторынгу.
Мэтавыя слупкі pg_stat_statements для пабудовы сістэмы маніторынгу:
- queryid Унутраны хэш-код, вылічаны па дрэве разбору аператара
- max_time Максімальны час, выдаткаваны на аператар, у мілісекундах
Назапасіўшы і выкарыстоўваючы статыстыку па гэтых двух слупках, можна пабудаваць маніторынгавую сістэму.
Як выкарыстоўваецца pg_stat_statements для маніторынгу прадукцыйнасці PostgreSQL
Для маніторынгу прадукцыйнасці запытаў выкарыстоўваецца:
На баку мэтавай базы дадзеных – прадстаўленне pg_stat_statements
З боку сервера і базы дадзеных маніторынгу - набор bash-скрыптоў і сэрвісных табліц.
1 этап - збор статыстычных дадзеных
На хасце маніторынгу па кроне рэгулярна запускаецца скрыпт які капіюе ўтрыманне ўяўлення pg_stat_statements з мэтавай базы дадзеных у табліцу pg_stat_history у базе дадзеных маніторынгу.
Такім чынам, фарміруецца гісторыя выканання асобных запытаў, якую можна выкарыстоўваць для фарміравання справаздач прадукцыйнасці і настройкі метрык.
2 этап - настройка метрык прадукцыйнасці
Грунтуючыся на сабраных дадзеных, выбіраемы запыты, выкананне якіх найболей крытычна/важна для кліента(прыкладанні). Па ўзгадненні з заказчыкам, усталёўваны значэнні метрык прадукцыйнасці выкарыстоўваючы палі queryid і max_time.
Вынік - старт маніторынгу прадукцыйнасці
- Маніторынгавы скрыпт пры запуску правярае сканфігураваныя метрыкі прадукцыйнасці, параўноўваючы значэнне max_time метрыкі са значэннем з уяўлення pg_stat_statements у мэтавай базе дадзеных.
- Калі значэнне ў мэтавай базе даных перавышае значэнне метрыкі - фарміруецца папярэджанне (інцыдэнт у тыкетнай сістэме)
Дадатковая магчымасць 1
Гісторыя планаў выканання запытаў
Для наступнага рашэння інцыдэнтаў прадукцыйнасці вельмі добрае мець гісторыю змены планаў выканання запытаў.
Для захоўвання гісторыі выкарыстоўваецца сэрвісная табліца log_query. Табліца запаўняецца пры аналізе загружанага лог-файла PostgreSQL. Паколькі ў лог-файл у адрозненні ад уяўлення pg_stat_statements пападае поўны тэкст са значэннямі параметраў выканання, а не нармалізаваны тэкст, маецца магчымасць весткі лог не толькі чакай і працягласці запытаў, але і захоўваць планы выканання на бягучы момант часу.
Дадатковая магчымасць 2
Continuous performance improvement process
Маніторынг асобных запытаў у агульным выпадку не прызначаны для рашэння задачы бесперапыннага паляпшэння прадукцыйнасці базы дадзеных у цэлым паколькі кантралюе і вырашае задачы прадукцыйнасці толькі для асобных запытаў. Аднак можна пашырыць метад і наладзіць маніторынг запыты для ўсіх баз даных.
Для гэтага трэба ўвесці дадатковыя метрыкі прадукцыйнасці:
- За апошнія дні
- За базавы перыяд
Скрыпт выбірае запыты з уяўлення pg_stat_statements у мэтавай базе дадзеных і параўноўвае значэнне max_time з сярэднім значэннем max_time, у першым выпадку за апошнія дні або за абраны перыяд часу (baseline), па-другім выпадку.
Такім чынам, у выпадку дэградацыі прадукцыйнасці для любога запыту, папярэджанне будзе сфарміравана аўтаматычна, без ручнога аналізу справаздач.
А пры чым тут сінтэз?
У апісанай падыходзе, як і мяркуе метад сінтэзу - паляпшэннем асобных частак сістэмы, паляпшаем сістэму ў цэлым.
- Запыт выкананы базай дадзеных - тэза
- Зменены запыт - антытэза
- Змена стан сістэмы - сінтэз
развіццё сістэмы
- Пашырэння збіранай статыстыкі даданнем гісторыі для сістэмнага ўяўлення pg_stat_activity
- Пашырэнне збіранай статыстыкі даданнем гісторыі для статыстыкі асобных табліц якія ўдзельнічаюць у запытах
- Інтэграцыя з сістэмай маніторынгу ў воблаку AWS
- І яшчэ, што-небудзь можна прыдумаць...
Крыніца: habr.com
