Podstawowe problemy bazodanowe

Krótki przewodnik po chorobach baz danych.

[Pierwsze kroki] [Lock] [Indeksy] [Dlaczego to nie jest problem sieciowy] [Jak poszerzać wiedzę o postgresie]

Pierwsze kroki

Na początku pada nie tyle słowo, co zdanie, na dodatek pochodzi ono nie od boga, tylko od developera i na ogół brzmi tak:

Pierwszą czynnością jaką wykonujemy jest połączenie po ssh i uruchomienie htop - zanim trochę bardziej szczegółowo omówimy, co możemy tam zobaczyć, załóżmy że nie widzimy nic szczególnego - parametry są trochę podwyższone (albo i nawet nie), nie ma zapytania-killera. Jeśli i przeszukanie logów po “FATAL|ERROR“ nie zwraca nic konkretnego, pierwszą czynnością naprawczą jest wykonanie analyze:

vacuumdb -d [nazwa_bazy] -j [ilość_wątków] --analyze-in-stages

opcjonalnie z vacuum:

vacuumdb -d [nazwa_bazy] -j [ilość_wątków] -z

Powyższe instrukcje wykonujemy z shella i wykonają się dla wszystkich tabel - proces odpalamy w screenie i przechodzimy do dalszej diagnostyki. O ANALYZE, martwych krotkach i VACUUM poczytasz tu.

Lock

Krótka ściąga z locków jest tu (myślę, że warto w ogóle zapoznać się z tym artykułem), tu powtórzymy podstawowe zapytanie diagnostyczne:

WITH locks AS (
SELECT DISTINCT pg_locks.pid, 1 AS blocking, datname, state, query_start
FROM pg_locks LEFT JOIN pg_stat_activity ON pg_locks.pid = pg_stat_activity.pid
WHERE granted = TRUE AND pg_locks.pid NOT IN (SELECT pid FROM pg_locks WHERE NOT granted) AND pg_locks.pid != pg_backend_pid()
UNION
SELECT DISTINCT pg_locks.pid, 0 AS blocking, datname, state, query_start
FROM pg_locks LEFT JOIN pg_stat_activity ON pg_locks.pid = pg_stat_activity.pid
WHERE NOT granted)
SELECT
sum(blocking) AS blocking_cnt,
sum(CASE WHEN blocking = 0 THEN 1 ELSE 0 END) AS blocked_cnt,
sum(CASE WHEN blocking = 1 AND state = 'idle in transaction' THEN 1 ELSE 0 END) AS blocking_idle_in_transaction_cnt,
FLOOR(max(EXTRACT(EPOCH FROM now() - COALESCE(query_start, now())))) AS max_lock_duration
FROM locks
WHERE datname = '{#DBNAME}'; --{#DBNAME} - zamień na nazwę bazy

Niepokojące informacje mogą czekać w kolumnie blocked_cnt, wskazuje ona ilość zapytań, które zostały zablokowane przez inne zapytania. Tym zapytaniem natomiast zobaczysz co konkretnie powoduje locki.

Problemy z lockami mogą objawiać się różnie i sprawdzenie tego jest elementem każdej diagnostyki, ale dość typowe jest połączenie wysokiego loadu i wysycania puli połączeń.

Indeksy

Duplikaty

Dlaczego to nie jest problem sieciowy

Z jakiegoś powodu często i szczególnie, kiedy wyeliminuje się najbardziej podstawowe przyczyny (nie ma podwyższonego loadu, dysk / CPU / RAM są w porządku), podejrzenia kierowane są do sieci. Jeśli jednak przejrzy się dokumenty typu RCA, okazuje się, że sieć nie była przyczyną nawet 1% przypadków.

To, co wskazuje na problem sieciowy to znamiona awarii globalnej. Jeśli zatem cały świat wokół Ciebie nie przypomina syreny strażackiej a ludzie zaczynają wypowiedź od powitania a nie od wulgaryzmów, serio, zostaw sieć w spokoju.

Jak poszerzać wiedzę o postgresie

PostgreSQL to jeden z najbardziej zaawansowanych silników bazodanowych, w dodatku bardzo “elokwentny“ - chętnie powie Ci dużo na swój temat, trzeba tylko zapytać. Jest świetna dokumentacja i oczywiście mnóstwo informacji znajdziesz w logach (większość parametrów przy zmianie wymaga tylko reloadu, ale ale uważaj, żeby plik z logami nie ważył za dużo). Trzecim źródłem wiedzy jest sama baza - postres ma mnóstwo metadanych, z których możesz dowiedzieć co w bazie jest i co się z nią dzieje. Jest też sztuczka, która bez dokumentacji ułatwi Ci zebranie wiedzy:

Jak widzisz, uruchomienie natywnego klienta PostgreSQL z

Last modified: 30 May 2024