{"id":56075,"date":"2020-02-04T00:00:00","date_gmt":"2020-02-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/osnovy-monitoringa-postgresql-aleksej-lesovskij"},"modified":"2020-02-18T14:04:16","modified_gmt":"2020-02-18T11:04:16","slug":"osnovy-monitoringa-postgresql-aleksej-lesovskij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"Podstawy monitorowania PostgreSQL. Olek Lesowski","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Zach\u0119cam do zapoznania si\u0119 z transkrypcj\u0105 wyk\u0142adu Alieksieja Lesowskiego z Data Egret \"Podstawy monitorowania PostgreSQL\"<\/strong><\/p>\n

<\/p>\n

W tym wyk\u0142adzie Alieksiej Lesowski om\u00f3wi kluczowe aspekty statystyki PostgreSQL, co one oznaczaj\u0105 i dlaczego powinny by\u0107 brane pod uwag\u0119 w monitorowaniu; jakie wykresy powinny by\u0107 uwzgl\u0119dnione w monitorowaniu, jak je doda\u0107 i jak je interpretowa\u0107. Wyk\u0142ad b\u0119dzie przydatny dla administrator\u00f3w baz danych, administrator\u00f3w system\u00f3w i programist\u00f3w, kt\u00f3rzy interesuj\u0105 si\u0119 rozwi\u0105zywaniem problem\u00f3w PostgreSQL.<\/p>\n

\n

\r\n \"Odtwarzaj\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Nazywam si\u0119 Aleksej Lesowski, reprezentuj\u0119 firm\u0119 Data Egret. <\/p>\n

<\/p>\n

Kilka s\u0142\u00f3w o sobie. Kiedy\u015b zaczyna\u0142em jako administrator system\u00f3w. <\/p>\n

<\/p>\n

Zarz\u0105dza\u0142em r\u00f3\u017cnorodnymi systemami Linux, zajmowa\u0142em si\u0119 r\u00f3\u017cnymi sprawami zwi\u0105zanymi z Linuxem, tj. wirtualizacj\u0105, monitoringiem, pracowa\u0142em z proxy itd. Ale w pewnym momencie zacz\u0105\u0142em po\u015bwi\u0119ca\u0107 wi\u0119cej czasu na bazy danych, PostgreSQL. Bardzo mi si\u0119 podoba\u0142. Z czasem sta\u0142em si\u0119 DBA PostgreSQL i sp\u0119dza\u0142em na tym wi\u0119kszo\u015b\u0107 swojego czasu pracy.<\/p>\n

<\/p>\n

I przez ca\u0142\u0105 swoj\u0105 karier\u0119 zawsze interesowa\u0142y mnie tematy zwi\u0105zane ze statystyk\u0105, monitoringiem i zbieraniem telemetrycznych danych. Kiedy by\u0142em administratorem system\u00f3w, pracowa\u0142em intensywnie z Zabbixem. Napisa\u0142em te\u017c niewielki zestaw skrypt\u00f3w jak zabbix-extensions<\/a><\/noindex>. By\u0142 do\u015b\u0107 popularny w swoim czasie. Dzi\u0119ki niemu mo\u017cna by\u0142o monitorowa\u0107 nie tylko r\u00f3\u017cne wa\u017cne elementy zwi\u0105zane z Linuxem, ale tak\u017ce inne komponenty.<\/p>\n

<\/p>\n

