Jakie metryki wdrożenia PostgreSQL należy monitorować? Ta seria postów na blogu ma na celu zapewnienie minimalnego, początkowego zestawu podstawowych działań monitorujących, które należy wdrożyć, aby zapewnić kondycję i stabilność serwerów Postgres.
To trzecia i ostatnia część serii blogów, która obejmuje metryki na poziomie tabeli, indeksu i systemu. Pierwsza jedna obejmowała metryki na poziomie klastra, a druga jedna obejmowała metryki na poziomie bazy danych.
Poziom stołu
Zazwyczaj dane w bazie danych podlegają zasadzie 80-20. 20% tabel zawiera większość danych i jest najczęściej dostępnych lub zmutowanych. Ustawienie dodatkowego monitorowania tylko dla tych tabel może zapewnić wgląd, który jest ważny, ale niewielki.
Oto kilka wskaźników na poziomie tabeli, którym warto się przyjrzeć:
1. Rozmiar stołu
Rzeczywisty rozmiar dysku używany przez tabelę musi być monitorowany. W większości przypadków tabela stale rośnie, więc to tempo wzrostu jest bardziej interesujące.
Często zdarza się, że tempo wzrostu zmienia się po wdrożeniu nowej wersji aplikacji lub bazowej zmianie wzorców ruchu/obciążenia/wejściu samej aplikacji. Takie zmiany muszą zostać zbadane, przynajmniej w celu sprawdzenia, czy nowa szybkość jest obsługiwana przez dostarczony sprzęt.
Działanie:monitoruj powiększanie się tabeli w każdym tygodniu/miesiącu, badaj nagłe zmiany.
Jak to zrobić:
-- returns the size for each table
SELECT schemaname || '.' || relname,
pg_size_pretty(pg_table_size(schemaname || '.' || relname))
FROM pg_stat_user_tables;2. Nadmiar stołu
Ze względu na architekturę MVCC Postgresa starsze wersje wierszy leżą w plikach danych fizycznych dla każdej tabeli i są określane jako rozdęcie . Operacja usunięcia przestarzałych wersji wierszy nazywa się próżnia . Postgres uruchamia w tle proces o nazwie autovacuum , który pobiera tabele kandydatów (na podstawie konfigurowalnych parametrów) i odkurza je dla Ciebie.
Bloat spowalnia operacje na stole i marnuje miejsce na dysku, i może uciec, nawet z automatycznym odkurzaniem. Wymagane jest monitorowanie rozdęcia jako bezwzględnej liczby bajtów oraz procentu (martwych danych do wszystkich danych).
Ta metryka może być monitorowana na poziomie pojedynczej tabeli lub jako agregacja w wybranych tabelach lub na poziomie bazy danych.
Działanie:stale monitoruj rozrost tabeli w bajtach i wartościach procentowych, ostrzegaj, jeśli wartości przekraczają ustawiony próg, w razie potrzeby PRÓŻNIJ.
Jak to zrobić:
Użyj check_postgres orpgmetrics, aby uzyskać szacunki wzdęcia. Więcej informacji znajdziesz na wiki.
3. Skany sekwencyjne
Gdy wykonywane są zapytania, które nie wykorzystują optymalnie dostępnych indeksów lub jeśli informacje statystyczne skojarzone z tabelą są zbyt nieaktualne, Postgres może skończyć z koniecznością przechodzenia przez każdy wiersz tabeli. Nazywa się to skanowaniem sekwencyjnym i nie jest zbyt pożądane w ogólnym przypadku. Lepiej byłoby mieć skanowanie indeksu , gdzie wiersze tabeli są dostępne pośrednio poprzez wyszukiwanie indeksu.
PostgreSQL może powiedzieć, ile razy tabela była skanowana sekwencyjnie i ile razy indeks był używany. Możesz użyć tego do monitorowania liczby kolejnych skanów (jeśli chcesz ich całkowicie uniknąć) lub jako procent wszystkich skanów.
Działanie:Stale monitoruj sekw. liczba lub procent skanów, alert, jeśli wartość przekracza ustawiony próg.
Jak to zrobić:
-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
seq_scan,
round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;Poziom indeksu
1. Rozmiar indeksu
Indeksy mogą zajmować dużo miejsca na dysku. Każdy indeks tabeli może sam potencjalnie mieć tyle samo miejsca na dysku, co sama tabela. Przydatne jest obserwowanie całkowitego rozmiaru indeksów w bazie danych lub indeksów ważnych tabel, szczególnie w przypadku wdrożeń, w których indeksy mogą być tworzone przez automatyczne procesy.
Nierozsądnie duże indeksy mogą być spowodowane rozdęciem lub po prostu źle zaprojektowanym indeksem. W obu przypadkach naprawienie przyczyny (poprzez przebudowanie indeksu lub refaktoryzację zapytania/indeksu) może skrócić czasy zapytań, dlatego warto zbadać duże indeksy.
Działanie:Monitoruj łączny rozmiar interesujących indeksów w każdym tygodniu/miesiącu, badaj, gdy są zbyt duże.
Jak to zrobić:
-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
pg_size_pretty(pg_total_relation_size(indexrelid))
FROM pg_stat_user_indexes;2. Nadmiar indeksu
Indeksy też mogą się rozdęć. Istnieje zbyt wiele czynników, w tym obciążenie tabelą, typ indeksu, wersja Postgresa i inne, które decydują o tym, jak nadęty będzie indeks. Rozdęte indeksy mogą spowolnić wstawianie i zmniejszyć wydajność wyszukiwania. Monitoruj rozrost indeksów zarówno jako wartość bezwzględną (liczbę bajtów), jak i jako procent. Indeksy będą musiały zostać odbudowane, gdy staną się zbyt rozdęte.
Działanie:stale monitoruj rozrost indeksu w bajtach i wartościach procentowych, ostrzegaj, jeśli wartości przekraczają ustawiony próg.
Jak to zrobić:
Użyj check_postgres orpgmetrics, aby uzyskać szacunki wzdęcia. Więcej informacji znajdziesz na wiki.
3. Współczynnik trafień w pamięci podręcznej
PostgreSQL buforuje często używane regiony indeksów (a także tabele) w pamięci. Jeśli dostroiłeś swoje zapytania tak, aby nie dotykały tabel z wyjątkiem pobierania wierszy, następnym krokiem jest zapewnienie maksymalnej rezydencji w pamięci podręcznej dla tych ważnych indeksów, które naprawdę przyspieszają Twoje zapytania.
Wykorzystanie pamięci podręcznej indeksu można mierzyć współczynnikiem trafień w pamięci podręcznej, który jest procentem bloków indeksu odczytanych z pamięci podręcznej do całkowitej liczby odczytanych bloków.
Działanie:stale monitoruj procentowy współczynnik trafień w pamięci podręcznej, ostrzegaj, jeśli wartość spadnie poniżej ustawionego progu. Zbadaj niskie wartości ważnych indeksów.
Jak to zrobić:
-- returns the cache hit ratio as a percentage, for each index
SELECT schemaname || '.' || indexrelname AS index_name,
round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 /
pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
FROM pg_stat_user_indexes
WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;Poziom systemu
Oprócz metryk PostgreSQL ważne jest, aby śledzić kilka metryk maszyny lub maszyny wirtualnej, na której działa Twój Postgres. Możesz użyć do tego dowolnego popularnego rozwiązania do monitorowania, a nawet samodzielnie je pobrać i śledzić.
1. Wykorzystana pamięć
Nowoczesne systemy Linux mają złożone rozliczanie pamięci. Zalecamy monitorowanie „pamięci używanej”, czyli pamięci pozostałej po uwzględnieniu pamięci oznaczonej jako wolna , jako bufory , jak buforowany i jako płyta . Bufory i pamięć podręczna ustąpią pod presją, podobnie jak większość (zwykle ponad 95%) płyty.
Jednak używana pamięć musi być mierzona przez odpowiednio długi okres. Jeśli masz zadania wsadowe, raporty, ETL itp., które są uruchamiane w weekendy, okres będzie wynosił jeden tydzień. Prawdziwym wskaźnikiem, który będziesz musiał monitorować, jest maksymalna wykorzystana pamięć w tym okresie.
Zazwyczaj wraz ze wzrostem rozmiaru bazy danych wartość ta ma tendencję do zwiększania się. Musisz upewnić się, że maksymalne wykorzystanie pamięci mieści się w wygodnym limicie dostępnej pamięci, na przykład 60-80%. Zaniedbanie tego spowoduje niepowodzenie obciążeń analitycznych/OLAP z powodu braku pamięci.
Działanie:monitoruj maksymalne wykorzystanie pamięci w ciągu tygodnia/dwóch nocy, ostrzegaj, jeśli przekroczy ustawiony próg, przypisz ponownie.
Jak to zrobić :
Używana pamięć jest podana przez MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab , gdzie Mem* pola pochodzą z /proc/meminfo . Więcej informacji znajdziesz w tym artykule RedHat.
2. Średnie obciążenie
Prosta średnia wartość obciążenia jest nadal najłatwiejszym i najszybszym sposobem oszacowania obciążenia serwera. Jest to szczególnie ważne w przypadku serwerów Postgres, ponieważ każdy backend jest oddzielnym procesem systemu operacyjnego, a posiadanie większej ich liczby w stanie, w którym można uruchomić, zwiększy średnią wartość obciążenia.
W przypadku danego serwera Postgres średnie obciążenie powinno pozostawać w rozsądnym zakresie w cyklu biznesowym (np. przez tydzień, wliczając w to zadania wsadowe).
Działanie:monitoruj średnie maksymalne obciążenie każdego dnia/tygodnia, badaj rosnące trendy.
Jak to zrobić :
Średnie obciążenia 1 minuta, 5 minut i 15 minut to pierwsze 3 pola pierwszego wiersza w pliku /proc/loadavg .
3. Wolne miejsce na dysku
Ostatnia pozycja na naszej liście to najbardziej oczywista pozycja do monitorowania:ilość wolnego miejsca na dysku w każdym systemie plików używanym przez serwer PostgreSQL, w tym obszary tabel, katalogi plików WAL, katalogi kopii zapasowych i pliki dzienników serwera. W przypadkach, gdy w jednym systemie plików tworzonych jest zbyt wiele (100 milionów) plików, upewnij się, że monitorowana jest również liczba wolnych i-węzłów. Brak i-węzłów jest również zgłaszany jako mało miejsca na dysku.
Działanie:stale monitoruj wolne miejsce na dysku i wykorzystanie i-węzłów we wszystkich odpowiednich systemach plików, ostrzegaj, jeśli wartości spadną poniżej ustawionego progu.
Jak to zrobić :
Wolnego miejsca na dysku w systemie plików nie można odzyskać bezpośrednio przez odczytanie dowolnego pliku w /proc . Możesz użyć stat -f /path/to/mount lub nawet df aby znaleźć używane, wolne i zarezerwowane miejsce na dysku dla określonego, zamontowanego systemu plików.
Szybkie informacje
Oto pełna lista wszystkich metryk, które omówiliśmy do tej pory w tej serii. Pamiętaj, że są to tylko minimalne, najbardziej istotne metryki, które musisz monitorować, aby wykryć, kiedy wszystko pójdzie nie tak z wdrożeniem PostgreSQL.
Poziom klastra
- Zakres identyfikatora transakcji
- Liczba backendów
- Nieaktywne gniazda replikacji
- Zaplecze oczekujące na blokady
- Zaplecza bezczynne podczas transakcji
- Opóźnienie replikacji dla aktywnych połączeń
- Opóźnienie replikacji dla gniazd replikacji
- Liczba plików WAL
- Liczba plików WAL gotowych do archiwizacji
Poziom bazy danych
- Połączeni klienci
- Rozmiar
- Nadmiar stołu na wszystkich stołach
- Nadmiar indeksu we wszystkich indeksach
- Długotrwałe transakcje
- Zakleszczenia
- Najstarszy odkurzacz
- Najstarsza analiza
Poziom stołu
- Rozmiar stołu
- Wzdęcia stołu
- Skanowania sekwencyjne
Poziom indeksu
- Rozmiar indeksu
- Wzdęcie indeksu
- Współczynnik trafień w pamięci podręcznej
Poziom systemu
- Wykorzystana pamięć
- Średnie obciążenie
- Wolne miejsce na dysku
Zbieranie tych danych
Powyższe sekcje zawierają instrukcje SQL do wyodrębnienia potrzebnych metryk z działającego serwera Postgres. Jeśli wolisz nie pisać skryptów samodzielnie, sprawdź narzędzie open source pgmetrics. Może zbierać powyższe dane i nie tylko oraz raportować je w formatach tekstowych i JSON.
Możesz bezpośrednio wysyłać raporty pgmetrics do naszej oferty handlowej,pgDash, która przechowuje i przetwarza te raporty w celu wyświetlania wykresów i wykonywania alertów.
