Прапаную азнаёміцца з расшыфроўкай дакладу Аляксей Лясоўскі з Data Egret "Асновы маніторынгу PostgreSQL"
У гэтым дакладзе Аляксей Лясоўскі раскажа пра ключавыя моманты постгрэсавай статыстыкі, што яны азначаюць, і чаму яны павінны прысутнічаць у маніторынгу; пра тое, якія графікі павінны быць у маніторынгу, як іх дадаць і як інтэрпрэтаваць. Даклад будзе карысны адміністратарам баз дадзеных, сістэмным адміністратарам і распрацоўнікам, якім цікавы траблшутинг Postgres'а.
Мяне клічуць Аляксей Лясоўскі, я прадстаўляю кампанію Data Egret.
Трохі слоў аб сабе. Я пачынаў калісьці даўным-даўно сістэмным адміністратарам.
Адміністраваў усякія розныя Linux, займаўся рознымі рэчамі, злучанымі з Linux, т. е. віртуалізацыяй, маніторынгам, працаваў з проксі і т. д. Але ў нейкі момант я стаў займацца больш базамі дадзеных, PostgreSQL. Ён мне вельмі падабаўся. І ў нейкі момант я пачаў займацца PostgreSQL асноўную частку свайго працоўнага часу. І так паступова я стаў PostgreSQL DBA.
І на працягу ўсёй сваёй кар'еры мне заўсёды былі цікавыя тэмы статыстыкі, маніторынгу, зняцця тэлеметрыі. І калі я быў сістэмным адміністратарам, я займаўся вельмі шчыльна Zabbix. І напісаў невялікі набор скрыптоў як . Ён быў даволі папулярным у свой час. І тамака можна было маніторыць вельмі розныя важныя штукі, не толькі Linux, але яшчэ розныя кампаненты.
Цяпер я займаюся ўжо PostgreSQL. Я пішу ўжо іншую штуку, якая дазваляе працаваць з PostgreSQL-статыстыкай. Яна называецца (артыкул на хабры ).
Невялікая ўступная. Якія бываюць сітуацыі ў нашых замоўцаў, у нашых кліентаў? Адбываецца нейкая аварыя, злучаная з базай дадзенай. І калі ўжо аднавілі базу дадзеных, прыходзіць начальнік аддзела ці начальнік распрацоўкі і кажа: "Сябры, трэба было б нам заманіторыць базу дадзеных, таму што здарылася нешта дрэннае і трэба, каб у будучыні такога не адбывалася". І тут пачынаецца цікавы працэс выбару сістэмы маніторынгу ці адаптацыі існуючай сістэмы маніторынгу для таго, каб можна было маніторыць сваю базу дадзеных - PostgreSQL, MySQL ці нейкія іншыя. І калегі пачынаюць прапаноўваць: «Я чуў, што ёсць вось такая база дадзеных. Давайце выкарыстоўваць яе». Калегі пачынаюць адно з адным спрачацца. І ў выніку атрымліваецца, што мы выбіраем нейкую базу дадзеных, але маніторынг PostgreSQL у ёй прадстаўлены даволі слаба і заўсёды даводзіцца нешта дапілоўваць. Браць нейкія рэпазітары з GitHub, кланаваць іх, адаптаваць скрыпты, неяк даналаджваць. І ў выніку гэта вывальваецца ў нейкую ручную працу.
Таму ў гэтым дакладзе я пастараюся даць вам нейкія веды аб тым, як выбіраць маніторынг не толькі для PostgreSQL, але і для базы дадзеных. І даць тыя веды, якія дазволяць вам дапілаваць ваш маніторынг, каб атрымаць ад яго нейкую карысць, каб можна было маніторыць сваю базу дадзеных з карысцю, каб своечасова папярэджваць нейкія маючыя адбыцца аварыйныя сітуацыі, якія могуць узнікнуць.
І тыя ідэі, якія будуць у гэтым дакладзе, іх можна наўпрост адаптаваць да любой базы дадзеных, няхай гэта будзе СКБД ці noSQL. Таму тут не толькі PostgreSQL, але тут будзе шмат рэцэптаў, як зрабіць гэта ў PostgreSQL. Будуць прыклады запытаў, прыклады сутнасцяў, якія ёсць у PostgreSQL для маніторынгу. І калі ваша СКБД мае такія ж рэчы, якія дазваляюць засунуць іх у маніторынг, вы таксама можаце іх адаптаваць, дадаць і будзе добра.
У дакладзе я не буду
расказваць пра тое, як дастаўляць і захоўваць метрыкі. Не буду нічога казаць аб пост-апрацоўцы дадзеных і падаванні іх карыстачу. І не буду нічога казаць аб алертынгу.
Але па ходзе апавядання я буду паказваць розныя скрыншоты існуючых маніторынгаў, неяк буду іх крытыкаваць. Але тым не менш я пастараюся не называць брэндаў, каб не ствараць рэкламу ці антырэкламу гэтым прадуктам. Таму ўсе супадзенні выпадковыя і застаюцца на вашай фантазіі.
Для пачатку разбяромся, што такое маніторынг. Маніторынг - гэта вельмі важная штука, якую трэба мець. Гэта ўсё разумеюць. Але ў той жа самы час маніторынг не адносіцца да бізнес-прадукту і напрамую не ўплывае на прыбытак кампаніі, таму на маніторынг заўсёды надаюць час па рэшткавым прынцыпе. Калі ў нас ёсць час, то мы займаемся маніторынгам, калі часу няма, то ОК, паставім у бэклог і калі-небудзь вернемся да гэтых задач.
Таму з нашай практыкі, калі мы прыходзім да кліентаў, маніторынг часта недапрацаваны і не мае нейкіх цікавых рэчаў, якія дапамагалі б нам рабіць працу лепш з базай даных. І таму маніторынг заўсёды трэба дапілоўваць.
Базы дадзеных - гэта такія складаныя штукі, якія таксама трэба маніторыць, таму што базы дадзеных - гэта сховішча інфармацыі. І інфармацыя вельмі важная для кампаніі, яе нельга губляць. Але ў той жа час базы дадзеных - гэта вельмі складаныя кавалкі праграмнага забеспячэння. Яны складаюцца з вялікай колькасці кампанентаў. І многія з гэтых кампанентаў трэба маніторыць.
Калі мы гаворым канкрэтна пра PostgreSQL, то яго можна прадставіць у выглядзе такой схемы, якая складаецца з вялікай колькасці кампанентаў. Гэтыя кампаненты ўзаемадзейнічаюць сябар з сябрам. І ў той жа час у PostgreSQL ёсць, так званая, падсістэма Stats Collector, якая дазваляе збіраць статыстыку аб працы гэтых падсістэм і падаваць нейкі інтэрфейс адміністратару ці карыстачу, каб ён мог праглядаць гэтую статыстыку.
Гэтая статыстыка прадстаўлена ў выглядзе некаторага набору функцый і завіруха (view). Іх можна яшчэ назваць табліцамі. Т. е. з дапамогай звычайнага psql кліента вы можаце падлучыцца да базы дадзеных, зрабіць select да гэтых функцый і завірухам, і атрымаць ужо нейкія пэўныя цыферкі аб працы падсістэм PostgreSQL.
Вы можаце дадаць гэтыя цыферкі ў вашу любімую сістэму маніторынгу, намаляваць графікі, дадаць функцыі і атрымаць аналітыку ў доўгатэрміновай перспектыве.
Але ў гэтым дакладзе я ня буду разглядаць пагалоўна ўсе гэтыя функцыі, бо гэта можа заняць цэлы дзень. Я буду звяртацца літаральна да двух-трох-чатырох штук і буду расказваць, як яны дапамагаюць зрабіць маніторынг лепшым.
І калі казаць пра маніторынг базы, дык што трэба маніторыць? У першую чаргу трэба маніторыць даступнасць, таму што база - гэта сэрвіс, які дае доступ да дадзеных кліентаў і нам трэба маніторыць даступнасць, а дае таксама яе некаторыя якасныя і колькасныя характарыстыкі.
Таксама трэба маніторыць кліентаў, якія падключаюцца да нашай базы, таму што яны могуць быць як і нармальнымі кліентамі, так і шкоднымі кліентамі, якія могуць наносіць шкоду базе даных. Іх таксама трэба маніторыць і адсочваць іх дзейнасьць.
Калі кліенты падключаюцца да базы дадзеных, то відавочна, што яны пачынаюць працаваць з нашымі дадзенымі, таму нам трэба маніторыць і тое, як кліенты працуюць з дадзенымі: з якімі табліцамі, у меншай ступені з якімі азначнікамі. Т. е. нам трэба ацаніць варклоад (workload), які ствараецца нашымі кліентамі.
Але і варклаад складаецца, вядома, з запытаў. Прыкладанні падключаюцца да базы, звяртаюцца да дадзеных з дапамогай запытаў, таму важна ацэньваць, якія запыты ў нас у базе дадзеных, адсочваць іх адэкватнасць, што яны не з'яўляюцца крыва напісанымі, што нейкія опцыі трэба перапісаць і зрабіць так, каб яны працавалі хутчэй і з больш лепшай прадукцыйнасцю.
І раз мы гаворым пра базу дадзеных, то база дадзеных - гэта заўсёды фонавыя працэсы. Фонавыя працэсы дазваляюць падтрымліваць прадукцыйнасць базы дадзеных на добрым узроўні, таму для іх працы яны патрабуюць нейкую колькасць рэсурсаў для сябе. І ў той жа час яны могуць перасякацца з рэсурсамі кліенцкіх запытаў, таму прагная праца фонавых працэсаў можа непасрэдна ўплываць на прадукцыйнасць кліенцкіх запытаў. Таму іх таксама трэба маніторыць і адсочваць, што няма ніякіх перакосаў у плане фонавых працэсаў.
І гэта ўсё ў плане маніторынгу базы даных застаецца ў сістэмнай метрыцы. Але улічваючы, што ў нас па большай частцы ўся інфраструктура з'яжджае ў аблокі, сістэмныя метрыкі асобнага хаста заўсёды адыходзяць на другі план. Але ў базах даных яны ўсё яшчэ актуальныя і маніторыць сістэмныя метрыкі, вядома, таксама трэба.
З сістэмнымі метрыкамі больш-менш усё добра, усе сучасныя сістэмы маніторынгу ўжо падтрымліваюць гэтыя метрыкі, але ў цэлым нейкіх кампанентаў усё ж недастаткова і трэба некаторыя рэчы дадаваць. Пра іх я таксама закрану, некалькі слайдаў будзе пра іх.
Першы пункт плана - гэта даступнасць. Што такое даступнасць? Даступнасць у маім разуменні - гэта здольнасць базы абслугоўваць падлучэнні, т. е. база паднятая, яна, як сэрвіс, прымае падлучэнні ад кліентаў. І гэтую даступнасць можна ацэньваць некаторымі характарыстыкамі. Гэтыя характарыстыкі вельмі зручна выносіць на дашборды.
Усе ведаюць, што такое дашборды. Гэта калі ты кінуў адзін погляд на экран, на якім зведзена неабходная інфармацыя. І вы ўжо можаце адразу вызначыць - ёсць праблема ў базе ці не.
Адпаведна даступнасць базы дадзеных і іншыя ключавыя характарыстыкі заўсёды неабходна выносіць на дашборды, каб гэтая інфармацыя была пад рукой, была ў вас заўсёды побач. Нейкія дадатковыя дэталі, якія ўжо дапамагаюць пры расследаванні інцыдэнтаў, пры расследаванні нейкіх аварыйных сітуацый, іх ужо трэба выносіць на другасныя дашборды, альбо хаваць у drilldown-лінках, якія вядуць на іншыя сістэмы маніторынгу.
Прыклад адной вядомай сістэмы маніторынгу. Гэта вельмі крутая сістэма маніторынгу. Яна збірае вельмі шмат дадзеных, але з майго пункта гледжання, у яе дзіўнае паняцце дашбордаў. Там ёсць спасылка "стварыць дашборд". Але калі вы ствараеце дашборд, вы ствараеце нейкі спіс, які складаецца з дзвюх калонак, нейкі спіс графікаў. І калі вам трэба нешта паглядзець, вы пачынаеце мышкай клікаць, гартаць, шукаць патрэбны графік. І на гэта сыходзіць час, т. е. дашбордаў, як такіх, няма. Ёсць толькі спісы графікаў.
Што трэба дадаваць на гэтыя дашборды? Можна пачаць з такой характарыстыкі як час водгуку. У PostgreSQL ёсць завіруха pg_stat_statements. Па змаўчанні яна адключаная, але гэта адна з важных сістэмных завірух, якую заўсёды неабходна ўключаць і выкарыстоўваць. Яна захоўвае ў сабе інфармацыю аб усіх выкананых запытах, якія ў базе дадзеных выконваліся.
Адпаведна, мы можам адштурхнуцца ад таго, што можна ўзяць сумарны час выканання ўсіх запытаў і падзяліць на колькасць запытаў з дапамогай вышэйпрыведзеных палёў. Але гэта такая сярэдняя тэмпература па шпіталі. Мы можам адштурхнуцца ад іншых палёў - мінімальны час выканання запытаў, максімальны і медыяны. І нават можам будаваць перцентили, у PostgreSQL ёсць адпаведныя функцыі для гэтага. І мы можам атрымаць нейкія лічбы, якія характарызуюць час водгуку нашай базы па ўжо выкананым запытам, т. е. мы не выконваем фэйкавы запыт 'select 1' і глядзім час водгуку, а мы аналізуем час адказаў па ўжо выкананым запытам і малюем альбо асобнай лічбай, альбо які будуецца па ёй графік.
Таксама важна адсочваць колькасць памылак, якія генеруюцца сістэмай у дадзены момант. І для гэтага можна выкарыстоўваць завіруху pg_stat_database. Мы арыентуемся на поле xact_rollback. Гэтае поле паказвае не толькі колькасць rollback, якія адбываюцца ў базе, але яшчэ і ўлічвае колькасць памылак. Умоўна кажучы, мы можам выводзіць гэтую лічбу ў наш дашборд і глядзець колькі ў нас памылак у дадзены момант. Калі памылак шмат, то гэта ўжо добрая нагода зазірнуць у логі і паглядзець, што ж гэта за памылкі і чаму яны адбываюцца, а далей ужо інвеставаць і вырашаць іх.
Можна дадаць такую штуку, як Тахометр. Гэта колькасць транзакцый у секунду і колькасць запытаў у секунду. Умоўна кажучы, вы можаце выкарыстоўваць гэтыя лічбы як бягучую прадукцыйнасць вашай базы дадзеных і назіраць ці ёсць пікі запытаў, пікі транзакцый ці, наадварот, база недагружана, таму што нейкі backend адваліўся. Гэтую лічбу важна заўсёды глядзець і памятаць, што для нашага праекта вось такая прадукцыйнасць з'яўляецца нармальнай, а значэнні вышэй і ніжэй ужо нейкія праблемныя і незразумелыя, а значыць, трэба глядзець, чаму такія лічбы.
Для таго каб ацэньваць колькасць транзакцый, мы зноў можам звярнуцца да завірухі pg_stat_database. Мы можам скласці колькасць commit і колькасць rollback і атрымаць колькасць транзакцый у секунду.
Усе разумеюць, што ў адну транзакцыю можа ўкласціся некалькі запытаў? Таму TPS і QPS крыху розныя.
Колькасць запытаў у секунду можна атрымаць па pg_stat_statements і проста пралічыць суму ўсіх выкананых запытаў. Зразумела, што мы параўноўваем бягучае значэнне з папярэднім, адымаем, атрымліваем дэльту, атрымліваем колькасць.
Можна дадаць дадатковыя метрыкі па жаданні, якія таксама дапамагаюць ацэньваць даступнасць нашай базы і адсочваць - ці не было нейкіх downtime.
Адна з гэтых метрык - гэта uptime. Але uptime у PostgreSQL – гэта крыху хітрая штука. Раскажу, чаму. Калі PostgreSQL запусціўся, пачынаецца даваць справаздачу uptime. Але калі ў нейкі момант, напрыклад, уначы выконвалася нейкая задача, прыйшоў OOM-killer і завяршыў прымусова даччыны працэс PostgreSQL, то ў гэтым выпадку PostgreSQL завяршае злучэнне ўсіх кліентаў, скідае вобласць шардаванай памяці і пачынае ўзнаўленне з апошняй кантрольнай кропкі. І пакуль доўжыцца гэтае аднаўленне з кантрольнай кропкі, база не прымае падлучэнні, т. е. гэтую сітуацыю можна ацэньваць, як downtime. Але пры гэтым лічыльнік uptime не скінецца, таму што ён улічвае час запуску postmaster з самага першага моманту. Таму такія сытуацыі можна прапусьціць.
Таксама варта маніторыць колькасць воркераў вакууму. Усе ведаюць, што такое autovacuum у PostgreSQL? Гэта цікавая падсістэма ў PostgreSQL. Пра яе напісана шмат артыкулаў, шмат зроблена дакладаў. Шмат абмеркаванняў пра вакуум, пра тое, як ён мусіць працаваць. Многія лічаць яго непазбежным злом. Але так і ёсьць. Гэта нейкі аналог зборшчыка смецця, які чысціць састарэлыя версіі радкоў, якія не патрэбныя ніводнай з транзакцыі і вызваляе месца ў табліцах, індэксах для новых радкоў.
Чаму трэба яго маніторыць? Бо вакуум часам робіць вельмі балюча. Ён аджырае вялікую колькасць рэсурсаў і кліенцкія запыты ад гэтага пачынаюць пакутаваць.
І маніторыць варта яго праз завіруху pg_stat_activity, пра якую я буду казаць у наступнай частцы. Гэтая завіруха паказвае бягучую актыўнасць у базе дадзеных. І праз гэтую актыўнасць мы можам адсачыць колькасць вакуумаў, якія працуюць прама зараз. Мы можам адсочваць вакуумы і бачыць, што калі ў нас перавышаны ліміт, то гэта нагода зазірнуць у налады PostgreSQL і неяк аптымізаваць працу вакууму.
Іншы асаблівасцю PostgreSQL з'яўляецца тое, што PostgreSQL вельмі балюча ад доўгіх транзакцый. Асабліва ад транзакцый, якія доўга вісяць і нічога не робяць. Гэта так званыя stat idle-in-transaction. Такая транзакцыя ўтрымлівае блакіроўкі, яна перашкаджае працаваць вакууму. І як следства - табліцы пухнуць, яны павялічваюцца ў памеры. І запыты, якія працуюць з гэтымі табліцамі, яны пачынаюць працаваць павольней, таму што трэба лапаціць усе старыя версіі радкоў з памяці на дыск і назад. Таму час, працягласць самых доўгіх транзакцый, самых доўгіх запытаў вакууму таксама трэба маніторыць. І калі мы бачым нейкія працэсы, якія працуюць ужо вельмі доўга, ужо больш за 10-20-30 хвілін для OLTP-нагрузкі, то на іх трэба ўжо звяртаць увагу і завяршаць прымусова, або аптымізаваць дадатак, каб яны не выклікаліся і не віселі. так доўга. Для аналітычнай нагрузкі 10-20-30 хвілін - гэта нармальна, там бывае яшчэ і больш доўгія.
Далей у нас варыянт з падключанымі кліентамі. Калі мы ўжо сфарміравалі дашборд, вывесілі на яго ключавыя метрыкі даступнасці, мы можам таксама дадаць туды і дадатковую інфармацыю аб падлучаных кліентах.
Інфармацыя аб падлучаных кліентах важная, таму што, з пункта гледжання PostgreSQL, кліенты бываюць рознымі. Бываюць добрыя кліенты, бываюць благія кліенты.
Просты прыклад. Пад кліентам я разуменню дадатак. Прыкладанне падключылася да базы дадзеных і пачынае адразу слаць туды свае запыты, база дадзеных іх апрацоўвае і выконвае, вынікі вяртае кліенту. Гэта добрыя і правільныя кліенты.
Бываюць сітуацыі, што кліент падключыўся, ён утрымлівае канэкт, але пры гэтым нічога не робіць. Ён знаходзіцца ў стане idle.
Але бываюць кепскія кліенты. Напрыклад, той жа кліент падключыўся, адкрыў транзакцыю, нешта парабіў у базе і потым сышоў у код, дапусцім, каб звярнуцца да знешняй крыніцы або для таго, каб зрабіць там апрацоўку, атрыманых дадзеных. Але пры гэтым ён не закрыў транзакцыю. І транзакцыя вісіць у базе і ўтрымлівае ў блакіроўку на радку. Гэты дрэнны стан. І калі раптам прыкладанне дзесьці ўсярэдзіне ў сябе зваліцца па эксэпшане (Exception), то транзакцыя можа застацца адчыненай на вельмі доўгі час. І гэта ўплывае напрамую на прадукцыйнасць PostgreSQL. PostgreSQL будзе працаваць павольней. Таму такіх кліентаў важна своечасова адсочваць і завяршаць іх працу прымусова. І трэба аптымізаваць сваё прыкладанне, каб не было такіх сітуацый.
Іншымі дрэннымі кліентамі з'яўляюцца якія чакаюць кліенты. Але яны становяцца дрэннымі з-за абставін. Напрыклад, простая транзакцыя: можа адкрыць транзакцыю, узяць блакіроўкі на нейкія радкі, потым дзесьці ў кодзе яна ўпадзе, застанецца транзакцыя, якая вісіць. Прыйдзе іншы кліент, запытае тыя ж самыя дадзеныя, але ён сутыкнецца з блакіроўкай, таму што тая віслая транзакцыя ўжо ўтрымлівае блакіроўкі на нейкія патрэбныя радкі. І другая транзакцыя будзе вісець у чаканні, калі першая транзакцыя завершыцца ці яе адміністратар прымусова закрые. Такім чынам, якія чакаюць транзакцыі могуць назапашвацца і перапаўняць ліміт падлучэнняў да базы дадзеных. І калі ліміт перапоўнены, то дадатак ужо не можа працаваць з базай. Гэта ўжо аварыйная сітуацыя для праекту. Таму кепскіх кліентаў трэба адсочваць і своечасова на іх рэагаваць.
Іншы прыклад маніторынгу. І тут ужо прыстойны дашборд. Ёсць інфармацыя па канэктах зверху. DB connection - 8 штук. І гэта ўсё. У нас няма інфармацыі аб тым, якія кліенты актыўныя, якія кліенты проста idle, нічога не робяць. Няма інфармацыі аб віслых транзакцыях і аб якія чакаюць канэктах, т. е. гэта такая лічба, якая паказвае колькасць канэктаў і ўсё. А далей варожаце самі.
Адпаведна, каб дадаць гэтую інфармацыю ў маніторынг, трэба звярнуцца да сістэмнай завірухі pg_stat_activity. Калі вы шмат часу праводзіце ў PostgreSQL, то гэта вельмі добрая завіруха, якая павінна стаць вашым сябрам, таму што яна паказвае бягучую актыўнасць у PostgreSQL, т. е. што адбываецца ў ім. На кожны працэс ёсць асобны радок, які паказвае інфармацыю па гэтым працэсе: з якога хаста выканана падключэнне, пад якім карыстальнікам, пад якім імем, калі запушчана транзакцыя, які зараз выконваецца запыт, які запыт выконваўся апошнім. І, адпаведна, стан кліента мы можам ацэньваць па полі stat. Умоўна кажучы, мы можам зрабіць групоўку па гэтым полі і атрымаць тыя stats-ы, якія ёсць зараз у базе дадзеных і колькасць канэктаў, якія з гэтым stat-ам у базе дадзеных. І ўжо атрыманыя лічбы мы можам дасылаць у наш маніторынг і маляваць па іх графікі.
Таксама важна ацэньваць працягласць транзакцыі. Я ўжо казаў, што важна ацэньваць працягласць вакуумаў, але і транзакцыі ацэньваюцца сапраўды гэтак жа. Ёсць палі xact_start і query_start. Яны, умоўна кажучы, паказваюць час старту транзакцыі і час старту запыту. Мы бярэм функцыю now(), якая паказвае бягучую адзнаку часу і адымаем timestamp транзакцыі і запыту. І атрымліваем працягласць транзакцыі, працягласць запыту.
Калі мы бачым доўгія транзакцыі, мы павінны іх ужо завяршаць. Для OLTP-нагрузкі доўгія транзакцыі - гэта ўжо больш за 1-2-3 хвілін. Для OLAP-нагрузкі доўгія транзакцыі з'яўляюцца нармальнымі, але калі яны выконваюцца больш за дзве гадзіны, то гэта таксама прыкмета таго, што дзесьці ў нас ёсць перакос.
Калі кліенты падключыліся да базы даных, яны пачынаюць працаваць з нашымі дадзенымі. Яны звяртаюцца да табліц, яны звяртаюцца да індэксаў, каб атрымаць дадзеныя з табліцы. І важна ацэньваць тое, як кліенты працуюць з гэтымі дадзенымі.
Гэта трэба для таго, каб ацэньваць наш варклаад і прыкладна разумець, якія табліцы ў нас самыя "гарачыя". Напрыклад, гэта трэба ў сітуацыях, калі мы хочам "гарачыя" табліцы змясціць на нейкае хуткае SSD сховішча. Напрыклад, нейкія архіўныя табліцы, якія мы ўжо даўно не выкарыстоўваем можна вынесці на нейкі "халодны" архіў, на SATA дыскі і няхай яны там жывуць, да іх зварот будзе ісці па неабходнасці.
Таксама гэта карысна для выяўлення анамалій пасля ўсякіх рэлізаў і дэплояў. Дапушчальны, праект выкаціў нейкую новую фічу. Напрыклад, дадалі новую функцыянальнасць для працы з базай. І калі мы пабудуем графікі выкарыстання табліц, мы на гэтых графіках зможам лёгка выявіць гэтыя анамаліі. Напрыклад, усплёскі update або воплескі delete. Гэта вельмі добра будзе бачна.
Таксама можна выявіць анамаліі "паплыў" статыстыкі. Што гэта значыць? У PostgreSQL вельмі моцны і вельмі добры планавальнік запытаў. І распрацоўшчыкі шмат часу надаюць яго развіццю. Як ён працуе? Для таго каб будаваць добрыя планы, PostgreSQL з некаторым інтэрвалам часу, з некаторай перыядычнасцю збірае статыстыку аб размеркаванні дадзеных у табліцах. Гэта самыя частыя значэнні: колькасць унікальных значэнняў, інфармацыя аб NULL у табліцы, вельмі шмат інфармацыі.
На аснове гэтай статыстыкі планавальнік будуе некалькі запытаў, выбірае найбольш аптымальны і выкарыстоўвае гэты план запыту для выканання самага запыту і вяртання даных.
І бывае, што статыстыка "плыве". Дадзеныя якасці, колькасці памяняліся неяк у табліцы, але статыстыка пры гэтым не сабралася. І сфармаваныя планы могуць аказацца не аптымальнымі. І калі ў нас планы акажуцца неаптымальнымі па збіраемым маніторынгу, па табліцах, мы зможам убачыць гэтыя анамаліі. Напрыклад, дзесьці якасна змяніліся дадзеныя і разам азначніка стаў выкарыстоўвацца паслядоўны праход па табліцы, г.зн. калі запыту трэба вярнуць усяго толькі 100 радкоў (варта абмежаванне limit 100), то для гэтага запыту будзе выкананы поўны перабор. І гэта заўсёды вельмі дрэнна адбіваецца на прадукцыйнасці.
І мы зможам убачыць гэта ў маніторынгу. І ўжо паглядзець на гэты запыт, выканаць для яго explain, сабраць статыстыку, пабудаваць новы дадатковы азначнік. І ўжо адрэагаваць на гэтую праблему. Таму гэта так важна.
Іншы прыклад маніторынгу. Я думаю, шмат хто яго даведаўся, таму што ён вельмі папулярны. Хто выкарыстоўвае ў сябе ў праектах ? А хто выкарыстоўвае гэты прадукт сумесна з Prometheus? Справа ў тым, што ў стандартным рэпазітары гэтага маніторынгу ёсць дашборд для працы з PostgreSQL. Prometheus. Але тут ёсць адна дрэнная дэталь.
Ёсць некалькі графікаў. І ў якасці unity паказаны байты, т. е. тамака 5 графікаў. Гэта Insert data, Update data, Delete data, Fetch data і Return data. У якасці unit вымярэння пазначаны байты. Але справа ў тым, што статыстыка ў PostgreSQL вяртае дадзеныя ў tuple (радках). І, адпаведна, гэтыя графікі - гэта вельмі добры спосаб прынізіць ваш варклоад ў некалькі разоў, у дзесяткі разоў, таму што tuple - гэта не байт, tuple - гэта радок, гэта шмат байтаў і яна заўсёды зменнай даўжыні. Т. е. вылічыць варклоад ў байтах з дапамогай tuples - гэта нерэальная задача або вельмі складаная. Таму, калі вы выкарыстоўваеце дашборд ці ўбудаваны маніторынг, заўсёды важна разумець, што ён працуе правільна і вяртае вам карэктна ацэненыя дадзеныя.
Як атрымліваць статыстыку па гэтых табліцах? Для гэтага ў PostgreSQL ёсць некаторае сямейства завірух. І асноўная завіруха - гэта . User_tables - гэта азначае, што табліцы, створаныя ад асобы карыстальніка. У процівагу ёсць сістэмныя завірухі, якія выкарыстоўваюцца самім PostgreSQL. І ёсць зводная табліца Alltables, якая ўключае і сістэмныя, і прыстасаваныя. Вы можаце адштурхоўвацца ад любой з іх, якая вам больш за ўсё падабаецца.
Па вышэйпаказаных палях можна ацэньваць колькасць insert, update і delete. Той прыклад дашборда, які я выкарыстоўваў, як раз выкарыстоўвае гэтыя палі для ацэнкі характарыстык варклааду. Таму мы таксама можам адштурхоўвацца ад іх. Але варта памятаць, што гэта tuples, а не байты, таму мы ня можам узяць і зрабіць гэта байтамі.
На аснове гэтых дадзеных мы можам будаваць так званыя TopN-табліцы. Напрыклад, Top-5, Top-10. І можна адсочваць тыя гарачыя табліцы, якія ўтылізуюцца больш за астатніх. Напрыклад, 5 "гарачых" табліц па ўстаўцы. І па гэтых TopN-табліцах мы ацэньваем наш варклаад і можам ацэньваць усплёскі варклааду пасля ўсякіх рэлізаў і апдэйтаў, і дэплояў.
Таксама важна ацэньваць памеры табліцы, таму што часам распрацоўшчыкі выкочваюць новую фічу, і ў нас табліцы пачынаюць пухнуць у сваіх вялікіх памерах, таму што вырашылі дапісаць дадатковы аб'ём дадзеных, але пры гэтым не спрагназавалі, як гэта адаб'ецца на памеры базы дадзеных. Такія выпадкі таксама бываюць для нас неспадзеўкамі.
І зараз невялікае пытанне для вас. Якое ўзнікае пытанне, калі вы заўважаеце нагрузку на сэрвэры з базай дадзеных? Якое наступнае пытанне ў вас узнікае?
Але насамрэч пытанне ўзнікае наступнае. Якія запыты выклікае нагрузка? Т. е. не цікава глядзець працэсы, якія выклікае нагрузка. Зразумела, што калі host з базай дадзеных, то тамака запушчана база дадзеных і зразумела, што толькі базы дадзеных там і будзе ўтылізаваць. Калі мы адкрыем Top, то ўбачым там спіс працэсаў у PostgreSQL, якія нешта робяць. З Top будзе не зразумела, што яны робяць.
Адпаведна, трэба выявіць тыя запыты, якія выклікаюць найбольшую загрузку, таму што цюнінг запытаў, як правіла, дае больш профіт, чым цюнінг канфігурацыі PostgreSQL ці аперацыйнай сістэмы, ці нават цюнінг жалеза. Па маёй ацэнцы - гэта прыкладна 80-85-90%. І гэта робіцца значна хутчэй. Хутчэй паправіць запыт, чым паправіць канфігурацыю, запланаваць рэстарт, асабліва, калі базу рэстартаваць нельга, альбо дадаваць жалеза. Прасцей недзе перапісаць запыт або дадаць індэкс, каб атрымаць ужо больш лепшы вынік ад гэтага запыту.
Адпаведна, трэба маніторыць запыты і іх адэкватнасць. Возьмем іншы прыклад маніторынгу. І тут таксама нібыта выдатны маніторынг. Ёсць інфармацыя па рэплікацыі, ёсць інфармацыя па прапускной здольнасці, блакіроўкам, утылізацыі рэсурсаў. Усё цудоўна, але няма інфармацыі па запытах. Не зразумела, якія запыты выконваюцца ў нашай базе даных, як доўга яны выконваюцца, колькі гэтых запытаў. Нам трэба ў маніторынгу заўжды мець гэтую інфармацыю.
І для атрымання гэтай інфармацыі мы можам выкарыстоўваць модуль pg_stat_statements. На яго аснове можна будаваць самыя розныя графікі. Напрыклад, можна атрымліваць інфармацыю па самых частых запытах, т. е. па тых запытах, якія выконваюцца часцей за ўсіх. Так, пасля дэплояў таксама вельмі карысна паглядзець на яго і разумець, ці няма нейкага ўсплёску запытаў.
Можна маніторыць самыя доўгія запыты, г. зн. тыя запыты, якія выконваюцца даўжэй за ўсіх. Яны працуюць на працэсары, яны спажываюць увод-вывад. Мы гэта таксама можам ацэньваць па палях total_time, mean_time, blk_write_time і blk_read_time.
Мы можам ацэньваць і маніторыць самыя цяжкія запыты ў плане выкарыстання рэсурсаў, тыя, якія чытаюць з дыска, якія працуюць з памяццю ці, наадварот, ствараюць нейкую нагрузку.
Можам ацэньваць самыя шчодрыя запыты. Гэта тыя запыты, якія вяртаюць вялікую колькасць радкоў. Напрыклад, гэта можа быць нейкі запыт, дзе забыліся паставіць ліміт. І ён проста вяртае ўсё змесціва табліцы ці запыту па запытаных табліцах.
І можна таксама маніторыць запыты, якія выкарыстоўваюць часовыя файлы ці часовыя табліцы.
І ў нас засталіся фонавыя працэсы. Фонавыя працэсы - гэта ў першую чаргу чэкпоінты або іх яшчэ называюць кантрольнымі кропкамі, гэта autovacuum і рэплікацыя.
Іншы прыклад маніторынгу. Ёсць злева ўкладка Maintenance, пераходзім на яе і спадзяемся ўбачыць, нешта карыснае. Але тут толькі час працы вакуума і збору статыстыкі, больш нічога. Гэта вельмі бедная інфармацыя, таму заўсёды трэба мець інфармацыю аб тым, як працуюць фонавыя працэсы ў нас у базе дадзеных і ці няма праблем ад іх працы.
Калі мы разглядаем кантрольныя кропкі, то варта памятаць, што кантрольныя кропкі ў нас скідаюць "брудныя" старонкі з вобласці шардаванай памяці на дыск, затым ствараюць кантрольную кропку. І гэты кантрольны пункт ужо далей можа выкарыстоўвацца як нейкае месца пры аднаўленні, калі раптам PostgreSQL быў завершаны ў аварыйным парадку.
Адпаведна, каб скінуць усе "брудныя" старонкі на дыск, трэба прарабіць нейкі аб'ём запісу. І, як правіла, на сістэмах з вялікім аб'ёмам памяці - гэта вельмі шмат. І калі ў нас чэкпоінты робяцца вельмі часта ў нейкі кароткі інтэрвал, то дыскавая прадукцыйнасць будзе вельмі моцна асядаць. І кліенцкія запыты будуць пакутаваць ад недахопу рэсурсаў. Яны будуць змагацца за рэсурсы і ім будзе не хапаць прадукцыйнасці.
Адпаведна, праз pg_stat_bgwriter па паказаных палях мы можам маніторыць колькасць якія здараюцца чэкпаінтаў. І калі ў нас за нейкі прамежак часу (за 10-15-20 хвілін, за паўгадзіны) вельмі шмат чэкпаінтаў, напрыклад, 3-4-5, то гэта ўжо можа быць праблемай. І ўжо трэба паглядзець у базе дадзеных, паглядзець у канфігурацыі, што выклікае такое разнастайнасць чэкпаінтаў. Можа быць, нейкі вялікі запіс ідзе. Па варклаадзе можам ужо ацаніць, таму што ў нас графікі варклааду ўжо дабаўлены. Мы можам ужо падцюніць параметры кантрольных кропак і зрабіць так, каб яны не моцна ўплывалі на прадукцыйнасць запытаў.
Я зноў вяртаюся да autovacuum, таму што гэта такая штука, як я ўжо казаў, якая проста можа скласці прадукцыйнасць як дыскаў, так і запытаў, таму заўсёды важна ацэньваць колькасць autovacuum.
Колькасць воркераў autovacuum у базе дадзеных абмежавана. Па змаўчанні іх тры, таму калі ў нас увесь час тры воркера працуюць у базе, тое гэта значыць, што ў нас autovacuum неданастроены, трэба паднімаць ліміты, пераглядаць налады autovacuum і ўжо лезці ў канфігурацыю.
Важна ацэньваць якія ў нас працуюць воркера вакууму. Або гэта запушчаны ад карыстальніка, 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-ай версіі дадаліся радкі, якія канкрэтна паказваюць лаг. Гэта write lag, flush lag, replay lag. Т. е. гэтыя штукі важна маніторыць. Калі мы бачым, што ў нас лаг рэплікацыі, то трэба даследаваць, чаму ён з'явіўся, адкуль узяўся і ўстараняць праблему.
З сістэмнымі метрыкамі практычна ўсё ў парадку. Калі зараджаецца любы маніторынг, ён пачынае з сістэмных метрык. Гэта утылізацыя працэсараў, памяці, swap, сеткі і дыска. Але тым не менш шматлікіх параметраў тамака па змаўчанні няма.
Калі з утылізацыяй працэсу ўсё ў парадку, то з утылізацыяй дыска ёсць праблемы. Як правіла, распрацоўшчыкі маніторынгаў дадаюць інфармацыю аб прапускной здольнасці. Яна можа быць у iops ці байтах. Але яны забываюць пра latency і ўтылізацыю дыскавых прылад. Гэта важнейшыя параметры, якія дазваляюць ацэньваць, наколькі ў нас загружаныя дыскі і наколькі яны тармозяць. Калі ў нас высокі latency, то гэта значыць, што есць нейкія праблемы з дыскамі. Калі ў нас высокая ўтылізацыя, тое гэта значыць, што дыскі не спраўляюцца. Гэта больш якасныя характарыстыкі, чым прапускная здольнасць.
Пры тым, што гэтую статыстыку можна таксама атрымаць з файлавай сістэмы /proc, як гэта робіцца для ўтылізацыі працэсараў. Чаму гэтую інфармацыю не дадаюць у маніторынгі, я не ведаю. Але, тым не менш, важна мець гэта ў сваім маніторынгу.
Тое ж самае адносна сеткавых інтэрфейсаў. Ёсць інфармацыя аб прапускной здольнасці сеткі ў пакетах, у байтах, але тым не менш няма інфармацыі аб latency і няма інфармацыі аб утылізацыі, хоць гэта таксама карысная інфармацыя.
Любыя маніторынгі маюць недахопы. І які маніторынг вы б не ўзялі, ён заўсёды будзе не адпавядаць нейкім крытэрам. Але тым не менш яны развіваюцца, дадаюцца новыя фічы, новыя рэчы, таму выбірайце нешта і дапілоўвайце.
І для таго каб дапілоўваць, трэба заўсёды мець уяўленне, што азначае якая аддаецца статыстыка і як з дапамогай яе можна вырашаць праблемы.
І некалькі ключавых момантаў:
- Заўсёды трэба маніторыць даступнасць, мець дашборды, каб вы маглі хутка ацаніць, што з базай усё ў парадку.
- Заўсёды трэба мець уяўленне аб тым, якія кліенты працуюць з вашай базай дадзенай, каб адсяваць дрэнных кліентаў і адстрэльваць іх.
- Важна ацэньваць тое, як гэтыя кліенты працуюць з дадзенымі. Трэба мець уяўленне аб вашым Варклаад.
- Важна ацэньваць, як фарміруецца гэты варклаад, з дапамогай якіх запытаў. Вы можаце ацэньваць запыты, вы можаце іх аптымізаваць, рэфактарыць, будаваць для іх індэксы. Гэта вельмі важна.
- Фонавыя працэсы могуць негатыўна ўплываць на кліенцкія запыты, таму важна адсочваць, каб яны не выкарыстоўваюць занадта шмат рэсурсаў.
- Сістэмныя метрыкі дазваляюць вам рабіць планы на маштабаванне, на павелічэнне ёмістасці вашых сервераў, таму важна таксама іх адсочваць і ацэньваць.
Калі вас зацікавіла гэтая тэма, тыя вы можаце прайсціся па гэтых спасылках.
- Гэта афіцыйная дакументацыя з калектара статыстыкі. Там ёсць апісанне ўсіх статыстычных завірух і апісанне ўсіх палёў. Вы можаце іх прачытаць, зразумець і прааналізаваць. І ўжо на аснове іх будаваць свае графікі, дабаўляць у свае маніторынгі.
Прыклады запытаў:
Гэта карпаратыўны наш рэпазітар і мой уласны. У іх ёсць прыклады запытаў. Там няма запытаў з серыі select* from нешта там. Тамака ўжо гатовыя запыты з джойнамі, з ужываннем цікавых функцый, якія дазваляюць з волкіх лічбаў зрабіць чытэльныя, зручныя значэнні, т. е. гэта байты, час. Вы можаце іх калупаць, глядзець, аналізаваць, дадаваць у свае маніторынгі, будаваць на іх аснове свае маніторынгі.
пытанні
Пытанне: Вы сказалі, што не будзеце рэкламаваць брэнды, але мне ўсё ж цікава - у сваіх праектах вы якія дашборды карыстаецеся?
Адказ: Па-рознаму. Бывае, што мы прыходзім да замоўца і ў яго ўжо ёсць свой маніторынг. І мы кансультуем заказчыка аб тым, што трэба дадаць у яго маніторынг. Горш за ўсё ідуць справы з Zabbiх. Бо ў яго няма магчымасці будаваць TopN-графікі. Самі мы выкарыстоўваем , таму што мы кансультавалі гэтых хлопцаў па маніторынгу. Яны рабілі маніторынг PostgreSQL на аснове нашага ТЗ. Я пішу свой pet-project, які дадзеныя збірае праз Prometheus і адмалёўвае іх у . У мяне задача зрабіць у Prometheus свой экспарцёр і далей ужо адмалёўваць усё ў Grafana.
Пытанне: Ці ёсць нейкія аналагі AWR-справаздач або … агрэгацыі? Вы ведаеце пра нешта такое?
Адказ: Так, я ведаю, што такое AWR, гэта крутая штука. На дадзены момант ёсць самыя розныя веласіпеды, якія рэалізуюць прыкладна наступную мадэль. З некаторым інтэрвалам часу пішуцца некаторыя baselines у той жа самы PostgreSQL ці ў асобнае сховішча. Іх можна трошкі ў інтэрнэце, яны ёсць. Адзін з распрацоўшчыкаў такой штукі сядзіць на форуме sql.ru у галінцы PostgreSQL. Яго можна злавіць там. Так, такія штукі ёсць, іх можна выкарыстоўваць. Плюс у сваім я таксама пішу штуку, якая дазваляе рабіць тое самае.
PS1 Калі вы выкарыстоўваеце postgres_exporter, то які дашборд вы карыстаецеся? Іх тамака некалькі. Яны ўжо састарэлыя. Можа супольнасць стварыць абноўлены шаблон?
PS2 Прыбраў pganalyze, бо ёсьць афіцэрная SaaS offering which focuses on performance monitoring and automated tuning suggestions.
Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. , Калі ласка.
Які self-hosted маніторынг 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 is a proprietary 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 карыстальнікаў.
Крыніца: habr.com