Proponuję przeczytać transkrypcję raportu Aleksieja Lesowskiego z Data Egret „Podstawy monitorowania PostgreSQL”
W tym raporcie Aleksiej Lesowski omówi kluczowe punkty statystyk post-Gross, ich znaczenie i powody, dla których powinny być uwzględniane w monitoringu; o tym, jakie wykresy powinny znaleźć się w monitoringu, jak je dodawać i jak je interpretować. Prelekcja będzie przydatna dla administratorów baz danych, administratorów systemów i deweloperów zainteresowanych rozwiązywaniem problemów z systemem Postgres.
Nazywam się Aleksiej Lesowski, reprezentuję Data Egret.
Kilka słów o mnie. Zaczynałem dawno temu jako administrator systemów.
Администрировал всякие разные Linux, занимался разными вещами, связанными с Linux, т. е. виртуализацией, мониторингом, работал с прокси и т. д. Но в какой-то момент я стал заниматься больше базами данных, PostgreSQL. Он мне очень нравился. И в какой-то момент я стал заниматься PostgreSQL основную часть своего рабочего времени. И так постепенно я стал PostgreSQL DBA.
Przez całą moją karierę interesowały mnie zagadnienia statystyki, monitoringu i telemetrii. Gdy byłem administratorem systemu, bardzo ściśle współpracowałem z Zabbixem. I napisałem mały zestaw skryptów, takich jak . Он был довольно популярным в свое время. И там можно было мониторить очень разные важные штуки, не только Linux, но еще разные компоненты.
Teraz już pracuję z PostgreSQL. Piszę już coś innego, co pozwoli Ci pracować ze statystykami PostgreSQL. To się nazywa (artykuł na temat Habr — ).
Krótkie wprowadzenie. Z jakimi sytuacjami spotykają się nasi klienci? Wystąpił jakiś błąd związany z bazą danych. A gdy baza danych została już przywrócona, przychodzi kierownik działu lub kierownik rozwoju i mówi: „Przyjaciele, musimy monitorować bazę danych, ponieważ wydarzyło się coś złego i musimy upewnić się, że to się nie zdarzy w przyszłości”. I tutaj zaczyna się ciekawy proces wyboru systemu monitorującego lub dostosowania istniejącego systemu monitorującego tak, aby można było monitorować bazę danych – PostgreSQL, MySQL lub inną. A koledzy zaczynają sugerować: „Słyszałem, że jest taka a taka baza danych. Wykorzystajmy ją”. Koledzy zaczynają się ze sobą kłócić. A na końcu okazuje się, że wybieramy jakąś bazę danych, ale monitorowanie PostgreSQL jest w niej reprezentowane raczej słabo i ciągle musimy coś zmieniać. Weź kilka repozytoriów z GitHub, sklonuj je, dostosuj skrypty i jakoś je dopracuj. A na końcu przeradza się to w jakiś rodzaj pracy ręcznej.
W tym wystąpieniu postaram się przekazać Wam wiedzę na temat tego, jak wybierać monitoring nie tylko dla PostgreSQL, ale także dla bazy danych. I aby przekazać Ci wiedzę, która pozwoli Ci udoskonalić monitorowanie, tak abyś mógł czerpać z niego korzyści, abyś mógł monitorować swoją bazę danych z korzyścią, a także abyś mógł na czas ostrzegać o wszelkich nadchodzących sytuacjach awaryjnych, które mogą się pojawić.
A pomysły przedstawione w tym raporcie można bezpośrednio zaadaptować do dowolnej bazy danych, niezależnie od tego, czy jest to DBMS czy noSQL. Nie chodzi tu tylko o PostgreSQL, ale będzie tam wiele przepisów na to, jak to zrobić w PostgreSQL. Będą przykłady zapytań, przykłady encji, które są monitorowane w PostgreSQL. A jeśli Twój system DBMS ma te same elementy, które pozwalają na ich monitorowanie, możesz je także dostosować, dodać i będzie dobrze.
Nie będzie mnie w raporcie
porozmawiajmy o tym, jak dostarczać i przechowywać dane pomiarowe. Nie będę się wypowiadał na temat późniejszego przetwarzania danych i udostępniania ich użytkownikowi. A o ostrzeganiu nie wspomnę.
Ale w miarę rozwoju opowieści będę pokazywał zrzuty ekranów istniejących systemów monitorujących i w pewien sposób je krytykował. Postaram się jednak nie podawać nazw marek, aby nie tworzyć reklamy lub antyreklamy tych produktów. Dlatego też wszelkie zbiegi okoliczności są przypadkowe i pozostają w naszej wyobraźni.
Najpierw wyjaśnijmy, czym jest monitorowanie. Monitorowanie jest bardzo ważną rzeczą. Każdy to rozumie. Jednocześnie jednak monitoring nie jest związany z produktem biznesowym i nie wpływa bezpośrednio na zysk przedsiębiorstwa, dlatego też czas poświęcany jest zawsze na monitoring rezydualny. Jeśli mamy czas, to monitorujemy, jeśli nie, to OK, umieścimy to w zaległościach i wrócimy do tych zadań pewnego dnia.
Dlatego z naszego doświadczenia wynika, że gdy przychodzimy do klientów, monitoring jest często słabo rozwinięty i nie zawiera żadnych ciekawych rzeczy, które pomogłyby nam lepiej pracować z bazą danych. Dlatego monitoring należy stale udoskonalać.
Bazy danych są na tyle złożone, że wymagają monitorowania, ponieważ stanowią magazyn informacji. A informacja ta jest bardzo ważna dla firmy; nie można go w żaden sposób utracić. Jednakże bazy danych są bardzo złożonymi programami. Składają się z dużej liczby komponentów. Wiele z tych elementów wymaga monitorowania.
Jeśli mówimy konkretnie o PostgreSQL, to można go przedstawić jako schemat składający się z dużej liczby komponentów. Elementy te oddziałują na siebie wzajemnie. Jednocześnie PostgreSQL posiada tzw. podsystem Stats Collector, który umożliwia zbieranie statystyk dotyczących działania tych podsystemów i udostępnia administratorowi lub użytkownikowi odpowiedni interfejs, aby mógł przeglądać te statystyki.
Statystyki te są prezentowane jako zbiór funkcji i widoków. Można je również nazwać tabelami. Oznacza to, że korzystając ze zwykłego klienta psql, można połączyć się z bazą danych, wybrać te funkcje i widoki oraz uzyskać konkretne liczby dotyczące działania podsystemów PostgreSQL.
Możesz dodać te liczby do swojego ulubionego systemu monitorowania, rysować wykresy, dodawać funkcje i uzyskiwać długoterminowe analizy.
Jednak w tym wystąpieniu nie będę omawiał wszystkich tych funkcji, ponieważ zajęłoby to cały dzień. Odniosę się dosłownie do dwóch, trzech lub czterech rzeczy i powiem, jak pomagają one usprawnić monitorowanie.
A jeśli mówimy o monitorowaniu bazy danych, co należy monitorować? Przede wszystkim musimy monitorować dostępność, ponieważ baza danych jest usługą zapewniającą klientom dostęp do danych, a my musimy monitorować dostępność, a także dostarczać niektóre jakościowe i ilościowe charakterystyki.
Musimy również monitorować klientów łączących się z naszą bazą danych, ponieważ mogą to być zarówno zwykli klienci, jak i złośliwi klienci, którzy mogą uszkodzić bazę danych. Należy je również monitorować i śledzić ich działania.
Gdy klienci łączą się z bazą danych, oczywiste jest, że zaczynają pracować z naszymi danymi, musimy więc monitorować, w jaki sposób klienci pracują z danymi: z którymi tabelami i, w mniejszym stopniu, z którymi indeksami. Oznacza to, że musimy ocenić obciążenie pracą, jakie generują nasi klienci.
Ale praca składa się też, rzecz jasna, z próśb. Aplikacje łączą się z bazą danych, uzyskują dostęp do danych za pomocą zapytań, dlatego ważne jest, aby oceniać, jakie zapytania mamy w bazie danych, monitorować ich adekwatność, aby nie były napisane krzywo, aby niektóre opcje nie wymagały przepisania i wykonania, aby działały szybciej i wydajniej.
A skoro mowa o bazie danych, to baza danych jest zawsze procesem działającym w tle. Procesy działające w tle pomagają utrzymać wydajność bazy danych na dobrym poziomie, dlatego do swojego działania wymagają pewnej ilości zasobów. Jednocześnie mogą one nakładać się na zasoby żądań klienta, co oznacza, że zachłanne procesy działające w tle mogą bezpośrednio wpływać na wydajność żądań klienta. Dlatego też należy je również monitorować i śledzić, aby mieć pewność, że nie wystąpi żadna nierównowaga w zakresie procesów zachodzących w tle.
A wszystko to w zakresie monitorowania baz danych, pozostaje w metrykach systemowych. Jednak biorąc pod uwagę fakt, że większość naszej infrastruktury przenosi się do chmury, parametry systemowe pojedynczego hosta schodzą na dalszy plan. Ale w bazach danych są one nadal istotne i oczywiście konieczne jest monitorowanie metryk systemowych.
Jeśli chodzi o metryki systemowe, wszystko jest mniej więcej w porządku, wszystkie nowoczesne systemy monitorowania już je obsługują, ale ogólnie rzecz biorąc, niektóre komponenty wciąż są niewystarczające i pewne rzeczy trzeba dodać. Wspomnę także o nich, będzie kilka slajdów na ich temat.
Pierwszym punktem planu jest dostępność. Czym jest dostępność? W moim rozumieniu dostępność to zdolność bazy do obsługi połączeń, tzn. baza jest uruchomiona i działa, jako usługa, przyjmując połączenia od klientów. Dostępność tę można ocenić na podstawie pewnych cech. Cechy te są bardzo wygodne do wyświetlania na pulpicie nawigacyjnym.
Każdy wie, czym są pulpity nawigacyjne. Polega ona na tym, że wystarczy jedno spojrzenie na ekran, na którym znajdują się niezbędne informacje. Dzięki temu można od razu stwierdzić, czy w bazie danych występuje problem, czy nie.
W związku z tym dostępność bazy danych i inne kluczowe cechy powinny być zawsze wyświetlane na pulpitach, aby informacje te były zawsze pod ręką i w pobliżu. Niektóre dodatkowe szczegóły, które są pomocne w badaniu incydentów lub w badaniu niektórych sytuacji awaryjnych, muszą zostać umieszczone w dodatkowych panelach sterowania lub ukryte w linkach umożliwiających przejście do systemów monitorujących innych firm.
Przykład jednego z dobrze znanych systemów monitorujących. To naprawdę fajny system monitorowania. Gromadzi wiele danych, ale moim zdaniem ma dziwną koncepcję pulpitów nawigacyjnych. Jest link do „utworzenia pulpitu nawigacyjnego”. Ale kiedy tworzysz pulpit nawigacyjny, tworzysz pewnego rodzaju listę z dwiema kolumnami, pewnego rodzaju listę wykresów. A gdy potrzebujesz coś zobaczyć, zaczynasz klikać myszką, przewijać, szukać odpowiedniego wykresu. A to zajmuje czas, bo nie ma żadnych tablic rozdzielczych. Istnieją tylko listy wykresów.
Co należy dodać do tych pulpitów nawigacyjnych? Można zacząć od takiej cechy jak czas reakcji. PostgreSQL ma widok pg_stat_statements. Domyślnie jest on wyłączony, jednak jest to jeden z ważniejszych widoków systemowych, który zawsze powinien być włączony i używany. Przechowuje informacje o wszystkich zapytaniach, które zostały wykonane w bazie danych.
Zatem możemy zacząć od tego, że całkowity czas wykonania wszystkich żądań możemy podzielić przez liczbę żądań, korzystając z pól wymienionych powyżej. Ale to jest średnia temperatura w szpitalu. Możemy zacząć od innych pól – minimalnego, maksymalnego i medianowego czasu wykonania zapytania. I możemy nawet budować percentyle; PostgreSQL ma odpowiednie funkcje do tego celu. Możemy uzyskać pewne liczby charakteryzujące czas reakcji naszej bazy danych na już wykonane żądania, tzn. nie wykonujemy fałszywego żądania „select 1” i nie sprawdzamy czasu reakcji, ale analizujemy czas reakcji na już wykonane żądania i rysujemy osobną liczbę lub budujemy na jej podstawie wykres.
Ważne jest również śledzenie liczby błędów generowanych na bieżąco przez system. W tym celu można wykorzystać widok pg_stat_database. Skupimy się na polu xact_rollback. Pole to pokazuje nie tylko liczbę wycofań zmian w bazie danych, ale także uwzględnia liczbę błędów. Mówiąc konwencjonalnie, możemy wyświetlić tę liczbę na naszym pulpicie i sprawdzić, ile błędów występuje w danym momencie. Jeśli błędów jest dużo, to już dobry powód, aby zajrzeć do logów i sprawdzić, jakiego rodzaju są to błędy i dlaczego występują, a następnie podjąć działania i je rozwiązać.
Możesz dodać coś takiego jak obrotomierz. Jest to liczba transakcji na sekundę i liczba żądań na sekundę. Mówiąc ogólnie, możesz użyć tych liczb jako bieżącej wydajności swojej bazy danych i zaobserwować, czy występują szczyty żądań, szczyty transakcji lub odwrotnie, czy baza danych nie jest niedociążona z powodu awarii jakiegoś zaplecza. Ważne jest, aby zawsze patrzeć na te liczby i pamiętać, że w naszym projekcie tego typu wydajność jest normalna, a wartości wyższe i niższe są już problematyczne i niejasne, co oznacza, że musimy zastanowić się, dlaczego te liczby się tam znajdują.
Aby oszacować liczbę transakcji, możemy ponownie odwołać się do widoku pg_stat_database. Możemy dodać liczbę zatwierdzeń i liczbę wycofań, aby uzyskać liczbę transakcji na sekundę.
Czy wszyscy rozumieją, że kilka żądań może zmieścić się w jednej transakcji? Dlatego TPS i QPS nieco się różnią.
Liczbę zapytań na sekundę można uzyskać z pg_stat_statements i po prostu obliczyć sumę wszystkich wykonanych zapytań. Oczywiste jest, że porównujemy obecną wartość z poprzednią, odejmujemy, otrzymujemy deltę, otrzymujemy ilość.
Jeśli chcesz, możesz dodać dodatkowe wskaźniki, które pomogą ocenić dostępność naszej bazy danych i sprawdzić, czy nie wystąpiły jakieś przestoje.
Jednym z takich wskaźników jest czas sprawności. Jednak dostępność bazy danych PostgreSQL to nieco skomplikowana sprawa. Powiem ci dlaczego. Po uruchomieniu PostgreSQL zaczyna raportować czas sprawności. Ale jeśli w pewnym momencie, na przykład w nocy, podczas wykonywania jakiegoś zadania pojawił się OOM-killer i siłą zakończył proces potomny PostgreSQL, wówczas w takim przypadku PostgreSQL zakończy połączenie wszystkich klientów, zresetuje podzielony obszar pamięci i rozpocznie odzyskiwanie od ostatniego punktu kontrolnego. W czasie odzyskiwania danych z punktu kontrolnego baza danych nie przyjmuje połączeń, czyli sytuację tę można uznać za przestoj. Jednak licznik czasu sprawności nie zostanie zresetowany, ponieważ bierze pod uwagę czas uruchomienia postmastera od samego początku. Dlatego takie sytuacje można pominąć.
Należy również monitorować liczbę pracowników zajmujących się odkurzaniem. Czy wszyscy wiedzą, czym jest autovacuum w PostgreSQL? To ciekawy podsystem w PostgreSQL. Napisano o niej wiele artykułów, powstało wiele raportów. Dużo dyskutuje się na temat próżni i tego, jak ona powinna działać. Wielu uważa to za zło konieczne. Ale tak właśnie jest. Jest to swego rodzaju odpowiednik modułu zbierającego śmieci, który usuwa przestarzałe wersje wierszy, które nie są już potrzebne żadnej transakcji, i zwalnia miejsce w tabelach i indeksach na nowe wiersze.
Dlaczego konieczne jest monitorowanie tego? Bo próżnia czasami bardzo boli. Pochłania mnóstwo zasobów, a to negatywnie wpływa na wymagania klientów.
Należy to monitorować za pomocą widoku pg_stat_activity, o którym opowiem w następnej sekcji. Ten widok pokazuje bieżącą aktywność w bazie danych. Dzięki tej aktywności możemy śledzić liczbę odkurzaczy działających w danej chwili. Możemy śledzić odkurzacze i zobaczyć, że jeśli przekroczyliśmy limit, to jest to powód, aby przyjrzeć się ustawieniom PostgreSQL i w jakiś sposób zoptymalizować działanie odkurzacza.
Kolejną cechą PostgreSQL jest to, że PostgreSQL jest bardzo uciążliwy w przypadku długich transakcji. Zwłaszcza w przypadku transakcji, które wiszą przez długi czas i nic się nie dzieje. Są to tzw. statystyki bezczynności w transakcji. Taka transakcja utrzymuje zamki, uniemożliwiając działanie odkurzacza. W efekcie tabele puchną i zwiększają swoje rozmiary. A zapytania działające na tych tabelach zaczynają działać wolniej, ponieważ muszą kopiować wszystkie stare wersje wierszy z pamięci na dysk i z powrotem. Dlatego też należy monitorować także czas trwania najdłuższych transakcji i najdłuższych żądań odkurzania. A jeśli widzimy jakieś procesy, które działają przez bardzo długi czas, ponad 10-20-30 minut w przypadku obciążenia OLTP, to powinniśmy zwrócić na nie uwagę i wymusić ich zakończenie lub zoptymalizować aplikację tak, aby nie były wywoływane i nie zawieszały się przez tak długi czas. W przypadku obciążenia pracą analityczną normą jest 10-20-30 minut, ale czasami może to potrwać dłużej.
Następnie mamy opcję z podłączonymi klientami. Po utworzeniu pulpitu nawigacyjnego i umieszczeniu na nim najważniejszych wskaźników dostępności możemy również dodać dodatkowe informacje o podłączonych klientach.
Informacje o podłączonych klientach są istotne, ponieważ z perspektywy PostgreSQL klienci występują w różnych formach. Są dobrzy klienci i źli klienci.
Prosty przykład. Przez klienta mam na myśli aplikację. Aplikacja łączy się z bazą danych i natychmiast zaczyna wysyłać do niej swoje żądania, baza danych je przetwarza i wykonuje, a wyniki zwraca klientowi. To są dobrzy i odpowiedni klienci.
Są sytuacje, gdy klient nawiązał połączenie, utrzymuje je, ale nic nie robi. Jest w stanie bezczynności.
Ale zdarzają się źli klienci. Na przykład ten sam klient połączył się, otworzył transakcję, wykonał jakąś czynność w bazie danych, a następnie wszedł do kodu, powiedzmy, w celu uzyskania dostępu do zewnętrznego źródła lub przetworzenia tam otrzymanych danych. Ale nie zamknął transakcji. A transakcja zawiesza się w bazie danych i blokuje wiersz. To zły stan. A jeśli nagle aplikacja gdzieś w sobie ulegnie awarii z powodu wyjątku, transakcja może pozostać otwarta przez bardzo długi czas. Ma to bezpośredni wpływ na wydajność PostgreSQL. PostgreSQL będzie działał wolniej. Dlatego ważne jest, aby na bieżąco śledzić takich klientów i skutecznie kończyć z nimi współpracę. Musisz zoptymalizować swoją aplikację, aby takie sytuacje nie miały miejsca.
Inni źli klienci to klienci czekający. Ale stają się źli z powodu okoliczności. Na przykład prosta bezczynna transakcja: może otworzyć transakcję, założyć blokady na kilka linii, a następnie w którymś momencie kodu nastąpi awaria, pozostawiając zawieszoną transakcję. Przyjdzie inny klient i zażąda tych samych danych, ale napotka blokadę, ponieważ ta zawieszona transakcja już posiada blokady na niektórych niezbędnych wierszach. Druga transakcja zostanie zawieszona w oczekiwaniu na zakończenie pierwszej transakcji lub jej przymusowe zamknięcie przez administratora. W rezultacie może dojść do kumulacji oczekujących transakcji i przepełnienia limitu połączeń z bazą danych. A gdy limit zostanie przekroczony, aplikacja nie będzie mogła już pracować z bazą danych. Jest to już sytuacja kryzysowa dla projektu. Dlatego też należy monitorować nieuczciwych klientów i reagować na nich w odpowiednim czasie.
Inny przykład monitorowania. A oto już porządny panel. Informacje o połączeniach znajdują się powyżej. Połączenie DB – 8 sztuk. I to wszystko. Nie mamy informacji o tym, którzy klienci są aktywni, a którzy po prostu nie robią nic. Nie ma informacji o oczekujących transakcjach i oczekujących połączeniach, tzn. jest to liczba pokazująca liczbę połączeń i tyle. A potem zgadnij sam.
Aby dodać te informacje do monitorowania, należy uzyskać dostęp do widoku systemowego pg_stat_activity. Jeśli spędzasz dużo czasu w programie PostgreSQL, jest to bardzo dobry widok, który powinien stać się Twoim przyjacielem, ponieważ pokazuje bieżącą aktywność w programie PostgreSQL, tzn. co się w nim dzieje. Dla każdego procesu istnieje oddzielny wiersz, w którym znajdują się informacje o tym procesie: z jakiego hosta nawiązano połączenie, pod jakim użytkownikiem, pod jaką nazwą, kiedy rozpoczęto transakcję, jakie zapytanie jest aktualnie wykonywane, które zapytanie było wykonywane jako ostatnie. Dzięki temu możemy ocenić status klienta, korzystając z pola statystyk. Mówiąc konwencjonalnie, możemy grupować według tego pola i uzyskać statystyki, które aktualnie znajdują się w bazie danych, a także liczbę połączeń, które mają tę statystykę w bazie danych. Otrzymane już liczby możemy przesłać do naszego systemu monitoringu i na ich podstawie sporządzić wykresy.
Ważne jest również, aby ocenić czas trwania transakcji. Już wcześniej wspominałem, że istotne jest szacowanie czasu trwania próżni, ale transakcje ocenia się dokładnie w ten sam sposób. Istnieją pola xact_start i query_start. Mówiąc prościej, pokazują one czas rozpoczęcia transakcji i czas rozpoczęcia żądania. Bierzemy funkcję now(), która pokazuje bieżący znacznik czasu, i odejmujemy znaczniki czasu transakcji i zapytania. I otrzymujemy czas trwania transakcji i czas trwania żądania.
Jeśli widzimy długie transakcje, powinniśmy już je kończyć. W przypadku obciążenia OLTP długie transakcje trwają już ponad 1-2-3 minuty. W przypadku obciążeń OLAP długie transakcje są czymś normalnym, ale jeśli trwają dłużej niż dwie godziny, to także znak, że gdzieś występuje stronniczość.
Gdy klienci połączą się z bazą danych, zaczną pracować z naszymi danymi. Uzyskują dostęp do tabel i indeksów w celu pobrania danych z tabeli. Ważne jest, aby ocenić, w jaki sposób klienci korzystają z tych danych.
Jest to konieczne, aby ocenić nasze obciążenie pracą i mniej więcej zrozumieć, które tabele są dla nas „najgorętsze”. Przykładowo jest to konieczne w sytuacjach, gdy chcemy umieścić „gorące” tabele na szybkim dysku SSD. Na przykład, niektóre tabele archiwalne, których nie używaliśmy przez dłuższy czas, możemy przenieść do „zimnego” archiwum, na dyski SATA, i pozwolić im tam pozostać, a dostęp do nich będzie możliwy w razie potrzeby.
Przydaje się również do wykrywania anomalii po wydaniach i wdrożeniach. Załóżmy, że projekt wprowadził nową funkcję. Na przykład dodaliśmy nową funkcjonalność do pracy z bazą danych. Jeśli zaś narysujemy wykresy wykorzystania tabel, z łatwością wykryjemy na nich te anomalie. Na przykład aktualizuj serie lub usuwaj serie. To będzie bardzo widoczne.
Możliwe jest również wykrywanie anomalii w „pływających” statystykach. Co to znaczy? PostgreSQL ma bardzo mocny i dobry planer zapytań. A twórcy poświęcają mu mnóstwo czasu. Jak to działa? Aby móc tworzyć dobre plany, PostgreSQL zbiera statystyki dotyczące rozkładu danych w tabelach w określonych odstępach czasu i z określoną częstotliwością. Oto najczęściej występujące wartości: liczba unikalnych wartości, informacje o wartościach NULL w tabeli, dużo informacji.
Na podstawie tych statystyk planista tworzy kilka zapytań, wybiera najbardziej optymalne i używa tego planu do wykonania samego zapytania i zwrócenia danych.
A zdarza się, że statystyki „pływają”. Jakość i ilość danych w tabeli uległy pewnym zmianom, ale statystyki nie zostały zebrane. A opracowane plany mogą nie być optymalne. A jeśli nasze plany okażą się nieoptymalne pod względem zbieranych przez nas danych monitorujących, jeśli chodzi o tabele, będziemy w stanie dostrzec te anomalie. Na przykład, gdzieś dane zmieniły się jakościowo i zamiast indeksu zaczęto stosować sekwencyjne przejście przez tabelę, tj. jeśli zapytanie musi zwrócić tylko 100 wierszy (istnieje limit 100), to dla tego zapytania zostanie przeprowadzone pełne wyszukiwanie. A to zawsze ma bardzo zły wpływ na produktywność.
I będziemy mogli to zaobserwować podczas monitoringu. Następnie przyjrzyj się temu zapytaniu, uruchom dla niego polecenie „explanation”, zbierz statystyki, utwórz nowy, dodatkowy indeks. I już zareagowali na ten problem. Dlatego to jest ważne.
Inny przykład monitorowania. Myślę, że wiele osób go rozpoznało, ponieważ jest bardzo popularny. Kto używa go w swoich projektach? ? Kto używa tego produktu w połączeniu z Prometheusem? Rzecz w tym, że standardowe repozytorium tego monitoringu ma panel do pracy z PostgreSQL – Prometeusz. Ale jest tu jeden zły szczegół.
Istnieje kilka wykresów. A bajty są określane jako jedność, tzn. jest 5 grafów. Są to: Wstaw dane, Aktualizuj dane, Usuń dane, Pobierz dane i Zwróć dane. Jednostką miary są bajty. Rzecz jednak w tym, że statystyki w PostgreSQL zwracają dane w postaci krotek (wierszy). A zatem wykresy te są bardzo dobrym sposobem na kilku-, a nawet kilkudziesięciu-krotne niedoszacowanie obciążenia pracą, ponieważ krotka nie jest bajtem, krotka jest ciągiem znaków, składa się z wielu bajtów i zawsze ma zmienną długość. Oznacza to, że obliczenie obciążenia pracą w bajtach za pomocą krotek jest zadaniem niemożliwym lub bardzo trudnym. Dlatego korzystając z pulpitu nawigacyjnego lub wbudowanego monitoringu, zawsze ważne jest, aby mieć pewność, że działa on prawidłowo i zwraca prawidłowo ocenione dane.
Jak uzyskać statystyki dla tych tabel? W tym celu PostgreSQL ma pewną rodzinę widoków. A najważniejsze jest to, że . User_tables – oznacza to tabele utworzone w imieniu użytkownika. Z kolei widoki systemowe są używane przez samą bazę danych PostgreSQL. Istnieje także tabela podsumowująca Alltables, która zawiera zarówno tabele systemowe, jak i użytkownika. Możesz zacząć od dowolnego, który Ci się najbardziej podoba.
Powyższe pola można wykorzystać do oszacowania liczby wstawień, aktualizacji i usunięć. Przykładowy pulpit nawigacyjny, którego użyłem, wykorzystuje te pola do oceny charakterystyki obciążenia. Dlatego możemy na nich dalej budować. Warto jednak pamiętać, że są to krotki, a nie bajty, więc nie możemy po prostu zrobić z nich bajtów.
Na podstawie tych danych możemy zbudować tzw. tabele TopN. Na przykład: Top-5, Top-10. Możesz także śledzić, które stoliki są częściej wykorzystywane niż inne. Na przykład 5 „gorących” tabel do wstawienia. Na podstawie tabel TopN oceniamy nasze obciążenie i możemy oszacować skoki obciążenia po wszelkiego rodzaju wersjach, aktualizacjach i wdrożeniach.
Ważne jest również oszacowanie rozmiaru tabeli, ponieważ czasami programiści wprowadzają nową funkcję, a nasze tabele zaczynają się powiększać, ponieważ decydują się na dodanie dodatkowej objętości danych, nie przewidując przy tym, jak wpłynie to na rozmiar bazy danych. Takie przypadki również są dla nas zaskoczeniem.
A teraz małe pytanie do Was. Jakie pytanie się pojawia, gdy zauważasz obciążenie serwera z bazą danych? Jakie jest Twoje następne pytanie?
Ale tak naprawdę nasuwa się następujące pytanie. Jakie zapytania generuje obciążenie? Oznacza to, że nie jest interesujące przyglądanie się procesom, które powoduje obciążenie. Oczywiste jest, że jeśli host ma bazę danych, to baza ta jest tam uruchomiona i oczywiste jest, że będą tam wykorzystywane tylko bazy danych. Jeśli otworzymy Top, zobaczymy listę procesów w PostgreSQL, które coś robią. Z góry nie będzie jasne, co robią.
W związku z tym należy znaleźć te zapytania, które powodują największe obciążenie, ponieważ dostrajanie zapytań z reguły przynosi większe korzyści niż dostrajanie konfiguracji PostgreSQL, systemu operacyjnego, a nawet sprzętu. Moim zdaniem jest to około 80-85-90%. I odbywa się to o wiele szybciej. Szybciej jest skorygować żądanie niż poprawić konfigurację, zaplanować ponowne uruchomienie, zwłaszcza jeśli nie można ponownie uruchomić bazy danych, lub dodać sprzęt. Łatwiej jest przepisać zapytanie w innym miejscu lub dodać indeks, aby uzyskać lepszy wynik tego zapytania.
W związku z tym konieczne jest monitorowanie wniosków i ich zasadności. Przyjrzyjmy się innemu przykładowi monitorowania. I tutaj również monitoring wydaje się być doskonały. Znajdują się tam informacje o replikacji, przepustowości, blokowaniu i wykorzystaniu zasobów. Wszystko w porządku, ale nie ma informacji o prośbach. Nie jest jasne, jakie zapytania są wykonywane w naszej bazie danych, jak długo są wykonywane, ani ile jest tych zapytań. Musimy zawsze uwzględniać te informacje w naszym monitoringu.
Aby uzyskać te informacje możemy skorzystać z modułu pg_stat_statements. Na jego podstawie można skonstruować wiele różnych wykresów. Można na przykład uzyskać informacje o najczęściej występujących żądaniach, tj. o żądaniach, które są najczęściej wykonywane. Tak, po wdrożeniu również bardzo przydatne jest sprawdzenie tego i sprawdzenie, czy nastąpił wzrost liczby żądań.
Możesz monitorować najdłużej wykonywane zapytania, tj. te, których wykonanie zajmuje najwięcej czasu. Działają na procesorze i zużywają zasoby wejścia/wyjścia. Możemy to również ocenić, korzystając z pól total_time, mean_time, blk_write_time i blk_read_time.
Możemy oceniać i monitorować najbardziej obciążające zapytania pod kątem wykorzystania zasobów, te, które odczytują dane z dysku, te, które operują na pamięci lub odwrotnie, te, które generują pewnego rodzaju obciążenie związane z zapisem.
Potrafimy ocenić nawet najbardziej hojne prośby. Są to zapytania zwracające dużą liczbę wierszy. Na przykład może to być prośba o zapomnienie o ustawieniu limitu. Zwraca po prostu całą zawartość tabeli lub zapytania we wszystkich żądanych tabelach.
Można także monitorować zapytania korzystające z plików tymczasowych lub tabel tymczasowych.
Pozostają nam procesy działające w tle. Procesy działające w tle to przede wszystkim punkty kontrolne, zwane również punktami kontrolnymi, czyli autopróżnią i replikacją.
Inny przykład monitorowania. Po lewej stronie znajduje się zakładka Konserwacja, kliknij ją i zobacz coś przydatnego. Ale tutaj mamy tylko czas działania próżni i zbierania statystyk, nic więcej. Są to bardzo ograniczone informacje, dlatego zawsze musimy mieć informacje o tym, jak działają procesy działające w tle w naszej bazie danych i czy występują jakieś problemy z ich działaniem.
Przyglądając się punktom kontrolnym, powinniśmy pamiętać, że punkty kontrolne usuwają „brudne” strony z obszaru pamięci shardowej na dysk, a następnie tworzą punkt kontrolny. Ten punkt kontrolny można następnie wykorzystać jako miejsce do przywrócenia działania programu PostgreSQL, jeśli zostanie on zakończony w sytuacji awaryjnej.
Zatem, aby zrzucić na dysk wszystkie „brudne” strony, konieczne jest wykonanie pewnej ilości zapisu. A z reguły w systemach z dużą ilością pamięci jest to dużo. A jeśli punkty kontrolne będą wykonywane bardzo często w krótkich odstępach czasu, wydajność dysku spadnie bardzo gwałtownie. A potrzeby klientów będą ograniczone z powodu braku zasobów. Będą walczyć o zasoby i będą mieć ograniczoną produktywność.
Zatem za pomocą pg_stat_bgwriter możemy monitorować liczbę punktów kontrolnych, które występują przy użyciu określonych pól. A jeśli mamy dużo punktów kontrolnych w określonym przedziale czasowym (10-15-20 minut, pół godziny), na przykład 3-4-5, to już może być problem. A teraz trzeba zajrzeć do bazy danych, sprawdzić konfigurację i sprawdzić, co jest przyczyną tak dużej liczby punktów kontrolnych. Być może trwa jakieś duże nagrywanie. Możemy to już oszacować na podstawie obciążenia pracą, ponieważ dodaliśmy już wykresy obciążenia pracą. Teraz możemy dostroić parametry punktu kontrolnego i upewnić się, że nie wpłyną one znacząco na wydajność zapytania.
Wracam do kwestii automatycznego podciśnienia, ponieważ jest to, jak już wspomniałem, tego typu rozwiązanie pozwala łatwo zwiększyć wydajność zarówno dysków, jak i zapytań. Dlatego zawsze ważne jest oszacowanie wielkości automatycznego podciśnienia.
Liczba pracowników odkurzaczy automatycznych w bazie danych jest ograniczona. Domyślnie jest ich trzy, więc jeśli mamy trzech pracowników stale pracujących w bazie danych, oznacza to, że nasz automatyczny odkurzacz nie jest prawidłowo skonfigurowany. Musimy zwiększyć limity, sprawdzić ustawienia automatycznego odkurzacza, a następnie przejść do konfiguracji.
Ważne jest, aby ocenić, jakiego rodzaju pracowników odkurzających mamy do dyspozycji. Albo został uruchomiony przez użytkownika, albo administrator bazy danych przyszedł i ręcznie uruchomił jakiś rodzaj odkurzacza, co spowodowało obciążenie. Mamy jakiś problem. Albo jest to liczba odkurzaczy obracających licznik transakcji. W przypadku niektórych wersji PostgreSQL są to bardzo ciężkie przypadki. Mogą też łatwo zsumować wydajność, ponieważ odczytują całą tabelę, skanując wszystkie bloki w tej tabeli.
I oczywiście czas działania odkurzaczy. Jeśli mamy odkurzacze, które działają przez bardzo długi czas, oznacza to, że powinniśmy ponownie zwrócić uwagę na konfigurację odkurzacza i ewentualnie rozważyć jego ustawienia. Ponieważ może wystąpić sytuacja, gdy odkurzacz pracuje na stole przez dłuższy czas (3-4 godziny), ale w tym czasie na stole ponownie zgromadzi się duża ilość martwych linii. A gdy już odkurzanie się zakończy, będzie musiał odkurzyć ten stół jeszcze raz. I dochodzimy do sytuacji nieskończonej próżni. I w tym przypadku próżnia nie radzi sobie ze swoją pracą, a tabele stopniowo zaczynają puchnąć, choć ilość przydatnych danych w nich zawartych pozostaje taka sama. Dlatego podczas długich okresów bezczynności zawsze przyglądamy się konfiguracji i staramy się ją zoptymalizować, ale jednocześnie tak, aby wydajność obsługi żądań klienta nie ucierpiała.
Prawie żadna instalacja PostgreSQL nie obsługuje obecnie replikacji strumieniowej. Replikacja to proces przenoszenia danych z urządzenia głównego do repliki.
Replikacja w PostgreSQL jest organizowana za pośrednictwem dziennika transakcji. Master generuje dziennik transakcji. Dziennik transakcji jest przesyłany do repliki za pośrednictwem połączenia sieciowego, a następnie odtwarzany w replice. To proste.
W związku z tym widok pg_stat_replication służy do monitorowania opóźnień replikacji. Jednak nie wszystko jest z nią proste. W wersji 10 widok przeszedł kilka zmian. Po pierwsze, zmieniono nazwy niektórych pól. I dodano kilka pól. Wersja 10 wprowadza pola umożliwiające oszacowanie opóźnienia replikacji w sekundach. To bardzo wygodne. Przed wersją 10 możliwe było oszacowanie opóźnienia replikacji w bajtach. Opcja ta pozostała w wersji 10, tzn. możesz wybrać, co jest dla Ciebie wygodniejsze – oceniać opóźnienie w bajtach czy w sekundach. Wiele osób robi obie rzeczy.
Aby jednak oszacować opóźnienie replikacji, konieczna jest znajomość pozycji dziennika w transakcji. A te pozycje dziennika transakcji znajdują się właśnie w widoku pg_stat_replication. Mówiąc konwencjonalnie, możemy użyć funkcji pg_xlog_location_diff() do pobrania dwóch punktów z dziennika transakcji. Oblicz różnicę między nimi i uzyskaj opóźnienie replikacji w bajtach. To bardzo wygodne i proste rozwiązanie.
W wersji 10 nazwę tej funkcji zmieniono na pg_wal_lsn_diff(). Ogólnie rzecz biorąc, we wszystkich funkcjach, widokach i narzędziach, gdzie napotkano słowo „xlog”, zostało ono zastąpione wartością „wal”. Dotyczy to zarówno widoków, jak i funkcji. To jest prawdziwa innowacja.
Ponadto w wersji 10 dodano linijki pokazujące konkretnie opóźnienie. Są to opóźnienia zapisu, opóźnienia opróżniania i opóźnienia odtwarzania. Ważne jest zatem monitorowanie takich rzeczy. Jeśli zauważymy opóźnienie replikacji, musimy zbadać, dlaczego ono występuje, skąd się wzięło i rozwiązać problem.
Jeśli chodzi o metryki systemowe, prawie wszystko jest w porządku. Rozpoczynając monitorowanie, zaczynamy od pomiarów systemu. Polega na wykorzystaniu procesorów, pamięci, pamięci wymiany, sieci i dysku. Jednak wiele parametrów nie jest dostępnych domyślnie.
Jeżeli wszystko jest w porządku z procesem utylizacji, to znaczy, że wystąpiły problemy z utylizacją dysku. Zazwyczaj programiści monitorujący dodają informacje o przepustowości. Może być podawana w iopsach lub bajtach. Ale zapominają o opóźnieniach i wykorzystaniu dysku. Są to ważniejsze parametry, które pozwalają nam ocenić, jak obciążone są nasze dyski i jak wolne są. Jeżeli opóźnienie jest duże, oznacza to, że występują jakieś problemy z dyskami. Jeżeli mamy do czynienia z wysokim wykorzystaniem, oznacza to, że dyski nie radzą sobie. Są to raczej cechy jakościowe niż przepustowość.
Co więcej, statystyki te można również uzyskać z systemu plików /proc, tak jak robi się to w przypadku wykorzystania procesora. Nie wiem, dlaczego te informacje nie są dodawane do monitoringu. Ważne jest jednak, aby mieć to na uwadze podczas monitorowania.
To samo dotyczy interfejsów sieciowych. Istnieją informacje o przepustowości sieci w pakietach, w bajtach, ale mimo to nie ma informacji o opóźnieniu ani o wykorzystaniu, choć są to również przydatne informacje.
Każdy monitoring ma swoje wady. I bez względu na to, jaki monitoring zastosujesz, zawsze okaże się, że jakieś kryteria nie są spełnione. Niemniej jednak rozwijają się, dodawane są nowe funkcje, nowe rzeczy, więc wybierz coś i dokończ to.
Aby je udoskonalić, zawsze trzeba mieć pojęcie, co oznaczają podawane statystyki i jak można je wykorzystać do rozwiązywania problemów.
I kilka kluczowych punktów:
- Powinieneś stale monitorować dostępność, mieć panele kontrolne, dzięki którym będziesz mógł szybko ocenić, czy wszystko jest w porządku z bazą danych.
- Zawsze musisz mieć pojęcie o tym, jacy klienci korzystają z Twojej bazy danych, aby móc odfiltrować złych klientów i ich zwolnić.
- Ważne jest, aby ocenić, w jaki sposób ci klienci pracują z danymi. Musisz mieć pojęcie o swoim obciążeniu pracą.
- Ważne jest, aby ocenić, w jaki sposób to obciążenie jest kształtowane i za pomocą jakich żądań. Możesz oceniać zapytania, możesz je optymalizować, refaktoryzować i budować dla nich indeksy. To jest bardzo ważne.
- Procesy działające w tle mogą negatywnie wpływać na żądania klientów, dlatego ważne jest, aby je monitorować, aby mieć pewność, że nie wykorzystują zbyt wielu zasobów.
- Metryki systemowe umożliwiają planowanie skalowania i zwiększania pojemności serwerów, dlatego ważne jest, aby je również śledzić i oceniać.
Jeśli interesuje Cię ten temat, możesz skorzystać z poniższych linków.
- jest to oficjalna dokumentacja od osoby gromadzącej dane statystyczne. Opis wszystkich widoków statystycznych i opis wszystkich pól. Możesz je przeczytać, zrozumieć i przeanalizować. Na ich podstawie stwórz własne wykresy i dodaj je do monitoringu.
Przykłady zapytań:
To jest nasze korporacyjne repozytorium i moje własne. Zawierają przykładowe zapytania. Nie ma zapytań serii select* z czegoś. Istnieją już gotowe zapytania z połączeniami, wykorzystujące ciekawe funkcje pozwalające z surowych liczb, czyli bajtów, czasu, uzyskać czytelne, wygodne wartości. Możesz je wybierać, oglądać, analizować, dodawać do monitoringu i na ich podstawie budować własny monitoring.
pytania
Pytanie: Powiedziałeś, że nie będziesz reklamować marek, ale nadal jestem ciekaw – jakiego rodzaju paneli sterowania używasz w swoich projektach?
Odpowiedź: Zależy. Zdarza się, że przyjeżdżamy do klienta, a on już ma swój monitoring. Konsultujemy z klientem, co należy dodać do monitoringu. Najgorzej jest z Zabbiх. Ponieważ nie ma możliwości budowania grafów TopN. Sami tego używamy ponieważ konsultowaliśmy się z tymi ludźmi w sprawie monitoringu. Przeprowadzili monitoring PostgreSQL w oparciu o naszą specyfikację techniczną. Piszę własny projekt hobbystyczny, który zbiera dane za pomocą Prometheusa i renderuje je w . Moim zadaniem jest stworzenie własnego eksportera w Prometheusie, a następnie wyrenderowanie wszystkiego w Grafanie.
Pytanie: Czy istnieją jakieś odpowiedniki raportów AWR lub... agregacji? Czy wiesz o czymś takim?
Odpowiedź: Tak, wiem czym jest AWR, to fajna rzecz. W tej chwili dostępna jest szeroka gama rowerów, które realizują mniej więcej następujący model. W pewnych odstępach czasu niektóre linie bazowe są zapisywane w tej samej bazie danych PostgreSQL lub w oddzielnym magazynie. Możesz je znaleźć w Internecie, bo istnieją. Jeden z twórców takiego rozwiązania zasiada na forum sql.ru w wątku poświęconym PostgreSQL. Można go tam złapać. Tak, takie rzeczy istnieją i można z nich korzystać. Plus w swoim własnym Piszę także coś, co pozwoli ci zrobić to samo.
PS1 Jeśli używasz postgres_exporter, z którego pulpitu korzystasz? Jest ich tam kilka. Są już nieaktualne. Może społeczność stworzy zaktualizowany szablon?
PS2 usunęło pganalyze, ponieważ jest to zastrzeżona usługa SaaS, która koncentruje się na monitorowaniu wydajności i automatycznych sugestiach dotyczących dostrajania.
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. , Proszę.
Który z samodzielnie hostowanych systemów do monitorowania Postgresql (z panelem sterowania) jest Twoim zdaniem najlepszy?
30,0%Zabbix + dodatki od Aleksieja Lesowskiego lub zabbix 4.4 lub 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 zastrzeżona aplikacja SaaS — nie mogę jej 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
Głosowało 10 użytkowników. 26 użytkowników wstrzymało się od głosu.
Źródło: www.habr.com
