Systemowe metryki PostgreSQL

Wyobraź sobie, że twój serwer PostgreSQL to restauracja, a my jesteśmy inspektorami. Żeby restauracja działała stabilnie, musimy brać pod uwagę, ile składników (CPU, pamięć, dysk) jest używanych, jak często się kończą i kto to wszystko zużywa. Jeśli to przegapimy, nasza "restauracja" może przyjąć za dużo zamówień i nie dać rady, albo po prostu padnie w środku dnia. Właśnie dlatego rozumienie systemowych metryk jest mega ważne.

Kluczowe metryki do monitorowania PostgreSQL:

1. CPU: pokazuje, ile czasu procesora jest zużywane na wykonywanie zapytań.
2. Pamięć (RAM): pokazuje, jak PostgreSQL korzysta z RAM-u, w tym cache'owanie zapytań.
3. Miejsce na dysku: chyba najbardziej przewidywalne — nie zapiszesz więcej danych, niż pozwala na to dysk.

Naszym celem jest nauczyć się sprawdzać i interpretować systemowe metryki PostgreSQL, żeby uniknąć problemów z wydajnością i brakiem zasobów.

Monitorowanie użycia CPU

Procesor to serce twojego serwera. PostgreSQL może zjadać CPU zarówno przy wykonywaniu ciężkich zapytań, jak i przy zadaniach w tle, takich jak autoanaliza i autovacuum bazy. Jeśli twoja baza przypomina wiecznie głodnego żarłoka, który łapczywie "pożera" CPU, czas zareagować.

1. Użycie narzędzi systemowych.
   Na początek sprawdź, ile czasu CPU PostgreSQL zużywa na poziomie systemu. Na Linuksie możesz użyć komend top albo htop.

Znajdź proces PostgreSQL (zwykle zawiera nazwę twojej bazy). Na przykład, postgres: postgres [twoje_zapytanie].

Zwróć uwagę na kolumnę %CPU. Jeśli ciągle "wariuje", to sygnał alarmowy.

2. Analiza obciążenia CPU z poziomu PostgreSQL.

PostgreSQL ma wbudowane widoki do monitorowania obciążenia. Najbardziej przydatny tutaj jest pg_stat_activity, który pokazuje aktywne zapytania.

Przykład zapytania:

SELECT pid, usename, query, state, now() - query_start AS duration
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY duration DESC;

Co tu jest ważne?

• state = 'active' pokaże tylko te zapytania, które są aktualnie wykonywane.
• duration pokaże, jak długo zapytania już obciążają CPU.

Praktyczna rada:

Jeśli widzisz długie zapytanie, które nie powinno tyle trwać, sprawdź, jakie indeksy są używane. Możesz też zakończyć problematyczny proces przez pg_terminate_backend.

Przykład zakończenia:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'active' AND duration > interval '10 minutes';

Monitorowanie użycia pamięci

Pamięć to drugi najważniejszy zasób dla PostgreSQL, szczególnie jeśli chodzi o cache'owanie danych. PostgreSQL mocno korzysta z RAM-u (przez parametry work_mem i shared_buffers), żeby przyspieszyć operacje.

1. Podstawowe parametry PostgreSQL dotyczące pamięci:

• shared_buffers: To główny blok pamięci przydzielany do pracy PostgreSQL. Zwykle zajmuje 25-40% całego RAM-u serwera.
• work_mem: Pamięć na sortowanie i haszowanie w jednym zapytaniu. Im większa wartość, tym więcej operacji tymczasowych można zrobić w RAM-ie (a nie na dysku).

2. Sprawdzanie aktualnych ustawień pamięci.

Żeby zobaczyć, jakie ustawienia pamięci są aktywne dla PostgreSQL, wykonaj:

SHOW shared_buffers;
SHOW work_mem;

Przykład wyniku:

1GB
4MB

To znaczy, że serwer ma przydzielone 1 GB RAM-u na shared_buffers i po 4 MB na każdą operację sortowania/haszowania.

3. Monitorowanie pamięci przez pg_stat_activity

Możesz sprawdzić, ile pamięci używają aktualne połączenia. Do tego jest wygodne zapytanie:

SELECT pid, usename, state, backend_start, pg_size_pretty(pg_backend_memory_contexts_size(pid)) AS memory_used
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY memory_used DESC;

To zapytanie pokaże, ile RAM-u używa każde aktywne połączenie.

Rada: jeśli któreś połączenie zjada za dużo pamięci, sprawdź, czy w zapytaniu są operacje sortowania albo agregacji, które można zoptymalizować.

Monitorowanie miejsca na dysku

Dysk to ostatni rezerwuar zasobów dla PostgreSQL. Nawet jeśli masz wystarczająco RAM-u i CPU, PostgreSQL potrzebuje miejsca na dysku do przechowywania danych, logów transakcji (WAL) i plików tymczasowych.

1. Sprawdzanie rozmiaru bazy danych.

Zacznijmy od podstaw: określenie rozmiaru bazy danych.

SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size;

Co robi to zapytanie?

Pokazuje całkowity rozmiar aktualnej bazy w czytelnym formacie (MB, GB).

2. Sprawdzanie rozmiaru tabel i indeksów.

Żeby znaleźć "ciężarowców" w bazie, użyj:

SELECT relname AS table_name, pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;

Przykład wyniku:

3. Monitorowanie WAL (logów transakcji).

Jeśli masz aktywną bazę, logi transakcji mogą szybko rosnąć. Sprawdzisz ich rozmiar tak:

SELECT pg_size_pretty(pg_xlog_location_diff(pg_current_wal_lsn(), '0/0')) AS wal_size;

Wnioski

Teraz masz narzędzia i wiedzę, żeby ogarniać systemowe metryki PostgreSQL:

1. Używaj htop albo pg_stat_activity do monitorowania obciążenia CPU.
2. Skonfiguruj parametry shared_buffers i work_mem dla optymalnego użycia pamięci.
3. Regularnie sprawdzaj rozmiar bazy, tabel i indeksów, żeby nie zabrakło miejsca na dysku.

Te umiejętności przydadzą ci się, żeby uniknąć niespodziewanych awarii i trzymać serwer PostgreSQL w świetnej formie. Myśląc o serwerze, pamiętaj: dobrze zorganizowane zasoby sprawią, że twój produkt będzie najpopularniejszy wśród klientów (użytkowników).