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 jest druga część serii blogów i obejmuje parametry na poziomie bazy danych.Pierwszy obejmuje parametry na poziomie klastra.
Część 2:Poziom bazy danych
W tej części przyjrzymy się metrykom i informacjom, które powinny być monitorowane dla każdej ważnej bazy danych, z której korzystasz.
Większość zapytań SQL wymienionych poniżej należy uruchamiać podczas połączenia z daną bazą danych.
1. Połączeni klienci
Połączeni klienci zajmują system operacyjny i zasoby systemowe. Postgres ma architekturę procesu na klienta i zbyt wielu klientów może spowolnić czas odpowiedzi na zapytania dla wszystkich. Rozważ użycie PgBouncer orpgpool, aby zmniejszyć liczbę połączeń, które serwer Postgres będzie musiał obsłużyć.
Miej oko na zmiany linii bazowej po aktualizacjach aplikacji i nagłych połączeniach z powodu zwiększonego ruchu.
Działanie:Monitoruj maksymalną liczbę podłączonych klientów każdego dnia/tygodnia, badaj zmiany trendów.
Jak to zrobić:
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. Rozmiar
Należy monitorować rzeczywisty rozmiar dysku używany przez bazę danych. W większości przypadków rozmiar bazy danych stale rośnie, więc to tempo wzrostu jest bardziej interesujące. Ponownie uważaj na zwiększone tempo wzrostu po wydaniu nowych aplikacji.
Działanie:Monitoruj wzrost rozmiaru bazy danych w każdym tygodniu/miesiącu, badaj trendy, udostępniaj ponownie.
Jak to zrobić:
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. Nadmiar stołu na wszystkie stoły
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 rozrostu, jako bezwzględnej liczby bajtów, a także procentu (martwych danych do wszystkich danych). Można to zrobić na poziomie bazy danych jako sumę we wszystkich tabelach, z możliwością zagłębienia się w „najbardziej rozdęte tabele”.
Działanie:stale monitoruj całkowity rozrost w bajtach i wartościach procentowych, ostrzegaj, gdy wartości przekraczają ustalony próg.
Jak to zrobić:
Użyj check_postgres orpgmetrics, aby uzyskać szacunki wzdęcia. Więcej informacji znajdziesz na wiki.
4. Nadmuch indeksu we wszystkich indeksach
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 całkowity rozrost w bajtach i wartościach procentowych, ostrzegaj, gdy wartości przekraczają ustalony próg.
Jak to zrobić:
Użyj check_postgres orpgmetrics, aby uzyskać szacunki wzdęcia. Więcej informacji znajdziesz na wiki.
5. Transakcje długoterminowe
Transakcje otwarte zbyt długo nie są dobrą wiadomością dla PostgreSQL. Długotrwałe transakcje mogą powodować przechowywanie plików WAL, mogą zawiesić się na blokadach i zapobiegać powstawaniu próżni. Aplikacje powinny być zaprojektowane tak, aby czas trwania transakcji był jak najkrótszy.
Backend obsługujący długotrwałą transakcję można zabić za pomocą pg_cancel_backend() i pg_terminate_backend() funkcje.
Działanie:stale monitoruj liczbę transakcji działających dłużej niż określony czas, ostrzegaj, gdy wartości przekraczają określony próg.
Jak to zrobić:
-- returns the count of transactions that have been running for more than a day
SELECT count(*)
FROM pg_stat_activity
WHERE xact_start < now() - '24 hours'::interval;6. Zakleszczenia
W PostgreSQL backendy nakładają blokady na wiersze i tabele niejawnie podczas wykonywania zapytań modyfikujących wiersze. Zapytania mogą również nakładać jawne blokady (takie jak SELECT .. FOR UPDATE ). Podobnie jak w programowaniu wielowątkowym, dwie transakcje nakładające blokady, pośrednio lub jawnie, w przeciwnej kolejności, mogą spowodować zakleszczenie.
PostgreSQL wykryje zakleszczenia i wycofa jedną z transakcji (wszystkie blokady utrzymywane przez transakcję zostaną zwolnione, gdy zostanie ona zatwierdzona lub wycofana). Szczegóły zostaną zarejestrowane w miejscu docelowym logowania PostgreSQL.
Aplikacje powinny być zaprojektowane tak, aby uniknąć możliwości zakleszczenia. Mogą również zdecydować się na ponowną próbę transakcji w przypadku zakleszczenia.
Działanie:Monitoruj liczbę zakleszczeń każdego dnia/tygodnia, przeprojektuj aplikację w celu zmniejszenia liczby, zbadaj zmiany.
Jak to zrobić:
Wystąpienia zakleszczeń wraz z dodatkowymi informacjami są rejestrowane w pliku dziennika PostgreSQL. Użyj pgmetrics, pgbadger lub innych narzędzi do przetwarzania logów specyficznych dla PostgreSQL, aby wyodrębnić te informacje.
7. Najstarsza próżnia
Regularne odkurzanie stołów, z automatycznym odkurzaniem lub z zaplanowanymi zadaniami, lub ręczne jest koniecznością, aby utrzymać szybkie operacje na stołach. Odkurzacze mogą jednak zawieść z różnych powodów, w tym długotrwałych transakcji, nieaktywnych gniazd replikacji itp.
Ponieważ regularne odkurzanie stołów jest dość ważne w świecie Postgres, najlepiej jest regularnie sprawdzać, czy wszystkie stoły zostały odkurzone przynajmniej raz w ustalonym odstępie czasu.
I chociaż zwykle są one niewidoczne i niewidoczne, tabele katalogowe systemu również powinny być odkurzane.
Działanie:stale sprawdzaj, czy jakikolwiek stół nie był odkurzany w ciągu ostatniej ustawionej liczby godzin/dni, ostrzeż, jeśli w ogóle.
Jak to zrobić:
-- returns the top 5 tables vacuumed least recently
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
ORDER BY last_vacuum ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been vacuumed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
WHERE last_vacuum < now() - '7 days'::interval;8. Najstarsza analiza
Aby wykonać zapytania SELECT, planer zapytań przygotowujeplan realizacji opisuje, które indeksy i tabele należy odczytać iw jaki sposób. Aby opracować skuteczny plan wykonania, planista musi mieć statystyki dotyczące rozkładu wartości, rozmiarów krotek i tak dalej. Takie informacje statystyczne o danych w tabeli są gromadzone i utrzymywane przez analizę operacje. Tabele z aktualnymi statystykami skutkują szybszymi zapytaniami i mniejszą liczbą operacji we/wy.
Wspomniany powyżej proces automatycznego odkurzania zazwyczaj uruchamia także ANALIZA na stole odkurza, aby aktualizować te informacje. Jednak samo to może nie zapewnić wystarczającego pokrycia analiz dla Twoich tabel. Będziesz chciał uzupełnić, uruchamiając ANALIZA jako zaplanowane zadania lub po znaczących mutacjach tabel.
W trosce o wydajność zapytań najlepiej jest stale sprawdzać, czy wszystkie tabele zostały przeanalizowane przynajmniej raz w określonym przedziale czasu.
Działanie:stale sprawdzaj, czy jakakolwiek tabela nie została przeanalizowana w ciągu ostatniej ustawionej liczby godzin/dni, ostrzeż, jeśli w ogóle.
Jak to zrobić:
-- returns the top 5 tables analyzed least recently
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
ORDER BY last_analyze ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been analyzed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
WHERE last_analyze < now() - '7 days'::interval;Zbieranie tych danych
Powyższe sekcje zawierają instrukcje SQL umożliwiające wyodrębnienie 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.
Dalej
Kolejna część tej serii obejmie metryki na poziomie tabeli, indeksu i systemu. Bądź na bieżąco!
