Sugeruję przeczytanie transkrypcji raportu Aleksieja Lesowskiego z Data Egret „Podstawy monitorowania PostgreSQL”
W tym raporcie Aleksiej Lesowski opowie o kluczowych punktach statystyk postgresowych, co one oznaczają i dlaczego powinny być obecne w monitoringu; o tym, jakie wykresy powinny znajdować się w monitoringu, jak je dodawać i jak je interpretować. Raport będzie przydatny dla administratorów baz danych, administratorów systemów i programistów zainteresowanych rozwiązywaniem problemów z Postgres.
Nazywam się Alexey Lesovsky, reprezentuję firmę Data Egret.
Kilka słów o mnie. Zacząłem dawno temu jako administrator systemu.
Administrowałem różnymi systemami Linux, pracowałem nad różnymi rzeczami związanymi z Linuksem, tj. wirtualizacją, monitorowaniem, pracowałem z proxy itp. Jednak w pewnym momencie zacząłem więcej pracować z bazami danych, PostgreSQL. Naprawdę go lubiłem. W pewnym momencie zacząłem pracować nad PostgreSQL przez większość mojego czasu pracy. I tak stopniowo zostałem administratorem danych PostgreSQL.
Przez całą moją karierę zawodową zawsze interesowałem się tematyką statystyki, monitoringu i telemetrii. Kiedy byłem administratorem systemu, bardzo blisko współpracowałem z Zabbixem. Napisałem mały zestaw skryptów, takich jak . W swoim czasie był dość popularny. I tam można było monitorować bardzo różne ważne rzeczy, nie tylko Linuksa, ale także różne komponenty.
Teraz pracuję nad PostgreSQL. Piszę już kolejną rzecz, która pozwala na pracę ze statystykami PostgreSQL. Nazywa się to (artykuł o Habré - ).
Mała uwaga wprowadzająca. Jakie sytuacje mają nasi klienci, nasi klienci? Wystąpił jakiś wypadek związany z bazą danych. A kiedy baza danych została już przywrócona, przychodzi kierownik działu lub kierownik ds. rozwoju i mówi: „Przyjaciele, musimy monitorować bazę danych, bo wydarzyło się coś złego i trzeba temu zapobiec w przyszłości”. I tu rozpoczyna się ciekawy proces wyboru systemu monitorowania lub adaptacji istniejącego systemu monitorowania tak, aby można było monitorować swoją bazę danych - PostgreSQL, MySQL lub jakieś inne. A koledzy zaczynają sugerować: „Słyszałem, że jest taka a taka baza danych. Wykorzystajmy to.” Koledzy zaczynają się ze sobą kłócić. I na koniec okazuje się, że wybieramy jakąś bazę danych, ale monitorowanie PostgreSQL jest w niej dość słabo przedstawione i zawsze trzeba coś dodać. Weź kilka repozytoriów z GitHub, sklonuj je, dostosuj skrypty i w jakiś sposób dostosuj je. I ostatecznie kończy się to na jakiejś pracy ręcznej.
Dlatego w tym wykładzie postaram się przekazać Państwu wiedzę na temat wyboru monitorowania nie tylko dla PostgreSQL, ale także dla bazy danych. I da Ci wiedzę, która pozwoli Ci dokończyć monitorowanie, aby odnieść z niego jakieś korzyści, abyś mógł z korzyścią monitorować swoją bazę danych, aby szybko zapobiec ewentualnym sytuacjom awaryjnym, które mogą się pojawić.
Pomysły, które znajdą się w tym raporcie, można bezpośrednio dostosować do dowolnej bazy danych, niezależnie od tego, czy jest to DBMS, czy noSQL. Dlatego istnieje nie tylko PostgreSQL, ale będzie wiele przepisów, jak to zrobić w PostgreSQL. Będą przykłady zapytań, przykłady encji, które PostgreSQL ma do monitorowania. A jeśli twój DBMS ma te same rzeczy, które pozwalają ci je monitorować, możesz je również dostosować, dodać i będzie dobrze.
Nie będzie mnie w raporcie
porozmawiaj o tym, jak dostarczać i przechowywać metryki. O dalszym przetwarzaniu danych i udostępnianiu ich użytkownikowi nie będę już wspominał. I nie będę mówił nic o ostrzeganiu.
Ale w miarę rozwoju historii będę pokazywać różne zrzuty ekranu z istniejącego monitoringu i w jakiś sposób je krytykować. Niemniej jednak postaram się nie wymieniać marek, aby nie tworzyć reklamy lub antyreklamy dla tych produktów. Dlatego wszystkie zbiegi okoliczności są przypadkowe i zależą od Twojej wyobraźni.
Najpierw zastanówmy się, czym jest monitorowanie. Monitorowanie to bardzo ważna rzecz. Każdy to rozumie. Ale jednocześnie monitoring nie dotyczy produktu biznesowego i nie wpływa bezpośrednio na zysk firmy, dlatego czas zawsze przeznaczany jest na monitoring rezydualny. Jeśli mamy czas, to robimy monitoring, jeśli nie mamy czasu, to OK, odłożymy to na backlog i kiedyś wrócimy do tych zadań.
Dlatego z naszej praktyki wynika, że gdy przychodzimy do klientów, monitoring jest często niekompletny i nie ma w nim żadnych ciekawych rzeczy, które pomogłyby nam lepiej pracować z bazą danych. Dlatego zawsze należy zakończyć monitorowanie.
Bazy danych to tak złożone obiekty, że również należy je monitorować, ponieważ bazy danych są repozytorium informacji. A informacja jest dla firmy bardzo ważna, nie można jej w żaden sposób utracić. Jednocześnie bazy danych są bardzo złożonymi elementami oprogramowania. Składają się z dużej liczby elementów. Wiele z tych elementów wymaga monitorowania.
Jeśli mówimy konkretnie o PostgreSQL, można go przedstawić w formie schematu składającego się z dużej liczby komponentów. Składniki te oddziałują na siebie. Jednocześnie PostgreSQL posiada tzw. podsystem Stats Collector, który umożliwia zbieranie statystyk dotyczących działania tych podsystemów i zapewnia administratorowi lub użytkownikowi pewnego rodzaju interfejs, dzięki któremu może przeglądać te statystyki.
Statystyki te prezentowane są w postaci pewnego zestawu funkcji i widoków. Można je również nazwać tabelami. Oznacza to, że używając zwykłego klienta psql, możesz połączyć się z bazą danych, dokonać wyboru tych funkcji i widoków oraz uzyskać pewne liczby dotyczące działania podsystemów PostgreSQL.
Możesz dodać te liczby do swojego ulubionego systemu monitorowania, rysować wykresy, dodawać funkcje i uzyskiwać analizy w dłuższej perspektywie.
Jednak w tym raporcie nie omówię wszystkich tych funkcji w całości, bo mogłoby to zająć cały dzień. Dosłownie odniosę się do dwóch, trzech lub czterech kwestii i powiem, w jaki sposób pomagają one w lepszym monitorowaniu.
A jeśli mówimy o monitorowaniu baz danych, to co należy monitorować? Przede wszystkim musimy monitorować dostępność, ponieważ baza danych jest usługą zapewniającą klientom dostęp do danych i musimy monitorować dostępność, a także podać niektóre jej cechy jakościowe i ilościowe.
Musimy także monitorować klientów łączących się z naszą bazą danych, ponieważ mogą to być zarówno zwykli klienci, jak i szkodliwi klienci, którzy mogą uszkodzić bazę danych. Należy ich także monitorować i śledzić ich działania.
Kiedy klienci łączą się z bazą danych, oczywiste jest, że zaczynają pracować z naszymi danymi, dlatego musimy monitorować, jak klienci pracują z danymi: z jakimi tabelami i w mniejszym stopniu z jakimi indeksami. Oznacza to, że musimy ocenić obciążenie pracą tworzone przez naszych klientów.
Ale obciążenie pracą obejmuje oczywiście także prośby. Aplikacje łączą się z bazą danych, uzyskują dostęp do danych za pomocą zapytań, dlatego ważne jest, aby ocenić, jakie zapytania mamy w bazie, monitorować ich adekwatność, czy nie są krzywo napisane, czy niektóre opcje wymagają przepisania i dorobienia, aby działały szybciej i z lepszą wydajnością.
A ponieważ mówimy o bazie danych, baza danych jest zawsze procesami w tle. Procesy działające w tle pomagają utrzymać wydajność bazy danych na dobrym poziomie, dlatego też wymagają do działania określonej ilości zasobów. Jednocześnie mogą nakładać się na zasoby żądań klientów, więc zachłanne procesy w tle mogą bezpośrednio wpływać na wydajność żądań klientów. Dlatego też należy je również monitorować i śledzić, aby nie doszło do zakłóceń procesów zachodzących w tle.
A wszystko to w zakresie monitorowania baz danych pozostaje w metryce systemowej. Biorąc jednak pod uwagę, że większość naszej infrastruktury przenosi się do chmur, wskaźniki systemowe pojedynczego hosta zawsze schodzą na dalszy plan. Ale w bazach danych są one nadal istotne i oczywiście konieczne jest również monitorowanie wskaźników systemowych.
Z metrykami systemowymi wszystko jest mniej więcej w porządku, wszystkie nowoczesne systemy monitorowania już obsługują te metryki, ale ogólnie rzecz biorąc, niektóre komponenty nadal nie wystarczą i pewne rzeczy należy dodać. Dotknę ich również, będzie o nich kilka slajdów.
Pierwszym punktem planu jest dostępność. Czym jest dostępność? Dostępność w moim rozumieniu to zdolność bazy do obsługi połączeń, czyli baza jest podnoszona, jako usługa przyjmuje połączenia od klientów. A dostępność tę można ocenić na podstawie pewnych cech. Wyświetlanie tych cech na pulpitach nawigacyjnych jest bardzo wygodne.
Każdy wie, czym są dashboardy. To moment, w którym rzucisz okiem na ekran, na którym podsumowane są niezbędne informacje. Możesz natychmiast określić, czy występuje problem w bazie danych, czy nie.
W związku z tym dostępność bazy danych i inne kluczowe cechy powinny być zawsze wyświetlane na dashboardach, aby te informacje były pod ręką i zawsze dostępne. Niektóre dodatkowe szczegóły, które już pomagają w badaniu incydentów, podczas badania niektórych sytuacji awaryjnych, należy je już umieścić na dodatkowych pulpitach nawigacyjnych lub ukryć w łączach do drążenia, które prowadzą do systemów monitorowania innych firm.
Przykład jednego dobrze znanego systemu monitorowania. To bardzo fajny system monitorowania. Zbiera mnóstwo danych, ale z mojego punktu widzenia ma dziwną koncepcję dashboardów. Znajduje się tam link do „utwórz panel kontrolny”. Ale kiedy tworzysz dashboard, tworzysz listę dwóch kolumn, listę wykresów. A kiedy już chcesz na coś popatrzeć, zaczynasz klikać myszką, przewijać, szukać odpowiedniego wykresu. A to wymaga czasu, bo nie ma dashboardów jako takich. Są tylko listy wykresów.
Co dodać do tych dashboardów? Możesz zacząć od takiej cechy, jak czas reakcji. PostgreSQL ma widok pg_stat_statements. Domyślnie jest wyłączony, ale jest to jeden z ważnych widoków systemowych, który zawsze powinien być włączony i używany. Przechowuje informacje o wszystkich uruchomionych zapytaniach, które zostały wykonane w bazie danych.
W związku z tym możemy zacząć od tego, że możemy wziąć całkowity czas realizacji wszystkich żądań i podzielić go przez liczbę żądań, korzystając z powyższych pól. Ale to jest średnia temperatura w szpitalu. Możemy zacząć od innych pól – minimalnego czasu wykonania zapytania, maksymalnego i mediany. Możemy nawet budować percentyle; PostgreSQL ma do tego odpowiednie funkcje. I możemy uzyskać pewne liczby, które charakteryzują czas odpowiedzi naszej bazy dla już zrealizowanych żądań, czyli nie wykonujemy fałszywego żądania „wybierz 1” i patrzymy na czas odpowiedzi, ale analizujemy czas odpowiedzi dla już zrealizowanych żądań i losujemy albo oddzielny rysunek, albo budujemy na jego podstawie wykres.
Ważne jest także monitorowanie liczby błędów, jakie na bieżąco generuje system. I do tego możesz użyć widoku pg_stat_database. Skupiamy się na polu xact_rollback. To pole pokazuje nie tylko liczbę wycofań, które występują w bazie danych, ale uwzględnia również liczbę błędów. Relatywnie rzecz biorąc, możemy wyświetlić tę liczbę na naszym pulpicie nawigacyjnym i zobaczyć, ile aktualnie mamy błędów. Jeśli występuje dużo błędów, jest to dobry powód, aby zajrzeć do dzienników i sprawdzić, jakiego rodzaju są to błędy i dlaczego występują, a następnie zainwestować w nie i je rozwiązać.
Można dodać coś takiego jak obrotomierz. Są to liczba transakcji na sekundę i liczba żądań na sekundę. Relatywnie rzecz biorąc, możesz użyć tych liczb jako bieżącej wydajności bazy danych i obserwować, czy występują szczyty liczby żądań, szczyty transakcji lub odwrotnie, czy baza danych nie jest niedociążona z powodu awarii jakiegoś backendu. Ważne jest, aby zawsze patrzeć na tę liczbę i pamiętać, że w przypadku naszego projektu tego rodzaju wydajność jest normalna, ale wartości powyżej i poniżej są już w pewnym sensie problematyczne i niezrozumiałe, co oznacza, że musimy przyjrzeć się, dlaczego te liczby są tak wysoki.
W celu oszacowania ilości transakcji ponownie możemy odwołać się do widoku pg_stat_database. Możemy dodać liczbę zatwierdzeń i liczbę wycofań i uzyskać liczbę transakcji na sekundę.
Czy wszyscy rozumieją, że w jednej transakcji może zmieścić się kilka żądań? Dlatego TPS i QPS są nieco inne.
Liczbę żądań na sekundę można uzyskać z pg_stat_statements i po prostu obliczyć sumę wszystkich zrealizowanych żądań. Oczywiste jest, że porównujemy bieżącą wartość z poprzednią, odejmujemy ją, otrzymujemy deltę i otrzymujemy ilość.
W razie potrzeby możesz dodać dodatkowe wskaźniki, które również pomogą ocenić dostępność naszej bazy danych i monitorować, czy wystąpiły jakiekolwiek przestoje.
Jednym z tych wskaźników jest czas sprawności. Ale czas pracy w PostgreSQL jest nieco trudny. Powiem ci dlaczego. Po uruchomieniu PostgreSQL rozpoczyna się raportowanie czasu pracy. Ale jeśli w pewnym momencie, na przykład, jakieś zadanie było wykonywane w nocy, pojawił się OOM-killer i na siłę zakończył proces potomny PostgreSQL, to w tym przypadku PostgreSQL kończy połączenie wszystkich klientów, resetuje obszar pamięci podzielonej na fragmenty i rozpoczyna odzyskiwanie z ostatni punkt kontrolny. I dopóki trwa to przywracanie z punktu kontrolnego, baza danych nie akceptuje połączeń, tj. tę sytuację można ocenić jako przestój. Ale licznik czasu pracy nie zostanie zresetowany, ponieważ uwzględnia czas uruchomienia postmastera od pierwszej chwili. Dlatego takie sytuacje można pominąć.
Powinieneś także monitorować liczbę pracowników próżniowych. Czy wszyscy wiedzą, czym jest autovacuum w PostgreSQL? To interesujący podsystem w PostgreSQL. Napisano o niej wiele artykułów, powstało wiele raportów. Istnieje wiele dyskusji na temat próżni i tego, jak powinna ona 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 elementy bezużyteczne, który czyści przestarzałe wersje wierszy, które nie są potrzebne w żadnej transakcji i zwalnia miejsce w tabelach i indeksach na nowe wiersze.
Dlaczego musisz to monitorować? Bo odkurzanie czasem bardzo boli. Zużywa dużą ilość zasobów, w wyniku czego żądania klientów zaczynają ucierpieć.
I należy to monitorować poprzez widok pg_stat_activity, o którym opowiem w następnej sekcji. Ten widok pokazuje bieżącą aktywność w bazie danych. Dzięki temu działaniu możemy śledzić liczbę odkurzaczy, które obecnie pracują. Możemy śledzić próżnie i zobaczyć, że jeśli przekroczyliśmy limit, to jest to powód, aby zajrzeć do ustawień PostgreSQL i jakoś zoptymalizować działanie próżni.
Kolejną rzeczą związaną z PostgreSQL jest to, że PostgreSQL ma dość długich transakcji. Zwłaszcza w przypadku transakcji, które wiszą przez długi czas i nic nie robią. Jest to tak zwana statystyka bezczynności w transakcji. Taka transakcja blokuje zamki i uniemożliwia działanie próżni. W rezultacie stoły puchną i powiększają się. Zapytania współpracujące z tymi tabelami zaczynają działać wolniej, ponieważ trzeba przenieść wszystkie stare wersje wierszy z pamięci na dysk i z powrotem. Dlatego też należy monitorować czas, czas trwania najdłuższych transakcji i najdłuższych żądań próżniowych. A jeśli widzimy, że niektóre procesy działają od bardzo długiego czasu, już dłużej niż 10-20-30 minut dla obciążenia OLTP, to musimy zwrócić na nie uwagę i na siłę je zakończyć lub zoptymalizować aplikację tak, aby nie dzwonią i nie wiszą tak długo. W przypadku obciążenia analitycznego normalne jest 10-20-30 minut, zdarzają się jednak dłuższe.
Następnie mamy opcję z podłączonymi klientami. Kiedy już stworzyliśmy dashboard i zamieściliśmy na nim kluczowe wskaźniki dostępności, możemy tam także dodać dodatkowe informacje o podłączonych klientach.
Informacje o połączonych klientach są ważne, ponieważ z perspektywy PostgreSQL klienci są różni. Są dobrzy klienci i są źli klienci.
Prosty przykład. Przez klienta rozumiem aplikację. Aplikacja połączyła się z bazą danych i natychmiast zaczyna tam wysyłać swoje żądania, baza danych je przetwarza i wykonuje, a wyniki zwraca klientowi. To dobrzy i poprawni klienci.
Są sytuacje, gdy klient się połączył, utrzymuje połączenie, ale nic nie robi. Jest w stanie bezczynności.
Ale są źli klienci. Przykładowo ten sam klient podłączył się, otworzył transakcję, zrobił coś w bazie danych, a następnie wszedł do kodu, aby np. uzyskać dostęp do zewnętrznego źródła lub tam przetworzyć otrzymane dane. Transakcji jednak nie sfinalizował. A transakcja wisi w bazie danych i jest trzymana w zamku na linii. To jest zły stan. A jeśli nagle aplikacja gdzieś w sobie zawiedzie z wyjątkiem, transakcja może pozostać otwarta przez bardzo długi czas. A to bezpośrednio wpływa na wydajność PostgreSQL. PostgreSQL będzie wolniejszy. Dlatego ważne jest, aby w odpowiednim czasie wyśledzić takich klientów i na siłę zakończyć ich pracę. A trzeba zoptymalizować swoją aplikację, żeby takie sytuacje nie miały miejsca.
Inni źli klienci czekają na klientów. Ale stają się źli z powodu okoliczności. Na przykład prosta bezczynna transakcja: może otworzyć transakcję, zablokować niektóre linie, a następnie gdzieś w kodzie zakończy się niepowodzeniem, pozostawiając zawieszoną transakcję. Przyjdzie inny klient i zażąda tych samych danych, ale napotka blokadę, ponieważ zawieszona transakcja zawiera już blokady w niektórych wymaganych wierszach. Druga transakcja będzie się zawieszać, czekając na zakończenie pierwszej transakcji lub wymuszenie jej zamknięcia przez administratora. Dlatego oczekujące transakcje mogą się kumulować i wypełniać limit połączeń z bazą danych. A po zapełnieniu limitu aplikacja nie może już współpracować z bazą danych. Jest to już sytuacja awaryjna dla projektu. Dlatego należy śledzić złych klientów i reagować na nie w odpowiednim czasie.
Kolejny przykład monitoringu. A tutaj jest już porządny dashboard. Informacje o połączeniach znajdują się powyżej. Złącze DB – 8 sztuk. I to wszystko. Nie mamy informacji o tym, którzy klienci są aktywni, a którzy są po prostu bezczynni i nic nie robią. Nie ma informacji o oczekujących transakcjach i oczekujących połączeniach, czyli jest to liczba pokazująca liczbę połączeń i tyle. A potem zgadnij sam.
W związku z tym, 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 PostgreSQL, to jest to bardzo dobry widok, który powinien zostać Twoim przyjacielem, ponieważ pokazuje bieżącą aktywność w PostgreSQL, czyli co się w nim dzieje. Dla każdego procesu znajduje się osobna linia, w której wyświetlane są informacje o tym procesie: z jakiego hosta nawiązano połączenie, z jakiego użytkownika, pod jaką nazwą, kiedy transakcja została rozpoczęta, jakie żądanie jest aktualnie realizowane, jakie żądanie zostało wykonane jako ostatnie. W związku z tym możemy ocenić stan klienta za pomocą pola stat. Relatywnie rzecz biorąc, możemy pogrupować według tego pola i uzyskać statystyki, które aktualnie znajdują się w bazie danych oraz liczbę połączeń, które mają tę statystykę w bazie danych. A otrzymane już liczby możemy przesłać do naszego monitoringu i na ich podstawie rysować wykresy.
Ważne jest również, aby ocenić czas trwania transakcji. Mówiłem już, że ważna jest ocena czasu trwania próżni, ale transakcje oceniane są w ten sam sposób. Istnieją pola xact_start i query_start. Relatywnie mówiąc, pokazują czas rozpoczęcia transakcji i czas rozpoczęcia żądania. Korzystamy z funkcji now(), która pokazuje bieżący znacznik czasu i odejmujemy znacznik czasu transakcji i żądania. I dostajemy czas trwania transakcji, czas trwania żądania.
Jeśli widzimy długie transakcje, powinniśmy je już sfinalizować. W przypadku obciążenia OLTP długie transakcje trwają już dłużej niż 1-2-3 minuty. W przypadku obciążenia OLAP długie transakcje są normalne, ale jeśli zajmują więcej niż dwie godziny, jest to również znak, że gdzieś mamy przekrzywienie.
Gdy klienci połączą się z bazą danych, rozpoczynają pracę z naszymi danymi. Mają dostęp do tabel, uzyskują dostęp do indeksów, aby pobrać dane z tabeli. Ważne jest, aby ocenić, w jaki sposób klienci wchodzą w interakcję z tymi danymi.
Jest to konieczne, aby ocenić nasze obciążenie pracą i z grubsza zrozumieć, które stoły są dla nas „najgorętsze”. Jest to potrzebne na przykład w sytuacjach, gdy chcemy umieścić „gorące” stoły na jakimś szybkim dysku SSD. Na przykład niektóre tabele archiwów, których nie używaliśmy od dłuższego czasu, można przenieść do jakiegoś „zimnego” archiwum, na dyski SATA i pozwolić im tam żyć, będą dostępne w razie potrzeby.
Jest to również przydatne do wykrywania anomalii po wszelkich wydaniach i wdrożeniach. Załóżmy, że projekt wydał nową funkcję. Na przykład dodaliśmy nową funkcjonalność do pracy z bazą danych. Jeśli narysujemy wykresy wykorzystania tabeli, możemy łatwo wykryć te anomalie na tych wykresach. Na przykład aktualizuj serie lub usuwaj serie. Będzie to bardzo widoczne.
Anomalie można także wykryć w „zmiennych” statystykach. Co to znaczy? PostgreSQL ma bardzo silny i bardzo dobry harmonogram zapytań. A twórcy poświęcają dużo czasu na jego rozwój. Jak on pracuje? Aby móc robić dobre plany, PostgreSQL zbiera statystyki dotyczące rozkładu danych w tabelach w określonym przedziale czasu i z określoną częstotliwością. Oto najczęstsze wartości: liczba unikalnych wartości, informacja o NULL w tabeli, dużo informacji.
Na podstawie tych statystyk planista konstruuje kilka zapytań, wybiera najbardziej optymalne i wykorzystuje ten plan zapytań do samodzielnego wykonania zapytania i zwrócenia danych.
A zdarza się, że statystyki „pływają”. Dane jakościowe i ilościowe w jakiś sposób zmieniły się w tabeli, ale statystyki nie zostały zebrane. A utworzone plany mogą nie być optymalne. A jeśli nasze plany okażą się nieoptymalne, na podstawie zebranego monitoringu, opartego na tabelach, będziemy mogli dostrzec te anomalie. Np. gdzieś dane zmieniły się jakościowo i zamiast indeksu zaczęto stosować sekwencyjne przejście przez tabelę, tj. jeśli zapytanie ma zwrócić tylko 100 wierszy (limit wynosi 100), wówczas dla tego zapytania zostanie przeprowadzone pełne wyszukiwanie. A to zawsze ma bardzo zły wpływ na wydajność.
I widzimy to w monitoringu. I już spójrz na to zapytanie, wyjaśnij je, zbierz statystyki, zbuduj nowy dodatkowy indeks. I już odpowiedz na ten problem. Dlatego to ważne.
Kolejny przykład monitoringu. Myślę, że wiele osób go rozpoznało, ponieważ jest bardzo popularny. Kto tego używa w swoich projektach ? Kto używa tego produktu w połączeniu z Prometheusem? Faktem jest, że w standardowym repozytorium tego monitorowania znajduje się pulpit nawigacyjny do pracy z PostgreSQL - Prometeusz. Ale jest jeden zły szczegół.
Istnieje kilka wykresów. A bajty są oznaczone jako jedność, tj. jest 5 wykresó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 krotce (wiersze). W związku z tym te wykresy są bardzo dobrym sposobem na kilkukrotne, dziesiątki niedoszacowania obciążenia pracą, ponieważ krotka nie jest bajtem, krotka jest ciągiem znaków, ma wiele bajtów i zawsze ma zmienną długość. Oznacza to, że obliczanie obciążenia w bajtach przy użyciu krotek jest zadaniem nierealistycznym lub bardzo trudnym. Dlatego też, korzystając z dashboardu lub wbudowanego monitoringu, zawsze ważne jest, aby zrozumieć, że działa on poprawnie i zwraca prawidłowo ocenione dane.
Jak uzyskać statystyki dotyczące tych tabel? W tym celu PostgreSQL ma pewną rodzinę widoków. A główny widok jest . User_tables - oznacza tabele utworzone w imieniu użytkownika. Natomiast istnieją widoki systemowe, z których korzysta sam PostgreSQL. Istnieje tabela podsumowująca Alltables, która obejmuje zarówno tabele systemowe, jak i użytkownika. Możesz zacząć od dowolnego z nich, który najbardziej Ci się podoba.
Korzystając z powyższych pól możesz oszacować liczbę wstawień, aktualizacji i usunięć. Przykładowy dashboard, którego użyłem, wykorzystuje te pola do oceny charakterystyki obciążenia. Dlatego też możemy na nich bazować. Warto jednak pamiętać, że są to krotki, a nie bajty, więc nie możemy tego zrobić po prostu w bajtach.
Na podstawie tych danych możemy zbudować tzw. tabele TopN. Na przykład Top-5, Top-10. Możesz także śledzić te gorące stoły, które są poddawane recyklingowi częściej niż inne. Na przykład 5 „gorących” stołów do wstawienia. Korzystając z tych tabel TopN, oceniamy nasze obciążenie pracą i możemy oceniać impulsy obciążenia po wszelkich wydaniach, aktualizacjach i wdrożeniach.
Ważne jest również, aby ocenić rozmiar tabeli, ponieważ czasami programiści wdrażają nową funkcję, a nasze tabele zaczynają puchnąć swoimi dużymi rozmiarami, ponieważ zdecydowali się dodać dodatkową ilość danych, ale nie przewidzieli, jak to będzie wpływają na wielkość bazy danych. Takie przypadki również są dla nas niespodzianką.
A teraz małe pytanie do Ciebie. Jakie pytanie pojawia się, gdy zauważysz obciążenie serwera bazy danych? Jakie masz następne pytanie?
Ale w rzeczywistości pytanie powstaje w następujący sposób. Jakie żądania powoduje obciążenie? Oznacza to, że przyglądanie się procesom wywołanym obciążeniem nie jest interesujące. Oczywiste jest, że jeśli host ma bazę danych, to baza danych jest tam uruchomiona i jasne jest, że tylko bazy danych zostaną tam usunięte. Jeśli otworzymy Top, zobaczymy tam listę procesów w PostgreSQL, które coś robią. Od Top 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 daje większy zysk niż dostrajanie konfiguracji PostgreSQL lub systemu operacyjnego, czy nawet dostrajanie sprzętu. Według moich szacunków jest to około 80-85-90%. A dzieje się to znacznie szybciej. Szybciej jest poprawić żądanie niż poprawić konfigurację, zaplanować ponowne uruchomienie, zwłaszcza jeśli nie można ponownie uruchomić bazy danych, lub dodać sprzęt. Łatwiej jest gdzieś przepisać zapytanie lub dodać indeks, aby uzyskać lepszy wynik z tego zapytania.
W związku z tym konieczne jest monitorowanie wniosków i ich adekwatności. Weźmy inny przykład monitorowania. I tutaj także wydaje się, że monitoring jest doskonały. Są informacje o replikacji, są informacje o przepustowości, blokowaniu, wykorzystaniu zasobów. Wszystko w porządku, ale nie ma informacji o prośbach. Nie jest jasne, jakie zapytania są uruchamiane w naszej bazie danych, jak długo trwają i ile jest tych zapytań. Zawsze musimy mieć te informacje w naszym monitorowaniu.
Aby uzyskać te informacje, możemy skorzystać z modułu pg_stat_statements. Na jego podstawie można budować różnorodne wykresy. Można na przykład uzyskać informacje o najczęściej występujących zapytaniach, czyli o tych zapytaniach, które są wykonywane najczęściej. Tak, po wdrożeniu bardzo przydatne jest przyjrzenie się temu i sprawdzenie, czy nastąpił wzrost liczby żądań.
Można monitorować najdłuższe zapytania, czyli te, których wykonanie zajmuje najwięcej czasu. Działają na procesorze, zużywają wejścia/wyjścia. Możemy to również ocenić za pomocą pól total_time, mean_time, blk_write_time i blk_read_time.
Możemy oceniać i monitorować najcięższe żądania pod względem wykorzystania zasobów, te, które odczytują z dysku, które działają z pamięcią lub odwrotnie, powodują pewnego rodzaju obciążenie zapisem.
Możemy ocenić najbardziej hojne prośby. Są to zapytania, które zwracają dużą liczbę wierszy. Może to być na przykład żądanie, w którym zapomniano ustawić limit. Po prostu zwraca całą zawartość tabeli lub zapytania w tabelach, których dotyczy zapytanie.
Można także monitorować zapytania korzystające z plików tymczasowych lub tabel tymczasowych.
Nadal mamy procesy w tle. Procesy w tle to przede wszystkim punkty kontrolne lub nazywane są także punktami kontrolnymi, są to autopróżnia i replikacja.
Kolejny przykład monitoringu. Po lewej stronie znajduje się zakładka Konserwacja, przejdź do niej i miej nadzieję, że zobaczysz coś przydatnego. Ale tutaj jest tylko czas działania próżni i zbierania statystyk, nic więcej. To bardzo uboga informacja, dlatego zawsze musimy mieć informację o tym, jak w naszej bazie działają procesy działające w tle i czy są jakieś problemy z ich pracą.
Kiedy patrzymy na punkty kontrolne, powinniśmy pamiętać, że punkty kontrolne usuwają brudne strony z obszaru pamięci podzielonej na dysk na dysk, a następnie tworzą punkt kontrolny. Ten punkt kontrolny można następnie wykorzystać jako miejsce do odzyskiwania, jeśli PostgreSQL zostanie nagle zamknięty w sytuacji awaryjnej.
W związku z tym, aby opróżnić wszystkie „brudne” strony na dysk, musisz wykonać pewną ilość zapisu. I z reguły w systemach z dużą ilością pamięci jest to dużo. A jeśli będziemy robić punkty kontrolne bardzo często w krótkich odstępach czasu, wówczas wydajność dysku spadnie bardzo znacząco. A żądania klientów będą ucierpiały z powodu braku zasobów. Będą konkurować o zasoby i brak im produktywności.
W związku z tym poprzez pg_stat_bgwriter korzystając z określonych pól możemy monitorować liczbę występujących punktów kontrolnych. A jeśli mamy dużo punktów kontrolnych w określonym przedziale czasu (za 10-15-20 minut, za pół godziny), na przykład 3-4-5, to może to już stanowić problem. A trzeba już zajrzeć do bazy, zajrzeć do konfiguracji, co powoduje taką ilość punktów kontrolnych. Być może trwają jakieś duże nagrania. Możemy już ocenić obciążenie pracą, ponieważ dodaliśmy już wykresy obciążenia. Możemy już dostosować parametry punktów kontrolnych i upewnić się, że nie wpływają one znacząco na wydajność zapytań.
Wracam ponownie do automatycznej próżni, ponieważ, jak powiedziałem, jest to coś, co może z łatwością zsumować wydajność dysku i zapytań, dlatego zawsze ważne jest oszacowanie ilości automatycznej próżni.
Liczba pracowników autovacuum w bazie danych jest ograniczona. Domyślnie jest ich trzech, więc jeśli w bazie danych zawsze pracuje trzech pracowników, oznacza to, że nasza autopróżnia nie jest skonfigurowana, musimy podnieść limity, zweryfikować ustawienia autovacuum i wejść w konfigurację.
Ważne jest, aby ocenić, jakich mamy pracowników odkurzających. Albo został uruchomiony przez użytkownika, przyszedł DBA i ręcznie uruchomił pewnego rodzaju próżnię, co spowodowało obciążenie. Mamy pewien problem. Albo jest to liczba odkurzaczy, które odkręcają licznik transakcji. W przypadku niektórych wersji PostgreSQL są to bardzo ciężkie odkurzacze. Mogą też łatwo zsumować wyniki, ponieważ czytają całą tabelę, skanują wszystkie bloki w tej tabeli.
I oczywiście czas trwania odkurzacza. Jeśli mamy odkurzacze trwałe, które działają bardzo długo, oznacza to, że ponownie musimy zwrócić uwagę na konfigurację odkurzacza i być może ponownie rozważyć jego ustawienia. Ponieważ może zaistnieć sytuacja, gdy próżnia pracuje na stole przez dłuższy czas (3-4 godziny), ale w czasie pracy próżni, w stole ponownie zgromadziła się duża ilość martwych rzędów. A gdy tylko odkurzanie się zakończy, musi ponownie odkurzyć ten stół. I dochodzimy do sytuacji – niekończącej się próżni. I w tym przypadku próżnia nie radzi sobie ze swoją pracą, a tabele stopniowo zaczynają puchnąć, chociaż ilość przydatnych danych pozostaje taka sama. Dlatego podczas długich próżni zawsze patrzymy na konfigurację i staramy się ją zoptymalizować, ale jednocześnie tak, aby nie ucierpiała wydajność żądań klientów.
Obecnie praktycznie nie ma instalacji PostgreSQL, która nie posiadałaby replikacji strumieniowej. Replikacja to proces przenoszenia danych z wzorca do repliki.
Replikacja w PostgreSQL odbywa się poprzez dziennik transakcji. Kreator generuje dziennik transakcji. Dziennik transakcji przesyłany jest połączeniem sieciowym do repliki, a następnie jest odtwarzany w replice. To proste.
W związku z tym widok pg_stat_replication służy do monitorowania opóźnienia replikacji. Ale nie wszystko jest z nią proste. W wersji 10 widok przeszedł kilka zmian. Po pierwsze, zmieniono nazwy niektórych pól. Dodano także niektóre pola. W wersji 10 pojawiły się pola pozwalające oszacować opóźnienie replikacji w sekundach. To jest bardzo wygodne. Przed wersją 10 możliwe było oszacowanie opóźnienia replikacji w bajtach. Ta opcja pozostaje w wersji 10, czyli możesz wybrać co jest dla Ciebie wygodniejsze - oszacuj opóźnienie w bajtach lub oszacuj opóźnienie w sekundach. Wiele osób robi jedno i drugie.
Niemniej jednak, aby ocenić opóźnienie replikacji, musisz znać pozycję dziennika w transakcji. Te pozycje dziennika transakcji znajdują się dokładnie w widoku pg_stat_replication. Relatywnie rzecz biorąc, możemy pobrać dwa punkty z dziennika transakcji za pomocą funkcji pg_xlog_location_diff(). Oblicz różnicę między nimi i uzyskaj opóźnienie replikacji w bajtach. Jest to bardzo wygodne i proste.
W wersji 10 nazwa tej funkcji została zmieniona na pg_wal_lsn_diff(). Ogólnie rzecz biorąc, we wszystkich funkcjach, widokach i narzędziach, w których pojawiło się słowo „xlog”, zostało ono zastąpione wartością „wal”. Dotyczy to zarówno widoków, jak i funkcji. To taka innowacja.
Dodatkowo w wersji 10 dodano linie, które wyraźnie pokazują opóźnienie. Są to opóźnienie zapisu, opóźnienie spłukiwania i opóźnienie odtwarzania. Oznacza to, że ważne jest monitorowanie tych rzeczy. Jeśli zauważymy, że mamy opóźnienie replikacji, musimy zbadać, dlaczego się pojawiło, skąd się wzięło i naprawić problem.
Prawie wszystko jest w porządku, jeśli chodzi o metryki systemowe. Kiedy rozpoczyna się monitorowanie, zaczyna się ono od wskaźników systemowych. Jest to rozdysponowanie procesorów, pamięci, wymiany, sieci i dysku. Jednak wiele parametrów nie jest tam domyślnie dostępnych.
Jeśli wszystko jest w porządku z procesem recyklingu, występują problemy z recyklingiem dysku. Z reguły programiści monitorujący dodają informacje o przepustowości. Może być w iops lub bajtach. Zapominają jednak o opóźnieniach i wykorzystaniu urządzeń dyskowych. Są to ważniejsze parametry, które pozwalają nam ocenić, jak obciążone są nasze dyski i jak wolne są. Jeśli mamy duże opóźnienia, oznacza to, że są pewne problemy z dyskami. Jeśli mamy wysokie wykorzystanie, oznacza to, że dyski nie radzą sobie. Są to lepsze cechy niż przepustowość.
Co więcej, statystyki te można również uzyskać z systemu plików /proc, tak jak ma to miejsce w przypadku procesorów recyklingowych. Nie wiem dlaczego ta informacja nie jest dodawana do monitoringu. Niemniej jednak ważne jest, aby mieć to w swoim monitorowaniu.
To samo dotyczy interfejsów sieciowych. Informacje o przepustowości sieci są podawane w pakietach, w bajtach, ale mimo to nie ma informacji o opóźnieniu i wykorzystaniu, chociaż jest to również użyteczna informacja.
Każdy monitoring ma wady. I niezależnie od tego, jaki rodzaj monitoringu podejmiesz, zawsze nie będzie on spełniał pewnych kryteriów. Niemniej jednak rozwijają się, dodawane są nowe funkcje i nowe rzeczy, więc wybierz coś i zakończ to.
Aby zakończyć, musisz zawsze mieć pojęcie, co oznaczają podawane statystyki i jak możesz je wykorzystać do rozwiązywania problemów.
I kilka kluczowych punktów:
- Zawsze warto monitorować dostępność i mieć dashboardy, dzięki którym szybko ocenimy, czy z bazą danych wszystko jest w porządku.
- Zawsze musisz mieć pojęcie o tym, jacy klienci pracują z Twoją bazą danych, aby wyeliminować złych klientów i ich zestrzelić.
- 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 powstaje to obciążenie pracą, za pomocą jakich zapytań. Możesz oceniać zapytania, optymalizować je, refaktoryzować i budować dla nich indeksy. To jest bardzo ważne.
- Procesy w tle mogą negatywnie wpływać na żądania klientów, dlatego ważne jest monitorowanie, czy nie zużywają oni zbyt wielu zasobów.
- Metryki systemowe umożliwiają planowanie skalowania i zwiększania wydajności serwerów, dlatego ważne jest ich śledzenie i ocena.
Jeśli interesuje Cię ten temat, możesz skorzystać z tych linków.
- to jest oficjalna dokumentacja od zbieracza statystyk. Znajduje się w nim opis wszystkich widoków statystycznych oraz opis wszystkich pól. Można je przeczytać, zrozumieć i przeanalizować. I na ich podstawie zbuduj swoje wykresy i dodaj je do swojego monitoringu.
Przykłady zapytań:
To jest nasze repozytorium firmowe i moje własne. Zawierają przykładowe zapytania. Nie ma tam żadnych zapytań z wybranej* z serii. Istnieją już gotowe zapytania z łączeniami, wykorzystujące ciekawe funkcje, które pozwalają zamienić surowe liczby na czytelne, wygodne wartości, czyli są to bajty, czas. Możesz je wyłapywać, przeglądać, analizować, dodawać do swojego monitoringu, budować na ich podstawie swój monitoring.
pytania
Pytanie: Mówiłeś, że nie będziesz reklamował marek, ale mimo to ciekawi mnie, jakich dashboardów używasz w swoich projektach?
Odpowiedź: To zależy. Zdarza się, że przychodzimy do klienta, a on ma już swój własny monitoring. Doradzamy klientowi, co należy dodać do jego monitoringu. Najgorzej jest z Zabbixem. Ponieważ nie ma możliwości budowania wykresów TopN. Sami używamy , ponieważ konsultowaliśmy się z tymi chłopakami w sprawie monitoringu. Monitorowali PostgreSQL w oparciu o nasze specyfikacje techniczne. Piszę własny projekt zwierzaka, który zbiera dane za pośrednictwem Prometheusa i renderuje je . Moje zadanie polega na stworzeniu własnego eksportera w Prometheusie i następnie wyrenderowaniu wszystkiego w Grafanie.
Pytanie: Czy istnieją analogie raportów AWR lub... agregacji? Czy wiecie o czymś takim?
Odpowiedź: Tak, wiem, co to jest AWR, to fajna rzecz. W tej chwili istnieje wiele rowerów, które realizują w przybliżeniu następujący model. W pewnym odstępie czasu niektóre linie bazowe są zapisywane w tym samym PostgreSQL lub w oddzielnym magazynie. Możesz poszukać ich w Google, są tam. Jeden z twórców czegoś takiego siedzi na forum sql.ru w wątku PostgreSQL. Można go tam złapać. Tak, są takie rzeczy, można je wykorzystać. Plus w swoim Piszę też coś, co pozwala ci zrobić to samo.
PS1 Jeśli używasz postgres_exporter, jakiego pulpitu nawigacyjnego używasz? Jest ich kilka. Są już przestarzałe. Może społeczność stworzy zaktualizowany szablon?
PS2 Usunięto pganalyze, ponieważ jest to zastrzeżona oferta 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óre samodzielne monitorowanie postgresql (z pulpitem nawigacyjnym) uważasz za najlepsze?
-
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 usługa 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