Zachęcam do zapoznania się z prezentacją przygotowaną przez Alekseja Lesowskiego z Data Egret "Podstawy monitorowania PostgreSQL"
W tej prezentacji Aleksej Lesowski omówi kluczowe elementy statystyki PostgreSQL, co one oznaczają oraz dlaczego powinny znajdować się w monitoringu; jakiego rodzaju wykresy powinny być w monitoringu, jak je dodać i jak je interpretować. Prezentacja będzie przydatna dla administratorów baz danych, administratorów systemów oraz programistów, którzy interesują się rozwiązywaniem problemów związanych z Postgresem.
Nazywam się Aleksej Lesowski, reprezentuję firmę Data Egret.
Kilka słów o sobie. Kiedyś zaczynałem jako administrator systemów.
Zarządzałem różnorodnymi systemami Linux, zajmowałem się różnymi sprawami związanymi z Linuxem, tj. wirtualizacją, monitoringiem, pracowałem z proxy itd. Ale w pewnym momencie zacząłem poświęcać więcej czasu na bazy danych, PostgreSQL. Bardzo mi się podobał. Z czasem stałem się DBA PostgreSQL i spędzałem na tym większość swojego czasu pracy.
I przez całą swoją karierę zawsze interesowały mnie tematy związane ze statystyką, monitoringiem i zbieraniem telemetrycznych danych. Kiedy byłem administratorem systemów, pracowałem intensywnie z Zabbixem. Napisałem też niewielki zestaw skryptów jak . Był dość popularny w swoim czasie. Dzięki niemu można było monitorować nie tylko różne ważne elementy związane z Linuxem, ale także inne komponenty.
Obecnie zajmuję się już PostgreSQL. Piszę aktualnie inne narzędzie, które umożliwia pracę ze statystyką PostgreSQL. Nazywa się (artykuł na habrze — ).
Krótki wstęp. Jakie sytuacje zdarzają się naszym klientom? Dochodzi do jakiejś awarii związanej z bazą danych. Gdy baza danych zostaje już naprawiona, szef działu lub szef projektowania mówi: „Przyjaciele, musimy monitorować bazę danych, ponieważ zdarzyło się coś złego i musimy zapobiec temu w przyszłości”. I tu zaczyna się interesujący proces wyboru systemu monitoringu lub dostosowywania istniejącego systemu monitoringu, aby móc monitorować swoją bazę danych – PostgreSQL, MySQL lub inne. Koledzy zaczynają proponować: „Słyszałem, że jest taka baza danych. Użyjmy jej.” Koledzy zaczynają ze sobą dyskutować. Ostatecznie okazuje się, że wybieramy jakąś bazę danych, ale monitoring PostgreSQL jest w niej słabo przedstawiony i zawsze trzeba coś poprawiać. Korzystać z repozytoriów z GitHub, klonować je, dostosowywać skrypty, jakoś konfigurować. I ostatecznie prowadzi to do ręcznej pracy.
Dlatego w tym wykładzie postaram się przekazać wam pewną wiedzę na temat tego, jak wybierać monitoring nie tylko dla PostgreSQL, ale także dla baz danych. I przekazać te informacje, które pozwolą wam poprawić wasz monitoring, aby uzyskać z niego korzyści, aby można było monitorować swoją bazę danych z pożytkiem, aby na czas ostrzegać o nadchodzących sytuacjach awaryjnych, które mogą się pojawić.
I te pomysły, które będą w tym wykładzie, można bezpośrednio dostosować do każdej bazy danych, czy to SQL, czy noSQL. Dlatego mówimy tutaj nie tylko o PostgreSQL, ale także będzie wiele przepisów, jak to zrobić w PostgreSQL. Będą przykłady zapytań, przykłady encji, które są w PostgreSQL do monitorowania. A jeśli wasza baza danych ma podobne elementy, które można włączyć do monitoringu, również możecie je dostosować, dodać i będzie dobrze.
Nie będę w wykładzie
opowiadać o tym, jak zbierać i przechowywać metryki. Nie powiem nic o przetwarzaniu danych i ich udostępnianiu użytkownikowi. I nie wspomnę o alertowaniu.
Jednak w trakcie opowiadania będę pokazywał różne zrzuty ekranu istniejących monitorów, a także będę je krytykować. Niemniej jednak postaram się nie wymieniać marek, aby nie tworzyć reklamy ani antyreklamy dla tych produktów. Wszystkie zbiegi okoliczności są przypadkowe i pozostają w sferze waszej wyobraźni.
Na początek wyjaśnijmy, czym jest monitoring. Monitoring to bardzo istotna rzecz, którą należy posiadać. To wszyscy rozumieją. Jednocześnie jednak monitoring nie jest związany z produktem biznesowym i nie wpływa bezpośrednio na zyski firmy, dlatego zazwyczaj poświęca się mu czas jako sprawie drugorzędnej. Jeśli mamy czas, zajmujemy się monitoringiem, jeśli czasu nie ma, to OK, umieścimy to w backlogu i kiedyś wrócimy do tych zadań.
Z naszej praktyki wynika, że gdy przychodzimy do klientów, monitoring często jest niedopracowany i nie zawiera interesujących elementów, które mogłyby pomóc w lepszej pracy z bazą danych. Dlatego monitoring zawsze wymaga dopracowania.
Bazy danych to skomplikowane rzeczy, które również muszą być monitorowane, ponieważ bazy danych są magazynem informacji. A informacje są bardzo ważne dla firmy, nie można ich w żaden sposób stracić. Jednocześnie bazy danych to bardzo skomplikowane fragmenty oprogramowania. Składają się z wielu komponentów. I wiele z tych komponentów wymaga monitorowania.
Jeśli mówimy konkretnie o PostgreSQL, można go przedstawić jako schemat składający się z wielu komponentów. Te komponenty współdziałają ze sobą. Jednocześnie w PostgreSQL istnieje tzw. podsystem Stats Collector, który umożliwia zbieranie statystyk dotyczących pracy tych podsystemów i udostępnia pewien interfejs administratorowi lub użytkownikowi, aby mógł przeglądać te statystyki.
Te statystyki są przedstawione jako zestaw funkcji i widoków (view). Można je również nazwać tabelkami. To znaczy, za pomocą zwykłego klienta psql można połączyć się z bazą danych, wykonać zapytanie do tych funkcji i widoków, i uzyskać konkretne liczby o pracy podsystemów PostgreSQL.
Możesz dodać te liczby do swojego ulubionego systemu monitorowania, narysować wykresy, dodać funkcje i uzyskać analitykę w dłuższym okresie czasu.
W tym raporcie nie zamierzam jednak omawiać wszystkich tych funkcji, ponieważ mogłoby to zająć cały dzień. Skupię się dosłownie na dwóch, trzech lub czterech aspektach, które pomogą poprawić monitorowanie.
A mówiąc o monitorowaniu bazy danych, co należy monitorować? Przede wszystkim dostępność, ponieważ baza danych to usługa, która zapewnia dostęp do danych dla klientów, więc musimy monitorować jej dostępność, a także pewne jakościowe i ilościowe wskaźniki.
Konieczne jest również monitorowanie klientów, którzy łączą się z naszą bazą danych, ponieważ mogą to być zarówno normalni klienci, jak i szkodliwi klienci, którzy mogą zaszkodzić bazie danych. Musimy ich także monitorować i śledzić ich aktywność.
Kiedy klienci łączą się z bazą danych, oczywiście zaczynają pracować z naszymi danymi, dlatego musimy monitorować również to, jak klienci pracują z danymi: z jakimi tabelami, w mniejszym stopniu z jakimi indeksami. Musimy ocenić obciążenie (workload), które generują nasi klienci.
Obciążenie składa się oczywiście z zapytań. Aplikacje łączą się z bazą danych i odwołują się do danych za pomocą zapytań, dlatego ważne jest, aby oceniać, jakie zapytania są w naszej bazie danych, monitorować ich adekwatność, zapewniać, że nie są źle napisane, oraz sprawdzać, czy niektóre opcje należy przepis na szybciej działające i bardziej wydajne.
A skoro mówimy o bazie danych, to zawsze są to procesy w tle. Procesy w tle pozwalają utrzymać wydajność bazy danych na odpowiednim poziomie, dlatego potrzebują pewnej ilości zasobów do działania. Jednocześnie mogą kolidować z zasobami zapytań od klientów, dlatego intensywna praca procesów w tle może bezpośrednio wpływać na wydajność zapytań od klientów. Musimy je również monitorować i sprawdzać, czy nie ma nadmiernych obciążeń związanych z procesami w tle.
A wszystko to w planie monitorowania bazy danych pozostaje w metrykach systemowych. Jednak biorąc pod uwagę, że w przeważającej części cała infrastruktura przenosi się do chmur, metryki systemowe pojedynczego hosta zawsze schodzą na drugi plan. Niemniej jednak w bazach danych wciąż mają znaczenie, a monitorowanie metryk systemowych również jest konieczne.
Z metrykami systemowymi w miarę wszystko jest w porządku, wszystkie nowoczesne systemy monitorowania już je wspierają, ale ogólnie wciąż brakuje kilku komponentów, które należy dodać. O nich również wspomnę, kilka slajdów będzie poświęconych temu tematowi.
Pierwszy punkt planu – to dostępność. Co to jest dostępność? Dostępność w moim przekonaniu – to zdolność bazy do obsługi połączeń, tzn. baza jest uruchomiona, jako usługa przyjmuje połączenia od klientów. Tę dostępność można oceniać pewnymi charakterystykami. Te charakterystyki bardzo wygodnie się przedstawia na dashboardach.
Wszyscy wiedzą, co to są dashboardy. To, kiedy rzucasz okiem na ekran, na którym zebrane są potrzebne informacje. I od razu możesz stwierdzić – czy w bazie jest problem, czy nie.
Odpowiednio dostępność bazy danych i inne kluczowe charakterystyki zawsze należy przedstawiać na dashboardach, aby ta informacja była pod ręką, abyś miał ją zawsze w zasięgu ręki. Jakieś dodatkowe szczegóły, które już pomagają w dochodzeniach incydentów lub badaniach sytuacji awaryjnych, należy już przedstawiać na wtórnych dashboardach lub ukrywać w linkach drilldown, które prowadzą do zewnętrznych systemów monitorowania.
Przykład jednego znanej systemu monitorowania. To bardzo świetny system monitorowania. Zbiera bardzo dużo danych, ale z mojego punktu widzenia ma dziwne pojęcie dashboardów. Jest tam link „stwórz dashboard”. Ale gdy tworzysz dashboard, tworzysz pewien wykaz składający się z dwóch kolumn, pewien wykaz wykresów. I kiedy musisz coś zobaczyć, zaczynasz klikać myszką, przewijać, szukać potrzebnego wykresu. I zajmuje to czas, tzn. właściwie nie ma dashboardów. Są tylko wykazy wykresów.
Co należy dodać do tych pulpitów? Można zacząć od takiej charakterystyki jak czas odpowiedzi. W PostgreSQL istnieje widok pg_stat_statements. Domyślnie jest on wyłączony, ale jest to jeden z ważnych widoków systemowych, który zawsze powinno się włączać i używać. Przechowuje on informacje o wszystkich wykonanych zapytaniach, które zostały zrealizowane w bazie danych.
Odpowiednio, możemy wyjść od tego, że możemy wziąć łączny czas wykonania wszystkich zapytań i podzielić go przez liczbę zapytań za pomocą powyższych pól. Ale to tak średnia temperatura w szpitalu. Możemy wyjść od innych pól – minimalnego czasu wykonania zapytań, maksymalnego i mediany. A nawet możemy obliczać percentyle, w PostgreSQL są odpowiednie funkcje do tego. I możemy uzyskać jakieś dane, które charakteryzują czas odpowiedzi naszej bazy na już zrealizowane zapytania, tzn. nie wykonujemy fałszywego zapytania 'select 1' i nie patrzymy na czas odpowiedzi, ale analizujemy czas odpowiedzi na już wykonaną zapytania i przedstawiamy to jako osobną cyfrę lub rysujemy na tej podstawie wykres.
Również ważne jest monitorowanie liczby błędów generowanych przez system w danym momencie. I do tego można użyć widoku pg_stat_database. Oryginalnie kierujemy się polem xact_rollback. To pole pokazuje nie tylko liczbę rollbacków, które mają miejsce w bazie, ale także uwzględnia liczbę błędów. Mówiąc krótko, możemy wyprowadzić tę liczbę na nasz pulpit i zobaczyć, ile mamy błędów w danym momencie. Jeśli błędów jest dużo, to już dobry powód, aby zajrzeć do logów i sprawdzić, co to są za błędy i dlaczego występują, a dalej już prowadzić dochodzenie i je rozwiązywać.
Można dodać takie coś jak Tachometr. To liczba transakcji na sekundę oraz liczba zapytań na sekundę. Mówiąc inaczej, możesz używać tych cyfr jako aktualnej wydajności swojej bazy danych i obserwować, czy są szczyty zapytań, szczyty transakcji, czy przeciwnie, baza nie jest obciążona, ponieważ jakiś backend się wyłączył. Tę liczbę ważne jest zawsze obserwować i pamiętać, że dla naszego projektu taka wydajność jest normalna, a wartości wyższe lub niższe są już jakieś problematyczne i niezrozumiałe, a więc należy sprawdzić, dlaczego są takie liczby.
Aby ocenić liczbę transakcji, możemy ponownie skorzystać z widoku pg_stat_database. Możemy zsumować liczbę commitów i liczbę rollbacków, aby uzyskać liczbę transakcji na sekundę.
Wszyscy rozumieją, że w jedną transakcję może zmieścić się kilka zapytań? Dlatego TPS i QPS są nieco różne.
Liczbę zapytań na sekundę można uzyskać z pg_stat_statements, po prostu sumując wszystkie wykonane zapytania. Oczywiście porównujemy bieżącą wartość z poprzednią, odejmujemy, uzyskujemy różnicę, otrzymujemy liczbę.
Można dodać dodatkowe metryki według uznania, które również pomagają ocenić dostępność naszej bazy i śledzić, czy nie było jakichkolwiek przestojów.
Jedną z tych metryk jest uptime. Jednak uptime w PostgreSQL to nieco skomplikowana sprawa. Opowiem, dlaczego. Kiedy PostgreSQL jest uruchomiony, zaczyna się liczyć uptime. Ale jeśli w pewnym momencie, na przykład w nocy, wykonywana była jakaś zadanie, a OOM-killer wymusił zakończenie procesu potomnego PostgreSQL, to w takim przypadku PostgreSQL kończy połączenie wszystkich klientów, resetuje obszar pamięci sharded i zaczyna przywracanie od ostatniego punktu kontrolnego. I podczas gdy trwa to przywracanie, baza nie akceptuje połączeń, czyli tę sytuację można ocenić jako downtime. Jednak licznik uptime się nie zresetuje, ponieważ uwzględnia czas uruchomienia postmastera od momentu pierwszego uruchomienia. Dlatego takie sytuacje mogą zostać pominięte.
Należy również monitorować liczbę pracowników autovacuum. Czy wszyscy wiedzą, co to jest autovacuum w PostgreSQL? To interesujący podsystem w PostgreSQL. Napisano o nim wiele artykułów, wygłoszono wiele prezentacji. Jest wiele dyskusji na temat vacuum, jak powinno działać. Wielu uważa go za nieuchronne zło. Ale tak jest. To pewien odpowiednik zbieracza śmieci, który czyści przestarzałe wersje wierszy, które nie są potrzebne żadnej transakcji i zwalnia miejsce w tabelach, indeksach na nowe wiersze.
Dlaczego należy go monitorować? Ponieważ vacuum czasami powoduje poważne problemy. Zajmuje dużą ilość zasobów, a na tym cierpią zapytania klientów.
Monitorowanie powinno odbywać się za pomocą widoku pg_stat_activity, o którym będę mówić w następnej sekcji. Ten widok pokazuje bieżącą aktywność w bazie danych. Dzięki tej aktywności możemy śledzić liczbę procesów vacuum, które są aktualnie uruchomione. Możemy monitorować procesy vacuum i dostrzegać, że jeśli przekroczony zostanie limit, to jest to powód, aby zajrzeć do ustawień PostgreSQL i zoptymalizować działanie vacuum.
Inną cechą PostgreSQL jest to, że bardzo źle znosi długie transakcje, zwłaszcza te, które długo wiszą i nic nie robią. To tak zwane stat idle-in-transaction. Taka transakcja utrzymuje blokady, co uniemożliwia działanie vacuum. W rezultacie tabele puchną, zwiększają swój rozmiar. A zapytania, które działają na tych tabelach, zaczynają działać wolniej, ponieważ muszą przeszukiwać wszystkie stare wersje wierszy z pamięci na dysk i z powrotem. Dlatego należy monitorować czas trwania najdłuższych transakcji oraz najdłuższych zapytań vacuum. Jeśli widzimy jakieś procesy, które działają już bardzo długo, przekraczając 10-20-30 minut w obciążeniu OLTP, wtedy należy na nie zwrócić uwagę i zakończyć je wymuszone, lub zoptymalizować aplikację, aby nie były wywoływane i nie wisiały tak długo. Dla obciążenia analitycznego 10-20-30 minut to norma, zdarzają się także dłuższe.
Kolejnym elementem są podłączeni klienci. Gdy już utworzyliśmy dashboard i wyświetliliśmy na nim kluczowe metryki dostępności, możemy także dodać dodatkowe informacje o podłączonych klientach.
Informacja o podłączonych klientach jest ważna, ponieważ z perspektywy PostgreSQL klienci są różni. Są dobrzy klienci i źli klienci.
Przykład. Pod klientem rozumiem aplikację. Aplikacja połączyła się z bazą danych i zaczyna natychmiast wysyłać do niej swoje zapytania, baza danych je przetwarza i wykonuje, a wyniki zwraca klientowi. To są dobrzy i prawidłowi klienci.
Zdarzają się sytuacje, kiedy klient się podłączył, trzyma połączenie, ale nic nie robi. Znajduje się w stanie idle.
Jednak bywają złe połączenia. Na przykład, ten sam klient połączył się, otworzył transakcję, coś zrobił w bazie, a potem przeszedł do kodu, powiedzmy, aby odwołać się do zewnętrznego źródła lub w celu przetworzenia otrzymanych danych. Ale nie zamknął transakcji. I transakcja wisi w bazie, blokując wiersz. To zła sytuacja. A jeśli nagle aplikacja wewnętrznie padnie z wyjątkiem (Exception), to transakcja może zostać otwarta na bardzo długi czas. I to bezpośrednio wpływa na wydajność PostgreSQL. PostgreSQL będzie działał wolniej. Dlatego takich klientów ważne jest, aby na czas śledzić i wymuszać zakończenie ich pracy. Należy również optymalizować swoje aplikacje, aby takich sytuacji unikać.
Innymi złymi klientami są klienci oczekujący. Stają się złymi z powodu okoliczności. Na przykład, zwykła wisząca transakcja: może otworzyć transakcję, zablokować niektóre wiersze, a potem gdzieś w kodzie zginąć, pozostawiając wiszącą transakcję. Przyjdzie inny klient, zażąda tych samych danych, ale napotka blokadę, ponieważ ta wisząca transakcja już trzyma blokady na potrzebnych wierszach. I druga transakcja będzie wisiała w oczekiwaniu na zakończenie pierwszej transakcji lub wymuszone zamknięcie przez administratora. Tak więc, transakcje oczekujące mogą się gromadzić i przekraczać limit połączeń z bazą danych. A kiedy limit jest przekroczony, aplikacja nie może już działać z bazą. To już sytuacja awaryjna dla projektu. Dlatego złe klientów należy śledzić i odpowiednio reagować.
Inny przykład monitoringu. I tutaj już elegancki dashboard. Informacje o połączeniach są na górze. Połączenie DB – 8 sztuk. I to wszystko. Nie mamy informacji o tym, którzy klienci są aktywni, którzy klienci są po prostu bezczynni, nic nie robią. Nie ma informacji o wiszących transakcjach i oczekujących połączeniach, tzn. to taka liczba, która pokazuje liczbę połączeń i tyle. A dalej zgadujcie sami.
Aby dodać te informacje do monitorowania, należy zwrócić się do widoku pg_stat_activity. Jeśli spędzasz dużo czasu w PostgreSQL, to jest to bardzo przydatny widok, który powinien stać się Twoim przyjacielem, ponieważ pokazuje aktualną aktywność w PostgreSQL, tzn. co się w nim dzieje. Dla każdego procesu istnieje osobny wiersz, który pokazuje informacje na temat tego procesu: z jakiego hosta wykonano połączenie, pod jakim użytkownikiem, jakim imieniem, kiedy uruchomiono transakcję, jaki jest aktualnie wykonywany zapytanie oraz jakie zapytanie było wykonywane ostatnio. W związku z tym, stan klienta możemy oceniać na podstawie pola stat. Możemy grupować według tego pola i uzyskać statystyki, które obecnie znajdują się w bazie danych oraz liczbę połączeń związanych z tą statystyką w bazie danych. Otrzymane liczby możemy wysyłać do naszego monitorowania i na ich podstawie rysować wykresy.
Również ważne jest, aby oceniać czas trwania transakcji. Już mówiłem, że ważne jest ocenianie czasu trwania vacuumów, ale transakcje również ocenia się w ten sam sposób. Są pola xact_start i query_start, które pokazują czas rozpoczęcia transakcji i czas rozpoczęcia zapytania. Używamy funkcji now(), która pokazuje aktualny znacznik czasu i odejmujemy timestamp transakcji i zapytania. Otrzymujemy czas trwania transakcji oraz czas trwania zapytania.
Jeśli widzimy długie transakcje, powinniśmy je zakończyć. Dla obciążenia OLTP, długie transakcje to te trwające dłużej niż 1-2-3 minuty.. Dla obciążenia OLAP, długie transakcje są normą, ale jeśli trwają dłużej niż dwie godziny, to jest to również oznaką, że gdzieś mamy zanikanie.
Kiedy klienci połączą się z bazą danych, zaczynają pracować z naszymi danymi. Odnoszą się do tabel, odnoszą się do indeksów, aby uzyskać dane z tabel. Ważne jest, aby oceniać to, jak klienci pracują z tymi danymi.
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.
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.
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.
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.
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.
I będziemy mogli to zobaczyć w monitoringu. Możemy już spojrzeć na to zapytanie, wykonać dla niego explain, zebrać statystyki, stworzyć nowy dodatkowy indeks. I zareagować na ten problem. Dlatego to ważne.
Inny przykład monitorowania. Myślę, że wiele osób go rozpozna, ponieważ jest bardzo popularny. Kto używa go w swoich projektach ? А кто использует этот продукт совместно с Prometheus? Дело в том, что в стандартном репозитории этого мониторинга есть дашборд для работы с PostgreSQL – Prometheus. Ale jest jeden zły szczegół.
Jest kilka wykresów. A jako jednostka podano bajty, tj. jest 5 wykresów. To Insert data, Update data, Delete data, Fetch data i Return data. Jako jednostka miary podano bajty. Problem w tym, że statystyki w PostgreSQL zwracają dane w krotkach (tuplach). A te wykresy to bardzo dobry sposób na zaniżenie obciążenia roboczego wielokrotnie, ponieważ krotka to nie bajt, krotka to wiersz, to wiele bajtów i zawsze ma zmienną długość. Tzn. obliczenie obciążenia roboczego w bajtach za pomocą krotek to nierealne zadanie lub bardzo trudne. Dlatego, gdy używasz dashboardu lub wbudowanego monitorowania, zawsze ważne jest, aby zrozumieć, że działa on poprawnie i zwraca ci poprawnie ocenione dane.
Jak uzyskać statystyki dla tych tabel? W tym celu PostgreSQL ma pewną rodzinę widoków. A główny widok to . User_tables – oznacza to, że tabele zostały stworzone z perspektywy użytkownika. W przeciwieństwie do tego są systemowe widoki, które są używane przez sam PostgreSQL. I jest podsumowująca tabela Alltables, która obejmuje zarówno systemowe, jak i użytkowe. Możesz się opierać na dowolnej z nich, która ci najbardziej odpowiada.
Na podstawie powyższych pól można ocenić liczbę insert, update i delete. Ten przykład dashboardu, który użyłem, dokładnie wykorzystuje te pola do oceny charakterystyk obciążenia roboczego. Dlatego możemy także się na nich opierać. Ale warto pamiętać, że to krotki, a nie bajty, więc nie możemy po prostu przekształcić ich w bajty.
Na podstawie tych danych możemy budować tzw. tabele TopN. Na przykład, Top-5, Top-10. I możemy śledzić te gorące tabele, które są używane częściej niż inne. Na przykład, 5 „gorących” tabel pod kątem wstawiania. I na podstawie tych tabel TopN oceniamy nasze obciążenie robocze i możemy oceniać wzrosty obciążenia roboczego po różnych wydaniach, aktualizacjach i wdrożeniach.
Również ważne jest ocenianie rozmiarów tabel, ponieważ czasami deweloperzy wdrażają nową funkcjonalność, co prowadzi do tego, że nasze tabele zaczynają puchnąć, ponieważ postanowili dodać dodatkową ilość danych, nie przewidując, jak wpłynie to na rozmiar bazy danych. Takie przypadki również bywają dla nas niespodziankami.
A teraz mam do was małe pytanie. Jaki pytanie pojawia się, gdy zauważacie obciążenie serwera z bazą danych? Jakie jest następne pytanie, które przychodzi wam do głowy?
Ale w rzeczywistości pojawia się następne pytanie. Jakie zapytania powodują obciążenie? Tzn. nie jest interesujące patrzeć na procesy, które generują obciążenie. Jasne, że jeśli hostuje bazę danych, to tam działa baza danych i wiadomo, że tylko bazy danych będą obciążać. Jeśli otworzymy Top, zobaczymy tam listę procesów w PostgreSQL, które coś robią. Z Top nie będzie wiadomo, co one robią.
W związku z tym konieczne jest wykrycie tych zapytań, które powodują największe obciążenie, ponieważ tuning zapytań zazwyczaj przynosi więcej korzyści niż tuning konfiguracji PostgreSQL czy systemu operacyjnego, a nawet tuning sprzętu. Moim zdaniem to około 80-85-90%. I dzieje się to znacznie szybciej. Łatwiej jest poprawić zapytanie, niż poprawić konfigurację, zaplanować restart, szczególnie jeśli bazy nie można restartować, albo dodawać sprzętu. Warto przeorganizować zapytanie lub dodać indeks, aby uzyskać lepszy wynik z tego zapytania.
W związku z tym należy monitorować zapytania i ich adekwatność. Weźmy inny przykład monitoringu. I tutaj również wygląda to na doskonały monitoring. Są informacje na temat replikacji, informacje o przepustowości, blokadach, wykorzystaniu zasobów. Wszystko w porządku, ale brakuje informacji o zapytaniach. Nie wiadomo, jakie zapytania są wykonywane w naszej bazie danych, jak długo one trwają, ile tych zapytań. Musimy zawsze mieć te informacje w monitoringu.
Aby uzyskać te informacje, możemy użyć modułu pg_stat_statements. Na jego podstawie można tworzyć różne wykresy. Na przykład, możemy uzyskać informacje na temat najczęściej wykonywanych zapytań, czyli tych, które są wykonywane najczęściej. Tak, po wdrożeniach również bardzo przydatne jest spojrzenie na to i zrozumienie, czy nie ma jakiegoś wzrostu liczby zapytań.
Możemy monitorować najdłużej wykonywane zapytania, czyli te, które trwają najdłużej. Obciążają one procesor i zużywają operacje wejścia/wyjścia. Możemy to ocenić na podstawie pól total_time, mean_time, blk_write_time i blk_read_time.
Możemy oceniać i monitorować najcięższe zapytania pod względem wykorzystania zasobów, te, które odczytują dane z dysku, które działają z pamięcią lub, przeciwnie, generują obciążenie zapisu.
Możemy oceniać najhojniejsze zapytania. To są te zapytania, które zwracają dużą liczbę wierszy. Na przykład, może to być zapytanie, w którym zapomniano ustawić limit. I po prostu zwraca całe dane z tabeli lub zapytania dotyczące zażądanych tabel.
Możemy również monitorować zapytania, które korzystają z plików tymczasowych lub tabel tymczasowych.
Zostały nam procesy w tle. Procesy w tle to przede wszystkim punkty kontrolne, zwane również checkpointami, autovacuum i replikacja.
Inny przykład monitorowania. Po lewej stronie jest zakładka Maintenance, przechodzimy do niej i mamy nadzieję zobaczyć coś przydatnego. Ale tutaj są tylko czasy działania procesu vacuum i zbierania statystyk, nic więcej. To bardzo uboga informacja, więc zawsze musimy mieć informacje o tym, jak działają nasze procesy w tle w bazie danych i czy nie ma problemów z ich działaniem.
Kiedy rozważamy punkty kontrolne, należy pamiętać, że punkty kontrolne zrzucają "brudne" strony z obszaru pamięci współdzielonej na dysk, a następnie tworzą punkt kontrolny. Ten punkt kontrolny może być później używany jako miejsce przywracania, jeśli PostgreSQL został nagle zakończony w wyniku awarii.
Aby zresetować wszystkie "brudne" strony na dysku, należy wykonać pewną ilość zapisywania. Zazwyczaj w systemach z dużą ilością pamięci – jest to bardzo dużo. A jeśli nasze punkty kontrolne są tworzone bardzo często w krótkim okresie, wydajność dysku będzie znacznie spadać. Klientowskie żądania będą cierpieć z powodu braku zasobów. Będą konkurować o zasoby i nie będą miały wystarczającej wydajności.
Zatem przez pg_stat_bgwriter według wskazanych pól możemy monitorować liczbę występujących punktów kontrolnych. Jeśli w jakimś czasie (przez 10-15-20 minut, pół godziny) występuje bardzo dużo punktów kontrolnych, na przykład 3-4-5, to już może stanowić problem. Należy wtedy przyjrzeć się bazie danych, sprawdzić konfigurację, co powoduje takie nadmiar punktów kontrolnych. Może odbywa się jakaś duża operacja zapisu. Na podstawie obciążenia możemy to ocenić, ponieważ mamy już wprowadzone wykresy obciążenia. Możemy dostosować parametry punktów kontrolnych tak, aby miały mniejszy wpływ na wydajność zapytań.
Ponownie wracam do autovacuum, ponieważ to jest coś, co, jak już mówiłem, może bez trudu obniżyć wydajność zarówno dysków, jak i zapytań, dlatego zawsze ważne jest ocenienie liczby autovacuum.
Liczba pracowników autovacuum w bazie danych jest ograniczona. Domyślnie wynosi ona trzy, więc jeśli przez cały czas pracują trzy pracownicy w bazie, oznacza to, że autovacuum jest niedostosowane, należy zwiększyć limity, przemyśleć ustawienia autovacuum i zająć się konfiguracją.
Ważne jest, aby ocenić, jacy pracownicy vacuumu są aktywni. Może to być uruchomienie przez użytkownika, DBA, który ręcznie uruchomił jakiś vacuum, co spowodowało obciążenie. Pojawił się jakiś problem. Lub może to być liczba vacuum, które zmieniają licznik transakcji. Dla niektórych wersji PostgreSQL – to bardzo ciężkie vacuum. I mogą z łatwością obniżyć wydajność, ponieważ skanują całą tabelę, przeglądają wszystkie bloki w tej tabeli.
Oczywiście, chodzi o czas trwania vacuumów. Jeśli mamy długie vacuumy, które działają przez długi czas, to znaczy, że powinniśmy ponownie zwrócić uwagę na konfigurację vacuumu i być może przeanalizować jego ustawienia. Może się zdarzyć sytuacja, w której vacuum działa na tabeli przez długi czas (3-4 godziny), ale w trakcie działania vacuumu w tabeli znowu zebrał się duży wolumen martwych wierszy. I gdy tylko vacuum się zakończy, znowu trzeba vacuumować tę tabelę. I wracamy do sytuacji – nieskończonego vacuumu. W takim przypadku vacuum nie radzi sobie ze swoją pracą, a tabele zaczynają stopniowo puchnąć pod względem rozmiaru, chociaż ilość użytecznych danych pozostaje taka sama. Dlatego przy długich vacuumach zawsze zwracamy uwagę na konfigurację i staramy się ją optymalizować, ale w taki sposób, aby nie ucierpiała wydajność zapytań klientów.
Obecnie niemal nie ma instalacji PostgreSQL, w której nie byłoby replikacji strumieniowej. Replikacja to proces przenoszenia danych z mastera na replikę.
Replikacja w PostgreSQL jest zorganizowana przez dziennik transakcji. Master generuje dziennik transakcji. Dziennik transakcji przez połączenie sieciowe trafia na replikę, a następnie na replikę jest odtwarzany. To proste.
Odpowiednio, do monitorowania opóźnienia replikacji używa się widoku pg_stat_replication. Ale z nim nie jest wszystko takie proste. W wersji 10 widok przeszedł kilka zmian. Po pierwsze, niektóre pola zostały przemianowane. I dodano kilka pól. W wersji 10 pojawiły się pola, które pozwalają oceniać lag replikacji w sekundach. To bardzo wygodne. Do wersji 10 była możliwość oceny lag replikacji w bajtach. Taka możliwość pozostała również w wersji 10, tzn. można wybierać, co jest dla was wygodniejsze - oceniać lag w bajtach lub w sekundach. Wiele osób robi to i to.
Niemniej jednak, aby ocenić lag replikacji, należy znać pozycję dziennika w transakcji. I te pozycje dziennika transakcji są właśnie w widoku pg_stat_replication. Mówiąc wprost, możemy za pomocą funkcji pg_xlog_location_diff() wziąć dwa punkty w dzienniku transakcji. Obliczyć między nimi różnicę i uzyskać lag replikacji w bajtach. To bardzo wygodne i proste.
W dziesiątej wersji ta funkcja została przemianowana na pg_wal_lsn_diff(). Ogólnie we wszystkich funkcjach, widokach, narzędziach, gdzie pojawiało się słowo „xlog”, zostało ono zastąpione wartością „wal”. Dotyczy to zarówno widoków, jak i funkcji. To jest takie nowo wprowadzenie.
Ponadto w dziesiątej wersji dodano linijki, które konkretnie pokazują opóźnienie. To są write lag, flush lag, replay lag. Tzn. te rzeczy ważne jest monitorować. Jeśli widzimy, że mamy opóźnienie w replikacji, musimy zbadać, dlaczego ono wystąpiło, skąd się wzięło i usunąć problem.
Z metrykami systemowymi prawie wszystko jest w porządku. Początek każdego monitoringu zaczyna się od metryk systemowych. To jest wykorzystanie procesorów, pamięci, swap, sieci i dysku. Jednak wiele parametrów nie jest domyślnie dostępnych.
Jeśli z wykorzystaniem procesora wszystko jest w porządku, to z wykorzystaniem dysku są problemy. Zazwyczaj programiści dodają informacje o przepustowości. Może być to w iops lub bajtach. Ale zapominają o latencji i wykorzystaniu urządzeń dyskowych. To są ważniejsze parametry, które umożliwiają ocenę, jak bardzo obciążone są dyski i jak bardzo spowalniają. Jeśli mamy wysoką latencję, to oznacza, że występują jakieś problemy z dyskami. Jeśli mamy wysokie wykorzystanie, to oznacza, że dyski nie spełniają oczekiwań. To są bardziej jakościowe charakterystyki niż przepustowość.
Choć tę statystykę można również uzyskać z systemu plików /proc, tak jak to się robi dla wykorzystania procesorów. Dlaczego tej informacji nie dodają do monitoringu, nie wiem. Jednakże ważne jest, aby to posiadać w swoim monitoringu.
To samo dotyczy interfejsów sieciowych. Są informacje o przepustowości sieci w pakietach, w bajtach, ale nie ma informacji o latencji i nie ma informacji o wykorzystaniu, chociaż to też jest przydatna informacja.
Wszystkie monitoringi mają wady. I jakiegokolwiek monitoringu byś nie wziął, zawsze będzie on niezgodny z jakimiś kryteriami. Jednak rozwijają się, dodawane są nowe funkcje, nowe rzeczy, więc wybierz coś i dopracuj.
Aby dopracowywać, zawsze trzeba mieć świadomość, co oznacza przekazywana statystyka i jak można poprzez nią rozwiązywać problemy.
I kilka kluczowych punktów:
- Zawsze trzeba monitorować dostępność, mieć pulpity nawigacyjne, aby szybko ocenić, czy z bazą wszystko w porządku.
- Zawsze trzeba mieć pojęcie o tym, którzy klienci korzystają z Twojej bazy danych, aby wykluczać złych klientów.
- Ważne jest ocenianie sposobu, w jaki ci klienci korzystają z danych. Należy mieć świadomość swojego obciążenia roboczego.
- Ważne jest, aby ocenić, jak kształtuje się to obciążenie robocze oraz jakie zapytania są w tym używane. Możesz oceniać zapytania, optymalizować je, refaktoryzować i tworzyć dla nich indeksy. To jest bardzo istotne.
- Procesy w tle mogą negatywnie wpływać na zapytania klientów, dlatego ważne jest, aby monitorować, by nie zużywały zbyt wielu zasobów.
- Metryki systemowe pozwalają Ci planować skalowanie oraz zwiększenie pojemności Twoich serwerów, więc również ważne jest ich śledzenie i ocena.
Jeśli interesuje Cię ten temat, możesz przejrzeć te linki.
— to oficjalna dokumentacja z kolekcjami statystyk. Znajdziesz tam opis wszystkich widoków statystycznych oraz opis pól. Możesz je przeczytać, zrozumieć i przeanalizować, a następnie na ich podstawie tworzyć swoje grafiki i dodawać do swoich monitorowań.
Przykłady zapytań:
To nasze korporacyjne repozytorium, a także moje osobiste. Zawiera przykłady zapytań. Nie ma tam zapytań w stylu select * from coś tam. To gotowe zapytania z łączeniami, wykorzystujące ciekawe funkcje, które pozwalają z surowych danych przekształcać je w czytelne, wygodne wartości, tzn. są to bajty, czas. Możesz je badać, przeglądać, analizować, dodawać do swoich monitorowań, tworzyć na ich podstawie własne monitorowania.
Pytania
Pytanie: Powiedziałeś, że nie będziesz reklamować marek, ale jestem ciekawy – jakich pulpitów używasz w swoich projektach?
Odpowiedź: Różnie. Czasem przychodzimy do klienta, a on już ma swoje monitorowanie. Konsultujemy klienta, co należy dodać do jego monitorowania. Najgorzej jest z Zabbiх, ponieważ nie ma możliwości tworzenia wykresów TopN. Sami używamy , ponieważ konsultowaliśmy tych ludzi w kwestii monitorowania. Robią monitorowanie PostgreSQL na podstawie naszego specyfikacji. Piszę mój projekt typu pet, który zbiera dane przez Prometheus i wizualizuje je w . Mam zadanie stworzyć własny eksporter w Prometheus i następnie wizualizować wszystko w Grafana.
Pytanie: Czy istnieją jakieś analogie raportów AWR lub ... agregacji? Wiecie coś na ten temat?
Odpowiedź: Tak, wiem, co to jest AWR, to świetna rzecz. Obecnie istnieje wiele różnych rozwiązań, które realizują mniej więcej tę samą ideę. W pewnych odstępach czasowych zapisywane są pewne baseline'y do tego samego PostgreSQL lub do oddzielnego magazynu. Można je znaleźć w internecie, są dostępne. Jeden z twórców takiego rozwiązania udziela się na forum sql.ru w wątku PostgreSQL. Można go tam złapać. Tak, takie rozwiązania istnieją i można je używać. Dodatkowo w swoim też piszę coś, co pozwala na to samo.
P.S.1 Jeśli korzystasz z postgres_exporter, to z jakiego dashboardu korzystasz? Jest ich kilka. Są już przestarzałe. Może społeczność stworzy zaktualizowany szablon?
P.S.2 Usunąłem pganalyze, ponieważ jest to komercyjna oferta SaaS skupiająca się na monitorowaniu wydajności i automatycznych sugestiach dostrajania.
Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. , proszę.
Jaki self-hosted monitoring PostgreSQL (z dashboardem) uważasz za najlepszy?
30,0%Zabbix + dodatki od Aleksieja Lesowskiego lub zabbix 4.4 albo 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 to komercyjna oferta SaaS — nie mogę usunąć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
Zagłosowało 10 użytkowników. Wstrzymało się 26 użytkowników.
Źródło: habr.com
