Trochę troski i dbałości o wdrożenie PostgreSQL znacznie zwiększa wydajność, unika nieprzyjemnych odkryć i zapewnia pewną przewidywalność. Oto 7 rzeczy, na które powinieneś zwrócić uwagę.
Nadmiar stołu
PostgreSQL implementuje transakcje przy użyciu techniki zwanej MVCC. MVCC jest zbyt długi i wymaga szczegółowego omówienia, ale są trzy rzeczy, które musisz wiedz o tym:
- Usunięcie wiersza oznacza jedynie, że jest on „niewidoczny” dla przyszłych transakcji.
- Aktualizacja wiersza tworzy nową wersję wiersza. Stara wersja jest oznaczona jako niewidoczna dla przyszłych transakcji, a nowa wersja jest oznaczona jako widoczna.
- Okresowo ktoś musi przyjrzeć się wszystkim aktualnie działającym transakcjom i powiedzieć:OK, najstarsza transakcja to 42, więc każda wersja wiersza, która jest niewidoczna dla numeru 42, może zostać fizycznie usunięta bez szkody dla spójności danych.
Tak właśnie działa MVCC (zasadniczo) i wynika z tego, że aktualizacje będzie zwiększyć ilość miejsca zajmowanego przez fizyczną bazę danych, a usuwanie nie Zmniejsz to. MVCC brzmi jak leniwy sposób na robienie rzeczy, ale jest popularny, ponieważ zapewnia zarówno spójność, jak i wydajność.
Niechciane, przestarzałe wersje wierszy w tabeli są nazywane rozdęciem (lub deadrows ). Proces, który może usunąć wzdęcia, nazywa się próżnią . PostgreSQL posiada automatycznie uruchamiany proces próżni z regulowanymi progami zwanymi autovacuum i oczywiście poleceniem VACUUM.
Ogólnie rzecz biorąc, rozdęcie może również spowolnić zapytania z powodu niedokładnych map widoczności i zmarnowanych operacji we/wy dysku.
Z tego powodu powinieneś regularnie:
- monitorowanie ilości wzdęć w bazie danych
- regularnie uruchamiaj odkurzacz
- monitoruj, czy próżnia jest uruchamiana regularnie dla wszystkich stołów
Istnieje kilka zapytań SQL zapewniających oszacowanie rozrostu na tabelę. Narzędzie open source toolpgmetrics zapewnia oszacowanie wzdęcia, a także czasy ostatniego uruchomienia ręcznego i automatycznego podciśnienia.
Wzdęcie indeksu
Indeksy też mogą się wzbierać. Chociaż wewnętrzna struktura indeksów jest nieprzezroczysta dla użytkownika SQL i różni się w zależności od typu indeksu (BTree, hash, GIN, GIST itp.), ogólna zasada pozostaje taka, że po usunięciu wierszy, do których odwołuje się indeks, miejsce zajmowane przez powiązane informacje wewnątrz indeksu jest tylko logicznie usuwany i nie wraca do systemu plików. Logicznie usunięta przestrzeń może być później ponownie wykorzystana przez indeks.
Istnieją dwa sposoby, aby Postgres zmniejszył fizyczny rozmiar indeksu:
- PEŁNA wersja polecenia VACUUM
- REINDEKS
Powiększenie indeksu musi być monitorowane, abyś był przynajmniej świadomy ilości niewykorzystanego miejsca. W tabelach z dużą liczbą wierszy nie jest niczym niezwykłym konfigurowanie regularnych zadań odbudowy indeksu.
Powiększenie indeksu można również uzyskać za pomocą tych samych zapytań, co poprzednio, a także za pomocą pgmetrics.
Długotrwałe transakcje
Transakcje powinny być jak najkrótsze, szczególnie w systemie MVCC.
Wyobraź sobie, że transakcja rozpoczęła się wczoraj, a zaraz potem nastąpiła próżnia. Teraz tak długo, jak ta transakcja jest otwarta, dalsze próżnie są bezużyteczne, ponieważ z definicji nasza transakcja będzie musiała zobaczyć wszystkie wiersze wszystkich stołów tak, jak były, gdy nasza transakcja rozpoczęła się wczoraj. Nawet jeśli nasza transakcja jest tylko do odczytu, nadal tak jest.
W rezultacie długotrwałe transakcje powodują rozdęcie. Zatrzymują się również na zasobach systemowych, utrzymują niezamknięte blokady i zwiększają prawdopodobieństwo wystąpienia zakleszczeń.
Najlepszym sposobem, aby zwracać uwagę na długoterminowe transakcje, jest ustawienie alertu dla liczby transakcji, które trwają dłużej niż określony czas. Możesz to uzyskać z widoku statystykpg_stat_activity , jak tak:
-- number of transactions that have been open for
-- more than 1 hour
SELECT count(*) FROM pg_stat_activity WHERE xact_start < now()-'1 hour'::interval;Opóźnienie replikacji
Gdy replikacja strumieniowa jest używana do replikacji wszystkich zmian z serwera primaryPostgreSQL do gorącej rezerwy (czyli repliki do odczytu), zwykle występuje niewielkie opóźnienie między momentem, w którym nastąpią aktualizacje wierszy na serwerze podstawowym, a momentem, gdy zmiany są widoczne dla aplikacji podłączonych do rezerwy .
Istnieją jednak przypadki, w których opóźnienie to może się zwiększyć:
- System gotowości nie jest w stanie odebrać i zastosować zmian z poziomu podstawowego wystarczająco szybko, aby nadążyć za nim, zwykle z powodu dużego obciążenia lub niedostatecznej obsługi
- zdegradowana sieć lub dysk
- konflikty zapytań
Tryb gotowości z wysokim lub nawet gorszym, rosnącym opóźnieniem replikacji może spowodować, że zapytania dotyczące trybu gotowości zwracają nieaktualne dane oraz tryb gotowości, który nie nadaje się do przełączania awaryjnego.
Jeśli masz konfigurację replikacji strumieniowej, monitorowanie opóźnień replikacji między każdą parą podstawowa-gotowość jest bardzo ważne i będziesz chciał ustawić upalerty, aby sprawdzić, czy opóźnienia replikacji przekraczają minutę lub jakikolwiek próg sensowny dla Twojej konfiguracji.
Ten post zawiera o wiele więcej informacji o tym, jak mierzyć i monitorować opóźnienie replikacji zarówno od strony głównej, jak i w trybie gotowości.
Nieaktywne gniazda replikacji
Użycie gniazd replikacji, wprowadzone w PostgreSQL 9.4, sprawia, że replikacja strumieniowa jest bardziej niezawodna i wydajna. Zasadniczo rezerwa zgłasza postęp replikacji do serwera podstawowego, który przechowuje te informacje w „gnieździe replikacji”.
Z tego powodu podstawowa teraz wie cały czas, jak daleko jest za gotowością. Dzięki temu serwer podstawowy może zachować wystarczającą ilość zaległości w plikach WAL (które są potrzebne do wznowienia replikacji), gdy stan wstrzymania przejdzie w tryb offline. Tak więc, gdy tryb gotowości powróci, nawet po długim czasie, główny nadal może zagwarantować, że replikacja zostanie wznowiona.
Przed gniazdami replikacji podstawowa może wyczyścić stare pliki WAL, ponieważ nie wiedziała, czy są one potrzebne w trybie gotowości, czy nie. Jeśli plik WAL potrzebny do stanu wstrzymania zostanie usunięty, nie ma możliwości wznowienia replikacji; musi być ponownie skonfigurowany od zera.
Jednak zachowanie systemu podstawowego polegające na przechowywaniu plików WAL w nieskończoność prowadzi do innego problemu. Jeśli stan wstrzymania został wycofany, a powiązane gniazdo replikacji nie zostało usunięte, pliki WAL zostaną zachowane na zawsze. Pliki WAL zachowane z tego powodu nie podlegają limitom określonym przez max_wal_size i inne opcje konfiguracji.
Ta sytuacja będzie się utrzymywać, dopóki pliki WAL nie zajmą całego miejsca na dysku, nawet bez ostrzeżenia w plikach dziennika PostgreSQL.
Nie trzeba dodawać, że nieaktywne szczeliny replikacji muszą być traktowane po ich wykryciu. Znajdź swoje nieaktywne miejsca replikacji za pomocą:
SELECT slot_name FROM pg_replication_slots WHERE NOT active;Analizuj stan
ANALIZA jest uruchamiana na tabelach w celu zbierania i aktualizowania informacji statystycznych o zawartości tabeli. Te informacje są używane przez planistę zapytań do przygotowania planu wykonania dla każdego zapytania SQL. Aktualne statystyki dotyczące zawartości tabeli zapewniają lepszy plan wykonania, co z kolei skutkuje szybszym wyszukiwaniem.
Demon autovacuum zwykle uruchamia ANALIZA po VACUUM. Może to jednak nie być wystarczająco częste dla ANALIZY. Jeśli dystrybucja danych w możliwych zmianach często, powinieneś częściej uruchamiać ANALIZA.
Zazwyczaj ANALYZE zachowuje się całkiem nieźle – potrzebuje tylko blokad odczytu, nie zużywa zbyt wiele zasobów i kończy się w rozsądnym czasie. Jest to bezpieczne, jeśli chodzi o uruchamianie go częściej niż nie.
Pilnowanie tabel, które nie były analizowane od dłuższego czasu, to dobry pomysł. Dowiedz się, kiedy ostatnio Twoje tabele były (automatycznie) analizowane za pomocą zapytania:
SELECT schemaname || '.' || relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables;Wykorzystanie zasobów
Monitorowanie obciążenia procesora, pamięci i wykorzystania dysku ma duży wpływ na zapewnienie wystarczającej pojemności, aby sprostać rosnącym potrzebom aplikacji korzystających z bazy danych.
PostgreSQL tworzy jeden proces do obsługi jednego połączenia. Chociaż może nie jest to obecnie najbardziej skalowalna architektura, ma duży wpływ na stabilność. Sprawia również, że średnia obciążenia systemu operacyjnego jest bardziej znacząca. Ponieważ zwykle PostgreSQLboxy uruchamiają tylko PostgreSQL, średnia obciążenia wynosząca powiedzmy 3 zazwyczaj oznacza, że są 3 połączenia czekające na udostępnienie rdzeni procesora, aby można je było zaplanować. Monitorowanie średniego maksymalnego obciążenia w ciągu typowego dnia lub tygodnia pozwala oszacować, w jakim stopniu Twoje urządzenie jest przeładowane lub niedostarczone z przodu procesora.
Pamięć i wolne miejsce na dysku to oczywiście standardowe rzeczy do monitorowania. Więcej połączeń i dłuższe transakcje nakładają większe wymagania na pamięć. Podczas monitorowania wolnego miejsca na dysku pamiętaj, aby śledzić je według obszaru tabel.