Obecnie zajmuj\u0119 si\u0119 ju\u017c PostgreSQL. Pisz\u0119 aktualnie inne narz\u0119dzie, kt\u00f3re umo\u017cliwia prac\u0119 ze statystyk\u0105 PostgreSQL. Nazywa si\u0119 pgCenter<\/a><\/noindex> (artyku\u0142 na habrze \u2014 Postgresowa statystyka bez nerw\u00f3w i stresu<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Kr\u00f3tki wst\u0119p. Jakie sytuacje zdarzaj\u0105 si\u0119 naszym klientom? Dochodzi do jakiej\u015b awarii zwi\u0105zanej z baz\u0105 danych. Gdy baza danych zostaje ju\u017c naprawiona, szef dzia\u0142u lub szef projektowania m\u00f3wi: \u201ePrzyjaciele, musimy monitorowa\u0107 baz\u0119 danych, poniewa\u017c zdarzy\u0142o si\u0119 co\u015b z\u0142ego i musimy zapobiec temu w przysz\u0142o\u015bci\u201d. I tu zaczyna si\u0119 interesuj\u0105cy proces wyboru systemu monitoringu lub dostosowywania istniej\u0105cego systemu monitoringu, aby m\u00f3c monitorowa\u0107 swoj\u0105 baz\u0119 danych \u2013 PostgreSQL, MySQL lub inne. Koledzy zaczynaj\u0105 proponowa\u0107: \u201eS\u0142ysza\u0142em, \u017ce jest taka baza danych. U\u017cyjmy jej.\u201d Koledzy zaczynaj\u0105 ze sob\u0105 dyskutowa\u0107. Ostatecznie okazuje si\u0119, \u017ce wybieramy jak\u0105\u015b baz\u0119 danych, ale monitoring PostgreSQL jest w niej s\u0142abo przedstawiony i zawsze trzeba co\u015b poprawia\u0107. Korzysta\u0107 z repozytori\u00f3w z GitHub, klonowa\u0107 je, dostosowywa\u0107 skrypty, jako\u015b konfigurowa\u0107. I ostatecznie prowadzi to do r\u0119cznej pracy. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Dlatego w tym wyk\u0142adzie postaram si\u0119 przekaza\u0107 wam pewn\u0105 wiedz\u0119 na temat tego, jak wybiera\u0107 monitoring nie tylko dla PostgreSQL, ale tak\u017ce dla baz danych. I przekaza\u0107 te informacje, kt\u00f3re pozwol\u0105 wam poprawi\u0107 wasz monitoring, aby uzyska\u0107 z niego korzy\u015bci, aby mo\u017cna by\u0142o monitorowa\u0107 swoj\u0105 baz\u0119 danych z po\u017cytkiem, aby na czas ostrzega\u0107 o nadchodz\u0105cych sytuacjach awaryjnych, kt\u00f3re mog\u0105 si\u0119 pojawi\u0107. <\/p>\n

<\/p>\n

I te pomys\u0142y, kt\u00f3re b\u0119d\u0105 w tym wyk\u0142adzie, mo\u017cna bezpo\u015brednio dostosowa\u0107 do ka\u017cdej bazy danych, czy to SQL, czy noSQL. Dlatego m\u00f3wimy tutaj nie tylko o PostgreSQL, ale tak\u017ce b\u0119dzie wiele przepis\u00f3w, jak to zrobi\u0107 w PostgreSQL. B\u0119d\u0105 przyk\u0142ady zapyta\u0144, przyk\u0142ady encji, kt\u00f3re s\u0105 w PostgreSQL do monitorowania. A je\u015bli wasza baza danych ma podobne elementy, kt\u00f3re mo\u017cna w\u0142\u0105czy\u0107 do monitoringu, r\u00f3wnie\u017c mo\u017cecie je dostosowa\u0107, doda\u0107 i b\u0119dzie dobrze.<\/p>\n

<\/p>\n

\"PodstawyNie b\u0119d\u0119 w wyk\u0142adzie
\nopowiada\u0107 o tym, jak zbiera\u0107 i przechowywa\u0107 metryki. Nie powiem nic o przetwarzaniu danych i ich udost\u0119pnianiu u\u017cytkownikowi. I nie wspomn\u0119 o alertowaniu.
\nJednak w trakcie opowiadania b\u0119d\u0119 pokazywa\u0142 r\u00f3\u017cne zrzuty ekranu istniej\u0105cych monitor\u00f3w, a tak\u017ce b\u0119d\u0119 je krytykowa\u0107. Niemniej jednak postaram si\u0119 nie wymienia\u0107 marek, aby nie tworzy\u0107 reklamy ani antyreklamy dla tych produkt\u00f3w. Wszystkie zbiegi okoliczno\u015bci s\u0105 przypadkowe i pozostaj\u0105 w sferze waszej wyobra\u017ani.
\n\"Podstawy
\nNa pocz\u0105tek wyja\u015bnijmy, czym jest monitoring. Monitoring to bardzo istotna rzecz, kt\u00f3r\u0105 nale\u017cy posiada\u0107. To wszyscy rozumiej\u0105. Jednocze\u015bnie jednak monitoring nie jest zwi\u0105zany z produktem biznesowym i nie wp\u0142ywa bezpo\u015brednio na zyski firmy, dlatego zazwyczaj po\u015bwi\u0119ca si\u0119 mu czas jako sprawie drugorz\u0119dnej. Je\u015bli mamy czas, zajmujemy si\u0119 monitoringiem, je\u015bli czasu nie ma, to OK, umie\u015bcimy to w backlogu i kiedy\u015b wr\u00f3cimy do tych zada\u0144. <\/p>\n

<\/p>\n

Z naszej praktyki wynika, \u017ce gdy przychodzimy do klient\u00f3w, monitoring cz\u0119sto jest niedopracowany i nie zawiera interesuj\u0105cych element\u00f3w, kt\u00f3re mog\u0142yby pom\u00f3c w lepszej pracy z baz\u0105 danych. Dlatego monitoring zawsze wymaga dopracowania. <\/p>\n

<\/p>\n

Bazy danych to skomplikowane rzeczy, kt\u00f3re r\u00f3wnie\u017c musz\u0105 by\u0107 monitorowane, poniewa\u017c bazy danych s\u0105 magazynem informacji. A informacje s\u0105 bardzo wa\u017cne dla firmy, nie mo\u017cna ich w \u017caden spos\u00f3b straci\u0107. Jednocze\u015bnie bazy danych to bardzo skomplikowane fragmenty oprogramowania. Sk\u0142adaj\u0105 si\u0119 z wielu komponent\u00f3w. I wiele z tych komponent\u00f3w wymaga monitorowania. <\/p>\n

<\/p>\n

\"PodstawyJe\u015bli m\u00f3wimy konkretnie o PostgreSQL, mo\u017cna go przedstawi\u0107 jako schemat sk\u0142adaj\u0105cy si\u0119 z wielu komponent\u00f3w. Te komponenty wsp\u00f3\u0142dzia\u0142aj\u0105 ze sob\u0105. Jednocze\u015bnie w PostgreSQL istnieje tzw. podsystem Stats Collector, kt\u00f3ry umo\u017cliwia zbieranie statystyk dotycz\u0105cych pracy tych podsystem\u00f3w i udost\u0119pnia pewien interfejs administratorowi lub u\u017cytkownikowi, aby m\u00f3g\u0142 przegl\u0105da\u0107 te statystyki. <\/p>\n

<\/p>\n

Te statystyki s\u0105 przedstawione jako zestaw funkcji i widok\u00f3w (view). Mo\u017cna je r\u00f3wnie\u017c nazwa\u0107 tabelkami. To znaczy, za pomoc\u0105 zwyk\u0142ego klienta psql mo\u017cna po\u0142\u0105czy\u0107 si\u0119 z baz\u0105 danych, wykona\u0107 zapytanie do tych funkcji i widok\u00f3w, i uzyska\u0107 konkretne liczby o pracy podsystem\u00f3w PostgreSQL. <\/p>\n

<\/p>\n

Mo\u017cesz doda\u0107 te liczby do swojego ulubionego systemu monitorowania, narysowa\u0107 wykresy, doda\u0107 funkcje i uzyska\u0107 analityk\u0119 w d\u0142u\u017cszym okresie czasu. <\/p>\n

<\/p>\n

W tym raporcie nie zamierzam jednak omawia\u0107 wszystkich tych funkcji, poniewa\u017c mog\u0142oby to zaj\u0105\u0107 ca\u0142y dzie\u0144. Skupi\u0119 si\u0119 dos\u0142ownie na dw\u00f3ch, trzech lub czterech aspektach, kt\u00f3re pomog\u0105 poprawi\u0107 monitorowanie.
\n\"Podstawy
\nA m\u00f3wi\u0105c o monitorowaniu bazy danych, co nale\u017cy monitorowa\u0107? Przede wszystkim dost\u0119pno\u015b\u0107, poniewa\u017c baza danych to us\u0142uga, kt\u00f3ra zapewnia dost\u0119p do danych dla klient\u00f3w, wi\u0119c musimy monitorowa\u0107 jej dost\u0119pno\u015b\u0107, a tak\u017ce pewne jako\u015bciowe i ilo\u015bciowe wska\u017aniki. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Konieczne jest r\u00f3wnie\u017c monitorowanie klient\u00f3w, kt\u00f3rzy \u0142\u0105cz\u0105 si\u0119 z nasz\u0105 baz\u0105 danych, poniewa\u017c mog\u0105 to by\u0107 zar\u00f3wno normalni klienci, jak i szkodliwi klienci, kt\u00f3rzy mog\u0105 zaszkodzi\u0107 bazie danych. Musimy ich tak\u017ce monitorowa\u0107 i \u015bledzi\u0107 ich aktywno\u015b\u0107.<\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Kiedy klienci \u0142\u0105cz\u0105 si\u0119 z baz\u0105 danych, oczywi\u015bcie zaczynaj\u0105 pracowa\u0107 z naszymi danymi, dlatego musimy monitorowa\u0107 r\u00f3wnie\u017c to, jak klienci pracuj\u0105 z danymi: z jakimi tabelami, w mniejszym stopniu z jakimi indeksami. Musimy oceni\u0107 obci\u0105\u017cenie (workload), kt\u00f3re generuj\u0105 nasi klienci.<\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Obci\u0105\u017cenie sk\u0142ada si\u0119 oczywi\u015bcie z zapyta\u0144. Aplikacje \u0142\u0105cz\u0105 si\u0119 z baz\u0105 danych i odwo\u0142uj\u0105 si\u0119 do danych za pomoc\u0105 zapyta\u0144, dlatego wa\u017cne jest, aby ocenia\u0107, jakie zapytania s\u0105 w naszej bazie danych, monitorowa\u0107 ich adekwatno\u015b\u0107, zapewnia\u0107, \u017ce nie s\u0105 \u017ale napisane, oraz sprawdza\u0107, czy niekt\u00f3re opcje nale\u017cy przepis na szybciej dzia\u0142aj\u0105ce i bardziej wydajne. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

A skoro m\u00f3wimy o bazie danych, to zawsze s\u0105 to procesy w tle. Procesy w tle pozwalaj\u0105 utrzyma\u0107 wydajno\u015b\u0107 bazy danych na odpowiednim poziomie, dlatego potrzebuj\u0105 pewnej ilo\u015bci zasob\u00f3w do dzia\u0142ania. Jednocze\u015bnie mog\u0105 kolidowa\u0107 z zasobami zapyta\u0144 od klient\u00f3w, dlatego intensywna praca proces\u00f3w w tle mo\u017ce bezpo\u015brednio wp\u0142ywa\u0107 na wydajno\u015b\u0107 zapyta\u0144 od klient\u00f3w. Musimy je r\u00f3wnie\u017c monitorowa\u0107 i sprawdza\u0107, czy nie ma nadmiernych obci\u0105\u017ce\u0144 zwi\u0105zanych z procesami w tle. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

A wszystko to w planie monitorowania bazy danych pozostaje w metrykach systemowych. Jednak bior\u0105c pod uwag\u0119, \u017ce w przewa\u017caj\u0105cej cz\u0119\u015bci ca\u0142a infrastruktura przenosi si\u0119 do chmur, metryki systemowe pojedynczego hosta zawsze schodz\u0105 na drugi plan. Niemniej jednak w bazach danych wci\u0105\u017c maj\u0105 znaczenie, a monitorowanie metryk systemowych r\u00f3wnie\u017c jest konieczne. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Z metrykami systemowymi w miar\u0119 wszystko jest w porz\u0105dku, wszystkie nowoczesne systemy monitorowania ju\u017c je wspieraj\u0105, ale og\u00f3lnie wci\u0105\u017c brakuje kilku komponent\u00f3w, kt\u00f3re nale\u017cy doda\u0107. O nich r\u00f3wnie\u017c wspomn\u0119, kilka slajd\u00f3w b\u0119dzie po\u015bwi\u0119conych temu tematowi. <\/p>\n

<\/p>\n

\"Podstawy
\nPierwszy punkt planu \u2013 to dost\u0119pno\u015b\u0107. Co to jest dost\u0119pno\u015b\u0107? Dost\u0119pno\u015b\u0107 w moim przekonaniu \u2013 to zdolno\u015b\u0107 bazy do obs\u0142ugi po\u0142\u0105cze\u0144, tzn. baza jest uruchomiona, jako us\u0142uga przyjmuje po\u0142\u0105czenia od klient\u00f3w. T\u0119 dost\u0119pno\u015b\u0107 mo\u017cna ocenia\u0107 pewnymi charakterystykami. Te charakterystyki bardzo wygodnie si\u0119 przedstawia na dashboardach. <\/p>\n

<\/p>\n

\"Podstawy
\nWszyscy wiedz\u0105, co to s\u0105 dashboardy. To, kiedy rzucasz okiem na ekran, na kt\u00f3rym zebrane s\u0105 potrzebne informacje. I od razu mo\u017cesz stwierdzi\u0107 \u2013 czy w bazie jest problem, czy nie.
\nOdpowiednio dost\u0119pno\u015b\u0107 bazy danych i inne kluczowe charakterystyki zawsze nale\u017cy przedstawia\u0107 na dashboardach, aby ta informacja by\u0142a pod r\u0119k\u0105, aby\u015b mia\u0142 j\u0105 zawsze w zasi\u0119gu r\u0119ki. Jakie\u015b dodatkowe szczeg\u00f3\u0142y, kt\u00f3re ju\u017c pomagaj\u0105 w dochodzeniach incydent\u00f3w lub badaniach sytuacji awaryjnych, nale\u017cy ju\u017c przedstawia\u0107 na wt\u00f3rnych dashboardach lub ukrywa\u0107 w linkach drilldown, kt\u00f3re prowadz\u0105 do zewn\u0119trznych system\u00f3w monitorowania. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Przyk\u0142ad jednego znanej systemu monitorowania. To bardzo \u015bwietny system monitorowania. Zbiera bardzo du\u017co danych, ale z mojego punktu widzenia ma dziwne poj\u0119cie dashboard\u00f3w. Jest tam link \u201estw\u00f3rz dashboard\u201d. Ale gdy tworzysz dashboard, tworzysz pewien wykaz sk\u0142adaj\u0105cy si\u0119 z dw\u00f3ch kolumn, pewien wykaz wykres\u00f3w. I kiedy musisz co\u015b zobaczy\u0107, zaczynasz klika\u0107 myszk\u0105, przewija\u0107, szuka\u0107 potrzebnego wykresu. I zajmuje to czas, tzn. w\u0142a\u015bciwie nie ma dashboard\u00f3w. S\u0105 tylko wykazy wykres\u00f3w.<\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Co nale\u017cy doda\u0107 do tych pulpit\u00f3w? Mo\u017cna zacz\u0105\u0107 od takiej charakterystyki jak czas odpowiedzi. W PostgreSQL istnieje widok pg_stat_statements. Domy\u015blnie jest on wy\u0142\u0105czony, ale jest to jeden z wa\u017cnych widok\u00f3w systemowych, kt\u00f3ry zawsze powinno si\u0119 w\u0142\u0105cza\u0107 i u\u017cywa\u0107. Przechowuje on informacje o wszystkich wykonanych zapytaniach, kt\u00f3re zosta\u0142y zrealizowane w bazie danych. <\/p>\n

<\/p>\n

W zwi\u0105zku z tym mo\u017cemy zacz\u0105\u0107 od tego, \u017ce mo\u017cna wzi\u0105\u0107 \u0142\u0105czny czas wykonania wszystkich zapyta\u0144 i podzieli\u0107 go przez liczb\u0119 zapyta\u0144 za pomoc\u0105 wy\u017cej wymienionych p\u00f3l. Ale to tylko \u015brednia temperatura w szpitalu. Mo\u017cemy odnosi\u0107 si\u0119 do innych p\u00f3l \u2013 minimalnego czasu wykonania zapyta\u0144, maksymalnego i mediany. A nawet mo\u017cemy zbudowa\u0107 percentyle, w PostgreSQL s\u0105 odpowiednie funkcje do tego. Dzi\u0119ki temu mo\u017cemy uzyska\u0107 jakie\u015b liczby, kt\u00f3re charakteryzuj\u0105 czas reakcji naszej bazy na ju\u017c wykonane zapytania, to znaczy nie wykonujemy fa\u0142szywego zapytania 'select 1' i nie sprawdzamy czasu reakcji, a analizujemy czasy odpowiedzi dla ju\u017c wykonanych zapyta\u0144 i przedstawiamy to jako pojedyncz\u0105 liczb\u0119 lub rysujemy wykres. <\/p>\n

<\/p>\n

R\u00f3wnie\u017c wa\u017cne jest monitorowanie liczby b\u0142\u0119d\u00f3w generowanych przez system w danym momencie. I do tego mo\u017cna u\u017cy\u0107 widoku pg_stat_database. Oryginalnie kierujemy si\u0119 polem xact_rollback. To pole pokazuje nie tylko liczb\u0119 rollback\u00f3w, kt\u00f3re maj\u0105 miejsce w bazie, ale tak\u017ce uwzgl\u0119dnia liczb\u0119 b\u0142\u0119d\u00f3w. M\u00f3wi\u0105c kr\u00f3tko, mo\u017cemy wyprowadzi\u0107 t\u0119 liczb\u0119 na nasz pulpit i zobaczy\u0107, ile mamy b\u0142\u0119d\u00f3w w danym momencie. Je\u015bli b\u0142\u0119d\u00f3w jest du\u017co, to ju\u017c dobry pow\u00f3d, aby zajrze\u0107 do log\u00f3w i sprawdzi\u0107, co to s\u0105 za b\u0142\u0119dy i dlaczego wyst\u0119puj\u0105, a dalej ju\u017c prowadzi\u0107 dochodzenie i je rozwi\u0105zywa\u0107.<\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Mo\u017cna doda\u0107 takie co\u015b jak Tachometr. To liczba transakcji na sekund\u0119 oraz liczba zapyta\u0144 na sekund\u0119. M\u00f3wi\u0105c inaczej, mo\u017cesz u\u017cywa\u0107 tych cyfr jako aktualnej wydajno\u015bci swojej bazy danych i obserwowa\u0107, czy s\u0105 szczyty zapyta\u0144, szczyty transakcji, czy przeciwnie, baza nie jest obci\u0105\u017cona, poniewa\u017c jaki\u015b backend si\u0119 wy\u0142\u0105czy\u0142. T\u0119 liczb\u0119 wa\u017cne jest zawsze obserwowa\u0107 i pami\u0119ta\u0107, \u017ce dla naszego projektu taka wydajno\u015b\u0107 jest normalna, a warto\u015bci wy\u017csze lub ni\u017csze s\u0105 ju\u017c jakie\u015b problematyczne i niezrozumia\u0142e, a wi\u0119c nale\u017cy sprawdzi\u0107, dlaczego s\u0105 takie liczby.<\/p>\n

<\/p>\n

Aby oceni\u0107 liczb\u0119 transakcji, mo\u017cemy ponownie skorzysta\u0107 z widoku pg_stat_database. Mo\u017cemy zsumowa\u0107 liczb\u0119 commit\u00f3w i liczb\u0119 rollback\u00f3w, aby uzyska\u0107 liczb\u0119 transakcji na sekund\u0119. <\/p>\n

<\/p>\n

Wszyscy rozumiej\u0105, \u017ce w jedn\u0105 transakcj\u0119 mo\u017ce zmie\u015bci\u0107 si\u0119 kilka zapyta\u0144? Dlatego TPS i QPS s\u0105 nieco r\u00f3\u017cne. <\/p>\n

<\/p>\n

Liczb\u0119 zapyta\u0144 na sekund\u0119 mo\u017cna uzyska\u0107 z pg_stat_statements, po prostu sumuj\u0105c wszystkie wykonane zapytania. Oczywi\u015bcie por\u00f3wnujemy bie\u017c\u0105c\u0105 warto\u015b\u0107 z poprzedni\u0105, odejmujemy, uzyskujemy r\u00f3\u017cnic\u0119, otrzymujemy liczb\u0119.<\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Mo\u017cna doda\u0107 dodatkowe metryki wed\u0142ug uznania, kt\u00f3re r\u00f3wnie\u017c pomagaj\u0105 oceni\u0107 dost\u0119pno\u015b\u0107 naszej bazy i \u015bledzi\u0107, czy nie by\u0142o jakichkolwiek przestoj\u00f3w. <\/p>\n

<\/p>\n

Jedn\u0105 z tych metryk jest uptime. Jednak uptime w PostgreSQL to nieco skomplikowana sprawa. Opowiem, dlaczego. Kiedy PostgreSQL jest uruchomiony, zaczyna si\u0119 liczy\u0107 uptime. Ale je\u015bli w pewnym momencie, na przyk\u0142ad w nocy, wykonywana by\u0142a jaka\u015b zadanie, a OOM-killer wymusi\u0142 zako\u0144czenie procesu potomnego PostgreSQL, to w takim przypadku PostgreSQL ko\u0144czy po\u0142\u0105czenie wszystkich klient\u00f3w, resetuje obszar pami\u0119ci sharded i zaczyna przywracanie od ostatniego punktu kontrolnego. I podczas gdy trwa to przywracanie, baza nie akceptuje po\u0142\u0105cze\u0144, czyli t\u0119 sytuacj\u0119 mo\u017cna oceni\u0107 jako downtime. Jednak licznik uptime si\u0119 nie zresetuje, poniewa\u017c uwzgl\u0119dnia czas uruchomienia postmastera od momentu pierwszego uruchomienia. Dlatego takie sytuacje mog\u0105 zosta\u0107 pomini\u0119te.<\/p>\n

<\/p>\n

Nale\u017cy r\u00f3wnie\u017c monitorowa\u0107 liczb\u0119 pracownik\u00f3w autovacuum. Czy wszyscy wiedz\u0105, co to jest autovacuum w PostgreSQL? To interesuj\u0105cy podsystem w PostgreSQL. Napisano o nim wiele artyku\u0142\u00f3w, wyg\u0142oszono wiele prezentacji. Jest wiele dyskusji na temat vacuum, jak powinno dzia\u0142a\u0107. Wielu uwa\u017ca go za nieuchronne z\u0142o. Ale tak jest. To pewien odpowiednik zbieracza \u015bmieci, kt\u00f3ry czy\u015bci przestarza\u0142e wersje wierszy, kt\u00f3re nie s\u0105 potrzebne \u017cadnej transakcji i zwalnia miejsce w tabelach, indeksach na nowe wiersze. <\/p>\n

<\/p>\n

Dlaczego nale\u017cy go monitorowa\u0107? Poniewa\u017c vacuum czasami powoduje powa\u017cne problemy. Zajmuje du\u017c\u0105 ilo\u015b\u0107 zasob\u00f3w, a na tym cierpi\u0105 zapytania klient\u00f3w. <\/p>\n

<\/p>\n

Monitorowanie powinno odbywa\u0107 si\u0119 za pomoc\u0105 widoku pg_stat_activity, o kt\u00f3rym b\u0119d\u0119 m\u00f3wi\u0107 w nast\u0119pnej sekcji. Ten widok pokazuje bie\u017c\u0105c\u0105 aktywno\u015b\u0107 w bazie danych. Dzi\u0119ki tej aktywno\u015bci mo\u017cemy \u015bledzi\u0107 liczb\u0119 proces\u00f3w vacuum, kt\u00f3re s\u0105 aktualnie uruchomione. Mo\u017cemy monitorowa\u0107 procesy vacuum i dostrzega\u0107, \u017ce je\u015bli przekroczony zostanie limit, to jest to pow\u00f3d, aby zajrze\u0107 do ustawie\u0144 PostgreSQL i zoptymalizowa\u0107 dzia\u0142anie vacuum. <\/p>\n

<\/p>\n

Inn\u0105 cech\u0105 PostgreSQL jest to, \u017ce bardzo \u017ale znosi d\u0142ugie transakcje, zw\u0142aszcza te, kt\u00f3re d\u0142ugo wisz\u0105 i nic nie robi\u0105. To tak zwane stat idle-in-transaction. Taka transakcja utrzymuje blokady, co uniemo\u017cliwia dzia\u0142anie vacuum. W rezultacie tabele puchn\u0105, zwi\u0119kszaj\u0105 sw\u00f3j rozmiar. A zapytania, kt\u00f3re dzia\u0142aj\u0105 na tych tabelach, zaczynaj\u0105 dzia\u0142a\u0107 wolniej, poniewa\u017c musz\u0105 przeszukiwa\u0107 wszystkie stare wersje wierszy z pami\u0119ci na dysk i z powrotem.<\/strong> Dlatego nale\u017cy monitorowa\u0107 czas trwania najd\u0142u\u017cszych transakcji oraz najd\u0142u\u017cszych zapyta\u0144 vacuum. Je\u015bli widzimy jakie\u015b procesy, kt\u00f3re dzia\u0142aj\u0105 ju\u017c bardzo d\u0142ugo, przekraczaj\u0105c 10-20-30 minut w obci\u0105\u017ceniu OLTP, wtedy nale\u017cy na nie zwr\u00f3ci\u0107 uwag\u0119 i zako\u0144czy\u0107 je wymuszone, lub zoptymalizowa\u0107 aplikacj\u0119, aby nie by\u0142y wywo\u0142ywane i nie wisia\u0142y tak d\u0142ugo.<\/strong> Dla obci\u0105\u017cenia analitycznego 10-20-30 minut to norma, zdarzaj\u0105 si\u0119 tak\u017ce d\u0142u\u017csze. <\/p>\n

<\/p>\n

\"Podstawy
\nKolejnym elementem s\u0105 pod\u0142\u0105czeni klienci. Gdy ju\u017c utworzyli\u015bmy dashboard i wy\u015bwietlili\u015bmy na nim kluczowe metryki dost\u0119pno\u015bci, mo\u017cemy tak\u017ce doda\u0107 dodatkowe informacje o pod\u0142\u0105czonych klientach. <\/p>\n

<\/p>\n

Informacja o pod\u0142\u0105czonych klientach jest wa\u017cna, poniewa\u017c z perspektywy PostgreSQL klienci s\u0105 r\u00f3\u017cni. S\u0105 dobrzy klienci i \u017ali klienci. <\/p>\n

<\/p>\n

Przyk\u0142ad. Pod klientem rozumiem aplikacj\u0119. Aplikacja po\u0142\u0105czy\u0142a si\u0119 z baz\u0105 danych i zaczyna natychmiast wysy\u0142a\u0107 do niej swoje zapytania, baza danych je przetwarza i wykonuje, a wyniki zwraca klientowi. To s\u0105 dobrzy i prawid\u0142owi klienci. <\/p>\n

<\/p>\n

Zdarzaj\u0105 si\u0119 sytuacje, kiedy klient si\u0119 pod\u0142\u0105czy\u0142, trzyma po\u0142\u0105czenie, ale nic nie robi. Znajduje si\u0119 w stanie idle. <\/p>\n

<\/p>\n

Jednak bywaj\u0105 z\u0142e po\u0142\u0105czenia. Na przyk\u0142ad, ten sam klient po\u0142\u0105czy\u0142 si\u0119, otworzy\u0142 transakcj\u0119, co\u015b zrobi\u0142 w bazie, a potem przeszed\u0142 do kodu, powiedzmy, aby odwo\u0142a\u0107 si\u0119 do zewn\u0119trznego \u017ar\u00f3d\u0142a lub w celu przetworzenia otrzymanych danych. Ale nie zamkn\u0105\u0142 transakcji. I transakcja wisi w bazie, blokuj\u0105c wiersz. To z\u0142a sytuacja. A je\u015bli nagle aplikacja wewn\u0119trznie padnie z wyj\u0105tkiem (Exception), to transakcja mo\u017ce zosta\u0107 otwarta na bardzo d\u0142ugi czas. I to bezpo\u015brednio wp\u0142ywa na wydajno\u015b\u0107 PostgreSQL. PostgreSQL b\u0119dzie dzia\u0142a\u0142 wolniej. Dlatego takich klient\u00f3w wa\u017cne jest, aby na czas \u015bledzi\u0107 i wymusza\u0107 zako\u0144czenie ich pracy. Nale\u017cy r\u00f3wnie\u017c optymalizowa\u0107 swoje aplikacje, aby takich sytuacji unika\u0107. <\/p>\n

<\/p>\n

Innymi z\u0142ymi klientami s\u0105 klienci oczekuj\u0105cy. Staj\u0105 si\u0119 z\u0142ymi z powodu okoliczno\u015bci. Na przyk\u0142ad, zwyk\u0142a wisz\u0105ca transakcja: mo\u017ce otworzy\u0107 transakcj\u0119, zablokowa\u0107 niekt\u00f3re wiersze, a potem gdzie\u015b w kodzie zgin\u0105\u0107, pozostawiaj\u0105c wisz\u0105c\u0105 transakcj\u0119. Przyjdzie inny klient, za\u017c\u0105da tych samych danych, ale napotka blokad\u0119, poniewa\u017c ta wisz\u0105ca transakcja ju\u017c trzyma blokady na potrzebnych wierszach. I druga transakcja b\u0119dzie wisia\u0142a w oczekiwaniu na zako\u0144czenie pierwszej transakcji lub wymuszone zamkni\u0119cie przez administratora. Tak wi\u0119c, transakcje oczekuj\u0105ce mog\u0105 si\u0119 gromadzi\u0107 i przekracza\u0107 limit po\u0142\u0105cze\u0144 z baz\u0105 danych. A kiedy limit jest przekroczony, aplikacja nie mo\u017ce ju\u017c dzia\u0142a\u0107 z baz\u0105. To ju\u017c sytuacja awaryjna dla projektu. Dlatego z\u0142e klient\u00f3w nale\u017cy \u015bledzi\u0107 i odpowiednio reagowa\u0107. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Inny przyk\u0142ad monitoringu. I tutaj ju\u017c elegancki dashboard. Informacje o po\u0142\u0105czeniach s\u0105 na g\u00f3rze. Po\u0142\u0105czenie DB \u2013 8 sztuk. I to wszystko. Nie mamy informacji o tym, kt\u00f3rzy klienci s\u0105 aktywni, kt\u00f3rzy klienci s\u0105 po prostu bezczynni, nic nie robi\u0105. Nie ma informacji o wisz\u0105cych transakcjach i oczekuj\u0105cych po\u0142\u0105czeniach, tzn. to taka liczba, kt\u00f3ra pokazuje liczb\u0119 po\u0142\u0105cze\u0144 i tyle. A dalej zgadujcie sami.
\n\"Podstawy
\nAby doda\u0107 te informacje do monitorowania, nale\u017cy zwr\u00f3ci\u0107 si\u0119 do widoku pg_stat_activity. Je\u015bli sp\u0119dzasz du\u017co czasu w PostgreSQL, to jest to bardzo przydatny widok, kt\u00f3ry powinien sta\u0107 si\u0119 Twoim przyjacielem, poniewa\u017c pokazuje aktualn\u0105 aktywno\u015b\u0107 w PostgreSQL, tzn. co si\u0119 w nim dzieje. Dla ka\u017cdego procesu istnieje osobny wiersz, kt\u00f3ry pokazuje informacje na temat tego procesu: z jakiego hosta wykonano po\u0142\u0105czenie, pod jakim u\u017cytkownikiem, jakim imieniem, kiedy uruchomiono transakcj\u0119, jaki jest aktualnie wykonywany zapytanie oraz jakie zapytanie by\u0142o wykonywane ostatnio. W zwi\u0105zku z tym, stan klienta mo\u017cemy ocenia\u0107 na podstawie pola stat. Mo\u017cemy grupowa\u0107 wed\u0142ug tego pola i uzyska\u0107 statystyki, kt\u00f3re obecnie znajduj\u0105 si\u0119 w bazie danych oraz liczb\u0119 po\u0142\u0105cze\u0144 zwi\u0105zanych z t\u0105 statystyk\u0105 w bazie danych. Otrzymane liczby mo\u017cemy wysy\u0142a\u0107 do naszego monitorowania i na ich podstawie rysowa\u0107 wykresy.
\nR\u00f3wnie\u017c wa\u017cne jest, aby ocenia\u0107 czas trwania transakcji. Ju\u017c m\u00f3wi\u0142em, \u017ce wa\u017cne jest ocenianie czasu trwania vacuum\u00f3w, ale transakcje r\u00f3wnie\u017c ocenia si\u0119 w ten sam spos\u00f3b. S\u0105 pola xact_start i query_start, kt\u00f3re pokazuj\u0105 czas rozpocz\u0119cia transakcji i czas rozpocz\u0119cia zapytania. U\u017cywamy funkcji now(), kt\u00f3ra pokazuje aktualny znacznik czasu i odejmujemy timestamp transakcji i zapytania. Otrzymujemy czas trwania transakcji oraz czas trwania zapytania. <\/p>\n

<\/p>\n

Je\u015bli widzimy d\u0142ugie transakcje, powinni\u015bmy je zako\u0144czy\u0107. Dla obci\u0105\u017cenia OLTP, d\u0142ugie transakcje to te trwaj\u0105ce d\u0142u\u017cej ni\u017c 1-2-3 minuty.<\/strong>. Dla obci\u0105\u017cenia OLAP, d\u0142ugie transakcje s\u0105 norm\u0105, ale je\u015bli trwaj\u0105 d\u0142u\u017cej ni\u017c dwie godziny, to jest to r\u00f3wnie\u017c oznak\u0105, \u017ce gdzie\u015b mamy zanikanie.<\/strong> <\/p>\n

<\/p>\n

\"Podstawy
\nKiedy klienci po\u0142\u0105cz\u0105 si\u0119 z baz\u0105 danych, zaczynaj\u0105 pracowa\u0107 z naszymi danymi. Odnosz\u0105 si\u0119 do tabel, odnosz\u0105 si\u0119 do indeks\u00f3w, aby uzyska\u0107 dane z tabel. Wa\u017cne jest, aby ocenia\u0107 to, jak klienci pracuj\u0105 z tymi danymi.<\/p>\n

<\/p>\n

To assess our workload and understand which tables are the most 'hot'. For instance, this is necessary when we want to place 'hot' tables on fast SSD storage. Archive tables that we no longer use can be moved to a 'cold' archive on SATA drives, allowing them to reside there, with access occurring only as needed. <\/p>\n

<\/p>\n

It is also useful for detecting anomalies after various releases and deployments. Suppose the project rolls out a new feature. For example, they added new functionality for working with the database. By building graphs of table usage, we can easily spot these anomalies, such as spikes in updates or deletions. This will be very evident.<\/p>\n

<\/p>\n

Anomalies in 'drifted' statistics can also be detected. What does this mean? PostgreSQL has a very powerful query planner. Developers dedicate a lot of time to its development. How does it work? To create good plans, PostgreSQL collects statistics about data distribution in tables at regular intervals. This includes common values: the count of unique values, information about NULLs in the table, and much more. <\/p>\n

<\/p>\n

Based on this statistics, the planner builds several queries, selects the most optimal one, and uses this query plan for executing the query and returning data. <\/p>\n

<\/p>\n

Sometimes, the statistics can 'drift'. The quality and quantity of data in the table might have changed, but statistics have not been updated. This can result in suboptimal plans being generated. If our plans become suboptimal based on the collected monitoring data for tables, we can see these anomalies. For example, where data quality has changed, and instead of using the index, a sequential scan of the table is performed, meaning if a query needs to return just 100 rows (with a limit of 100), a full scan will be executed instead. This always negatively impacts performance. <\/p>\n

<\/p>\n

I b\u0119dziemy mogli to zobaczy\u0107 w monitoringu. Mo\u017cemy ju\u017c spojrze\u0107 na to zapytanie, wykona\u0107 dla niego explain, zebra\u0107 statystyki, stworzy\u0107 nowy dodatkowy indeks. I zareagowa\u0107 na ten problem. Dlatego to wa\u017cne. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Inny przyk\u0142ad monitorowania. My\u015bl\u0119, \u017ce wiele os\u00f3b go rozpozna, poniewa\u017c jest bardzo popularny. Kto u\u017cywa go w swoich projektach Prometheus<\/a><\/noindex>? \u0410 \u043a\u0442\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 \u044d\u0442\u043e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e \u0441 Prometheus? \u0414\u0435\u043b\u043e \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u0432 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u043e\u043c \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438 \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0435\u0441\u0442\u044c \u0434\u0430\u0448\u0431\u043e\u0440\u0434 \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441 PostgreSQL \u2013 postgres_exporter<\/a><\/noindex> Prometheus. Ale jest jeden z\u0142y szczeg\u00f3\u0142. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Jest kilka wykres\u00f3w. A jako jednostka podano bajty, tj. jest 5 wykres\u00f3w. To Insert data, Update data, Delete data, Fetch data i Return data. Jako jednostka miary podano bajty. Problem w tym, \u017ce statystyki w PostgreSQL zwracaj\u0105 dane w krotkach (tuplach). A te wykresy to bardzo dobry spos\u00f3b na zani\u017cenie obci\u0105\u017cenia roboczego wielokrotnie, poniewa\u017c krotka to nie bajt, krotka to wiersz, to wiele bajt\u00f3w i zawsze ma zmienn\u0105 d\u0142ugo\u015b\u0107. Tzn. obliczenie obci\u0105\u017cenia roboczego w bajtach za pomoc\u0105 krotek to nierealne zadanie lub bardzo trudne. Dlatego, gdy u\u017cywasz dashboardu lub wbudowanego monitorowania, zawsze wa\u017cne jest, aby zrozumie\u0107, \u017ce dzia\u0142a on poprawnie i zwraca ci poprawnie ocenione dane. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Jak uzyska\u0107 statystyki dla tych tabel? W tym celu PostgreSQL ma pewn\u0105 rodzin\u0119 widok\u00f3w. A g\u0142\u00f3wny widok to pg_stat_user_tables<\/a><\/noindex>. User_tables \u2013 oznacza to, \u017ce tabele zosta\u0142y stworzone z perspektywy u\u017cytkownika. W przeciwie\u0144stwie do tego s\u0105 systemowe widoki, kt\u00f3re s\u0105 u\u017cywane przez sam PostgreSQL. I jest podsumowuj\u0105ca tabela Alltables, kt\u00f3ra obejmuje zar\u00f3wno systemowe, jak i u\u017cytkowe. Mo\u017cesz si\u0119 opiera\u0107 na dowolnej z nich, kt\u00f3ra ci najbardziej odpowiada.<\/p>\n

<\/p>\n

Na podstawie powy\u017cszych p\u00f3l mo\u017cna oceni\u0107 liczb\u0119 insert, update i delete. Ten przyk\u0142ad dashboardu, kt\u00f3ry u\u017cy\u0142em, dok\u0142adnie wykorzystuje te pola do oceny charakterystyk obci\u0105\u017cenia roboczego. Dlatego mo\u017cemy tak\u017ce si\u0119 na nich opiera\u0107. Ale warto pami\u0119ta\u0107, \u017ce to krotki, a nie bajty, wi\u0119c nie mo\u017cemy po prostu przekszta\u0142ci\u0107 ich w bajty.<\/p>\n

<\/p>\n

Na podstawie tych danych mo\u017cemy budowa\u0107 tzw. tabele TopN. Na przyk\u0142ad, Top-5, Top-10. I mo\u017cemy \u015bledzi\u0107 te gor\u0105ce tabele, kt\u00f3re s\u0105 u\u017cywane cz\u0119\u015bciej ni\u017c inne. Na przyk\u0142ad, 5 \u201egor\u0105cych\u201d tabel pod k\u0105tem wstawiania. I na podstawie tych tabel TopN oceniamy nasze obci\u0105\u017cenie robocze i mo\u017cemy ocenia\u0107 wzrosty obci\u0105\u017cenia roboczego po r\u00f3\u017cnych wydaniach, aktualizacjach i wdro\u017ceniach. <\/p>\n

<\/p>\n

R\u00f3wnie\u017c wa\u017cne jest ocenianie rozmiar\u00f3w tabel, poniewa\u017c czasami deweloperzy wdra\u017caj\u0105 now\u0105 funkcjonalno\u015b\u0107, co prowadzi do tego, \u017ce nasze tabele zaczynaj\u0105 puchn\u0105\u0107, poniewa\u017c postanowili doda\u0107 dodatkow\u0105 ilo\u015b\u0107 danych, nie przewiduj\u0105c, jak wp\u0142ynie to na rozmiar bazy danych. Takie przypadki r\u00f3wnie\u017c bywaj\u0105 dla nas niespodziankami. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

A teraz mam do was ma\u0142e pytanie. Jaki pytanie pojawia si\u0119, gdy zauwa\u017cacie obci\u0105\u017cenie serwera z baz\u0105 danych? Jakie jest nast\u0119pne pytanie, kt\u00f3re przychodzi wam do g\u0142owy? <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Ale w rzeczywisto\u015bci pojawia si\u0119 nast\u0119pne pytanie. Jakie zapytania powoduj\u0105 obci\u0105\u017cenie? Tzn. nie jest interesuj\u0105ce patrze\u0107 na procesy, kt\u00f3re generuj\u0105 obci\u0105\u017cenie. Jasne, \u017ce je\u015bli hostuje baz\u0119 danych, to tam dzia\u0142a baza danych i wiadomo, \u017ce tylko bazy danych b\u0119d\u0105 obci\u0105\u017ca\u0107. Je\u015bli otworzymy Top, zobaczymy tam list\u0119 proces\u00f3w w PostgreSQL, kt\u00f3re co\u015b robi\u0105. Z Top nie b\u0119dzie wiadomo, co one robi\u0105. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

W zwi\u0105zku z tym konieczne jest wykrycie tych zapyta\u0144, kt\u00f3re powoduj\u0105 najwi\u0119ksze obci\u0105\u017cenie, poniewa\u017c tuning zapyta\u0144 zazwyczaj przynosi wi\u0119cej korzy\u015bci ni\u017c tuning konfiguracji PostgreSQL czy systemu operacyjnego, a nawet tuning sprz\u0119tu. Moim zdaniem to oko\u0142o 80-85-90%. I dzieje si\u0119 to znacznie szybciej. \u0141atwiej jest poprawi\u0107 zapytanie, ni\u017c poprawi\u0107 konfiguracj\u0119, zaplanowa\u0107 restart, szczeg\u00f3lnie je\u015bli bazy nie mo\u017cna restartowa\u0107, albo dodawa\u0107 sprz\u0119tu. Warto przeorganizowa\u0107 zapytanie lub doda\u0107 indeks, aby uzyska\u0107 lepszy wynik z tego zapytania. <\/p>\n

<\/p>\n

\"Podstawy
\nW zwi\u0105zku z tym nale\u017cy monitorowa\u0107 zapytania i ich adekwatno\u015b\u0107. We\u017amy inny przyk\u0142ad monitoringu. I tutaj r\u00f3wnie\u017c wygl\u0105da to na doskona\u0142y monitoring. S\u0105 informacje na temat replikacji, informacje o przepustowo\u015bci, blokadach, wykorzystaniu zasob\u00f3w. Wszystko w porz\u0105dku, ale brakuje informacji o zapytaniach. Nie wiadomo, jakie zapytania s\u0105 wykonywane w naszej bazie danych, jak d\u0142ugo one trwaj\u0105, ile tych zapyta\u0144. Musimy zawsze mie\u0107 te informacje w monitoringu. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Aby uzyska\u0107 te informacje, mo\u017cemy u\u017cy\u0107 modu\u0142u pg_stat_statements. Na jego podstawie mo\u017cna tworzy\u0107 r\u00f3\u017cne wykresy. Na przyk\u0142ad, mo\u017cemy uzyska\u0107 informacje na temat najcz\u0119\u015bciej wykonywanych zapyta\u0144, czyli tych, kt\u00f3re s\u0105 wykonywane najcz\u0119\u015bciej. Tak, po wdro\u017ceniach r\u00f3wnie\u017c bardzo przydatne jest spojrzenie na to i zrozumienie, czy nie ma jakiego\u015b wzrostu liczby zapyta\u0144. <\/p>\n

<\/p>\n

Mo\u017cemy monitorowa\u0107 najd\u0142u\u017cej wykonywane zapytania, czyli te, kt\u00f3re trwaj\u0105 najd\u0142u\u017cej. Obci\u0105\u017caj\u0105 one procesor i zu\u017cywaj\u0105 operacje wej\u015bcia\/wyj\u015bcia. Mo\u017cemy to oceni\u0107 na podstawie p\u00f3l total_time, mean_time, blk_write_time i blk_read_time. <\/p>\n

<\/p>\n

Mo\u017cemy ocenia\u0107 i monitorowa\u0107 najci\u0119\u017csze zapytania pod wzgl\u0119dem wykorzystania zasob\u00f3w, te, kt\u00f3re odczytuj\u0105 dane z dysku, kt\u00f3re dzia\u0142aj\u0105 z pami\u0119ci\u0105 lub, przeciwnie, generuj\u0105 obci\u0105\u017cenie zapisu.<\/p>\n

<\/p>\n

Mo\u017cemy ocenia\u0107 najhojniejsze zapytania. To s\u0105 te zapytania, kt\u00f3re zwracaj\u0105 du\u017c\u0105 liczb\u0119 wierszy. Na przyk\u0142ad, mo\u017ce to by\u0107 zapytanie, w kt\u00f3rym zapomniano ustawi\u0107 limit. I po prostu zwraca ca\u0142e dane z tabeli lub zapytania dotycz\u0105ce za\u017c\u0105danych tabel.<\/p>\n

<\/p>\n

Mo\u017cemy r\u00f3wnie\u017c monitorowa\u0107 zapytania, kt\u00f3re korzystaj\u0105 z plik\u00f3w tymczasowych lub tabel tymczasowych. <\/p>\n

<\/p>\n

\"Podstawy
\nZosta\u0142y nam procesy w tle. Procesy w tle to przede wszystkim punkty kontrolne, zwane r\u00f3wnie\u017c checkpointami, autovacuum i replikacja. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Inny przyk\u0142ad monitorowania. Po lewej stronie jest zak\u0142adka Maintenance, przechodzimy do niej i mamy nadziej\u0119 zobaczy\u0107 co\u015b przydatnego. Ale tutaj s\u0105 tylko czasy dzia\u0142ania procesu vacuum i zbierania statystyk, nic wi\u0119cej. To bardzo uboga informacja, wi\u0119c zawsze musimy mie\u0107 informacje o tym, jak dzia\u0142aj\u0105 nasze procesy w tle w bazie danych i czy nie ma problem\u00f3w z ich dzia\u0142aniem. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Kiedy rozwa\u017camy punkty kontrolne, nale\u017cy pami\u0119ta\u0107, \u017ce punkty kontrolne zrzucaj\u0105 \"brudne\" strony z obszaru pami\u0119ci wsp\u00f3\u0142dzielonej na dysk, a nast\u0119pnie tworz\u0105 punkt kontrolny. Ten punkt kontrolny mo\u017ce by\u0107 p\u00f3\u017aniej u\u017cywany jako miejsce przywracania, je\u015bli PostgreSQL zosta\u0142 nagle zako\u0144czony w wyniku awarii. <\/p>\n

<\/p>\n

Aby zresetowa\u0107 wszystkie \"brudne\" strony na dysku, nale\u017cy wykona\u0107 pewn\u0105 ilo\u015b\u0107 zapisywania. Zazwyczaj w systemach z du\u017c\u0105 ilo\u015bci\u0105 pami\u0119ci \u2013 jest to bardzo du\u017co. A je\u015bli nasze punkty kontrolne s\u0105 tworzone bardzo cz\u0119sto w kr\u00f3tkim okresie, wydajno\u015b\u0107 dysku b\u0119dzie znacznie spada\u0107. Klientowskie \u017c\u0105dania b\u0119d\u0105 cierpie\u0107 z powodu braku zasob\u00f3w. B\u0119d\u0105 konkurowa\u0107 o zasoby i nie b\u0119d\u0105 mia\u0142y wystarczaj\u0105cej wydajno\u015bci. <\/p>\n

<\/p>\n

Zatem przez pg_stat_bgwriter wed\u0142ug wskazanych p\u00f3l mo\u017cemy monitorowa\u0107 liczb\u0119 wyst\u0119puj\u0105cych punkt\u00f3w kontrolnych. Je\u015bli w jakim\u015b czasie (przez 10-15-20 minut, p\u00f3\u0142 godziny) wyst\u0119puje bardzo du\u017co punkt\u00f3w kontrolnych, na przyk\u0142ad 3-4-5, to ju\u017c mo\u017ce stanowi\u0107 problem. Nale\u017cy wtedy przyjrze\u0107 si\u0119 bazie danych, sprawdzi\u0107 konfiguracj\u0119, co powoduje takie nadmiar punkt\u00f3w kontrolnych. Mo\u017ce odbywa si\u0119 jaka\u015b du\u017ca operacja zapisu. Na podstawie obci\u0105\u017cenia mo\u017cemy to oceni\u0107, poniewa\u017c mamy ju\u017c wprowadzone wykresy obci\u0105\u017cenia. Mo\u017cemy dostosowa\u0107 parametry punkt\u00f3w kontrolnych tak, aby mia\u0142y mniejszy wp\u0142yw na wydajno\u015b\u0107 zapyta\u0144.<\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Ponownie wracam do autovacuum, poniewa\u017c to jest co\u015b, co, jak ju\u017c m\u00f3wi\u0142em, mo\u017ce bez trudu obni\u017cy\u0107 wydajno\u015b\u0107 zar\u00f3wno dysk\u00f3w, jak i zapyta\u0144, dlatego zawsze wa\u017cne jest ocenienie liczby autovacuum. <\/p>\n

<\/p>\n

Liczba pracownik\u00f3w autovacuum w bazie danych jest ograniczona. Domy\u015blnie wynosi ona trzy, wi\u0119c je\u015bli przez ca\u0142y czas pracuj\u0105 trzy pracownicy w bazie, oznacza to, \u017ce autovacuum jest niedostosowane, nale\u017cy zwi\u0119kszy\u0107 limity, przemy\u015ble\u0107 ustawienia autovacuum i zaj\u0105\u0107 si\u0119 konfiguracj\u0105.
\nWa\u017cne jest, aby oceni\u0107, jacy pracownicy vacuumu s\u0105 aktywni. Mo\u017ce to by\u0107 uruchomienie przez u\u017cytkownika, DBA, kt\u00f3ry r\u0119cznie uruchomi\u0142 jaki\u015b vacuum, co spowodowa\u0142o obci\u0105\u017cenie. Pojawi\u0142 si\u0119 jaki\u015b problem. Lub mo\u017ce to by\u0107 liczba vacuum, kt\u00f3re zmieniaj\u0105 licznik transakcji. Dla niekt\u00f3rych wersji PostgreSQL \u2013 to bardzo ci\u0119\u017ckie vacuum. I mog\u0105 z \u0142atwo\u015bci\u0105 obni\u017cy\u0107 wydajno\u015b\u0107, poniewa\u017c skanuj\u0105 ca\u0142\u0105 tabel\u0119, przegl\u0105daj\u0105 wszystkie bloki w tej tabeli. <\/p>\n

<\/p>\n

Oczywi\u015bcie, chodzi o czas trwania vacuum\u00f3w. Je\u015bli mamy d\u0142ugie vacuumy, kt\u00f3re dzia\u0142aj\u0105 przez d\u0142ugi czas, to znaczy, \u017ce powinni\u015bmy ponownie zwr\u00f3ci\u0107 uwag\u0119 na konfiguracj\u0119 vacuumu i by\u0107 mo\u017ce przeanalizowa\u0107 jego ustawienia. Mo\u017ce si\u0119 zdarzy\u0107 sytuacja, w kt\u00f3rej vacuum dzia\u0142a na tabeli przez d\u0142ugi czas (3-4 godziny), ale w trakcie dzia\u0142ania vacuumu w tabeli znowu zebra\u0142 si\u0119 du\u017cy wolumen martwych wierszy. I gdy tylko vacuum si\u0119 zako\u0144czy, znowu trzeba vacuumowa\u0107 t\u0119 tabel\u0119. I wracamy do sytuacji \u2013 niesko\u0144czonego vacuumu. W takim przypadku vacuum nie radzi sobie ze swoj\u0105 prac\u0105, a tabele zaczynaj\u0105 stopniowo puchn\u0105\u0107 pod wzgl\u0119dem rozmiaru, chocia\u017c ilo\u015b\u0107 u\u017cytecznych danych pozostaje taka sama. Dlatego przy d\u0142ugich vacuumach zawsze zwracamy uwag\u0119 na konfiguracj\u0119 i staramy si\u0119 j\u0105 optymalizowa\u0107, ale w taki spos\u00f3b, aby nie ucierpia\u0142a wydajno\u015b\u0107 zapyta\u0144 klient\u00f3w. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Obecnie niemal nie ma instalacji PostgreSQL, w kt\u00f3rej nie by\u0142oby replikacji strumieniowej. Replikacja to proces przenoszenia danych z mastera na replik\u0119.<\/p>\n

<\/p>\n

Replikacja w PostgreSQL jest zorganizowana przez dziennik transakcji. Master generuje dziennik transakcji. Dziennik transakcji przez po\u0142\u0105czenie sieciowe trafia na replik\u0119, a nast\u0119pnie na replik\u0119 jest odtwarzany. To proste. <\/p>\n

<\/p>\n

Odpowiednio, do monitorowania op\u00f3\u017anienia replikacji u\u017cywa si\u0119 widoku pg_stat_replication. Ale z nim nie jest wszystko takie proste. W wersji 10 widok przeszed\u0142 kilka zmian. Po pierwsze, niekt\u00f3re pola zosta\u0142y przemianowane. I dodano kilka p\u00f3l. W wersji 10 pojawi\u0142y si\u0119 pola, kt\u00f3re pozwalaj\u0105 ocenia\u0107 lag replikacji w sekundach. To bardzo wygodne. Do wersji 10 by\u0142a mo\u017cliwo\u015b\u0107 oceny lag replikacji w bajtach. Taka mo\u017cliwo\u015b\u0107 pozosta\u0142a r\u00f3wnie\u017c w wersji 10, tzn. mo\u017cna wybiera\u0107, co jest dla was wygodniejsze - ocenia\u0107 lag w bajtach lub w sekundach. Wiele os\u00f3b robi to i to.<\/p>\n

<\/p>\n

Niemniej jednak, aby oceni\u0107 lag replikacji, nale\u017cy zna\u0107 pozycj\u0119 dziennika w transakcji. I te pozycje dziennika transakcji s\u0105 w\u0142a\u015bnie w widoku pg_stat_replication. M\u00f3wi\u0105c wprost, mo\u017cemy za pomoc\u0105 funkcji pg_xlog_location_diff() wzi\u0105\u0107 dwa punkty w dzienniku transakcji. Obliczy\u0107 mi\u0119dzy nimi r\u00f3\u017cnic\u0119 i uzyska\u0107 lag replikacji w bajtach. To bardzo wygodne i proste. <\/p>\n

<\/p>\n

W dziesi\u0105tej wersji ta funkcja zosta\u0142a przemianowana na pg_wal_lsn_diff(). Og\u00f3lnie we wszystkich funkcjach, widokach, narz\u0119dziach, gdzie pojawia\u0142o si\u0119 s\u0142owo \u201exlog\u201d, zosta\u0142o ono zast\u0105pione warto\u015bci\u0105 \u201ewal\u201d. Dotyczy to zar\u00f3wno widok\u00f3w, jak i funkcji. To jest takie nowo wprowadzenie. <\/p>\n

<\/p>\n

Ponadto w dziesi\u0105tej wersji dodano linijki, kt\u00f3re konkretnie pokazuj\u0105 op\u00f3\u017anienie. To s\u0105 write lag, flush lag, replay lag. Tzn. te rzeczy wa\u017cne jest monitorowa\u0107. Je\u015bli widzimy, \u017ce mamy op\u00f3\u017anienie w replikacji, musimy zbada\u0107, dlaczego ono wyst\u0105pi\u0142o, sk\u0105d si\u0119 wzi\u0119\u0142o i usun\u0105\u0107 problem. <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Z metrykami systemowymi prawie wszystko jest w porz\u0105dku. Pocz\u0105tek ka\u017cdego monitoringu zaczyna si\u0119 od metryk systemowych. To jest wykorzystanie procesor\u00f3w, pami\u0119ci, swap, sieci i dysku. Jednak wiele parametr\u00f3w nie jest domy\u015blnie dost\u0119pnych. <\/p>\n

<\/p>\n

Je\u015bli z wykorzystaniem procesora wszystko jest w porz\u0105dku, to z wykorzystaniem dysku s\u0105 problemy. Zazwyczaj programi\u015bci dodaj\u0105 informacje o przepustowo\u015bci. Mo\u017ce by\u0107 to w iops lub bajtach. Ale zapominaj\u0105 o latencji i wykorzystaniu urz\u0105dze\u0144 dyskowych. To s\u0105 wa\u017cniejsze parametry, kt\u00f3re umo\u017cliwiaj\u0105 ocen\u0119, jak bardzo obci\u0105\u017cone s\u0105 dyski i jak bardzo spowalniaj\u0105. Je\u015bli mamy wysok\u0105 latencj\u0119, to oznacza, \u017ce wyst\u0119puj\u0105 jakie\u015b problemy z dyskami. Je\u015bli mamy wysokie wykorzystanie, to oznacza, \u017ce dyski nie spe\u0142niaj\u0105 oczekiwa\u0144.<\/strong> To s\u0105 bardziej jako\u015bciowe charakterystyki ni\u017c przepustowo\u015b\u0107.<\/p>\n

<\/p>\n

Cho\u0107 t\u0119 statystyk\u0119 mo\u017cna r\u00f3wnie\u017c uzyska\u0107 z systemu plik\u00f3w \/proc, tak jak to si\u0119 robi dla wykorzystania procesor\u00f3w. Dlaczego tej informacji nie dodaj\u0105 do monitoringu, nie wiem. Jednak\u017ce wa\u017cne jest, aby to posiada\u0107 w swoim monitoringu.<\/strong> <\/p>\n

<\/p>\n

To samo dotyczy interfejs\u00f3w sieciowych. S\u0105 informacje o przepustowo\u015bci sieci w pakietach, w bajtach, ale nie ma informacji o latencji i nie ma informacji o wykorzystaniu, chocia\u017c to te\u017c jest przydatna informacja.<\/strong> <\/p>\n

<\/p>\n

\"Podstawy<\/p>\n

<\/p>\n

Wszystkie monitoringi maj\u0105 wady. I jakiegokolwiek monitoringu by\u015b nie wzi\u0105\u0142, zawsze b\u0119dzie on niezgodny z jakimi\u015b kryteriami. Jednak rozwijaj\u0105 si\u0119, dodawane s\u0105 nowe funkcje, nowe rzeczy, wi\u0119c wybierz co\u015b i dopracuj. <\/p>\n

<\/p>\n

Aby dopracowywa\u0107, zawsze trzeba mie\u0107 \u015bwiadomo\u015b\u0107, co oznacza przekazywana statystyka i jak mo\u017cna poprzez ni\u0105 rozwi\u0105zywa\u0107 problemy. <\/p>\n

<\/p>\n

I kilka kluczowych punkt\u00f3w:<\/p>\n

<\/p>\n