Wprowadzenie do monitoringu baz danych

Wyobraź sobie, że jesteś kapitanem statku płynącego przez ocean danych. Nie chodzi tylko o to, żeby statek płynął. Chcesz mieć pewność, że nie wpadnie na górę lodową długich zapytań, nie zaskoczy cię nagła burza blokad i statek nie zatonie przez przeciążenie połączeniami. Monitoring bazy danych to twój radar, barometr i echosonda, które pomagają unikać gór lodowych, sztormów i paniki.

Po co i jak monitorować bazę danych

Monitoring pomaga zapewnić stabilną pracę bazy danych i wcześniej zauważyć możliwe problemy. Wyobraź sobie, że zamiast nagłego padnięcia serwisu dostajesz wczesny sygnał: „Hej, tutaj zapytanie wykonuje się już 30 sekund i coś jest nie tak”. Wiesz z wyprzedzeniem, gdzie jest korek, kto trzyma blokadę i na jakim etapie baza zaraz się zadławi przez brak zasobów.

Na co warto zwrócić uwagę:

• Aktywność zapytań i transakcji. Obserwuj przepływ zapytań tak, jak dyspozytor patrzy na ruch na skrzyżowaniu. Które SQL-komendy spowalniają resztę? Kto najbardziej obciąża bazę? Te odpowiedzi dają szansę na optymalizację bez pośpiechu i paniki.

• Wykorzystanie zasobów. CPU, RAM i miejsce na dysku to jak paliwo i kadłub statku. Jeśli któryś z zasobów „cieknie” albo jest przeciążony, cały statek może stanąć. Monitoring pokazuje, gdzie jest przeciążenie i daje możliwość rozdzielenia obciążenia.

• Wydajność zapytań. Niektóre SQL-zapytania są jak kapryśni pasażerowie: wymagają za dużo, spowalniają innych i wiecznie narzekają. Monitoring pokaże, kto jest szczególnie „żarłoczny” — żeby można było zindeksować, przepisać albo wymienić.

• Blokady i konflikty. Czasem zapytania wchodzą sobie w drogę: jedno trzyma zasób, drugie na niego czeka. To jakby ktoś trzymał drzwi w jedną stronę, a drugi ciągnął w drugą. Monitoring takich blokad pozwala w porę zareagować i rozładować napięcie.

Dobry monitoring nie tylko mówi, że baza „żyje”. Podpowiada, gdzie jej życie może się posypać — i daje ci czas, żeby wszystko naprawić, zanim problemy staną się realne.

Kluczowe metryki do monitoringu PostgreSQL

Żeby rozumieć stan twojej bazy danych, musisz wiedzieć, na co patrzeć. Te metryki to twój „puls” i „ciśnienie” bazy danych. Oto najważniejsze parametry:

1. Liczba aktywnych połączeń.

   Ilu użytkowników jest teraz podłączonych? Czy próbują rozwalić twoją bazę bezmyślnymi zapytaniami? Na przykład pg_stat_activity, o którym pogadamy w kolejnych wykładach, pokaże aktualną aktywność.

2. Czas wykonywania zapytań.

   Które zapytania wykonują się najszybciej? A które myślą, że są już na zasłużonej emeryturze?

3. Wykorzystanie indeksów.

   Jeśli masz indeksy, ale ich nie używasz, coś jest nie tak. Sprawdzimy to przez pg_stat_user_indexes.

4. Poziom blokad i konfliktów.

   Szeroko stosowane do zapobiegania „Deadlocks” (wzajemnych blokad).

5. Obciążenie procesora i użycie pamięci.

   Na przykład, ile zasobów twojego serwera „zjada” PostgreSQL?

Jak to wygląda w praktyce?

Zobaczmy na realny przykład. Oto proste zapytanie, które pozwala sprawdzić rozmiar konkretnej bazy danych:

SELECT pg_size_pretty(pg_database_size('nazwa_twojej_bazy')) AS database_size;

To skromne zapytanie zwróci rozmiar bazy w czytelnym formacie — na przykład 243 MB albo 1.2 GB. Przydatne, gdy chcesz szybko ocenić, jak bardzo baza urosła ostatnio.

Jeśli chcesz zobaczyć rozmiary wszystkich baz naraz — bez podawania każdej z osobna — możesz użyć takiej wersji:

SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database;

To już daje przegląd wszystkich baz na serwerze — wygodne dla admina, który pilnuje użycia dysku i chce złapać „żarłocznych” zanim dostanie maila od hostingu: „Kończy ci się miejsce”.