Jaké metriky vašeho nasazení PostgreSQL byste měli sledovat? Cílem této série blogových příspěvků je poskytnout minimální počáteční sadu základních monitorovacích akcí, které byste měli implementovat, abyste zajistili zdraví a stabilitu vašich serverů Postgres.
Toto je druhá část série blogů a pokrývá parametry na úrovni databáze. První část pokrývá parametry na úrovni clusteru.
Část 2:Úroveň databáze
V této části se podíváme na metriky a informace, které by měly být monitorovány pro každou důležitou databázi, kterou používáte.
Většina dotazů SQL uvedených níže by měla být spuštěna při připojení k dané databázi.
1. Připojení klienti
Připojení klienti zabírají OS a systémové prostředky. Postgres má architekturu procesu na klienta a příliš mnoho klientů může zpomalit dobu odezvy na dotaz pro každého. Zvažte použití PgBouncer orpgpool ke snížení počtu připojení, která bude muset server Postgres obsluhovat.
Sledujte změny ve výchozím stavu po aktualizacích aplikace a nárůst počtu připojení kvůli zvýšenému provozu.
Akce:Monitorujte maximální počet připojených klientů každý den/týden, prozkoumejte změny trendu.
Jak na to:
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. Velikost
Je třeba sledovat skutečnou velikost disku používaného databází. Ve většině případů velikost databáze neustále roste, takže zajímavější je rychlost růstu. Opět si dávejte pozor na zvýšenou rychlost růstu po vydání nových aplikací.
Akce:Monitorujte růst velikosti databáze v průběhu každého týdne/měsíce, prozkoumejte trendy, obnovte ji.
Jak na to:
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. Stolní nafouknutí napříč všemi stoly
Kvůli architektuře MVCC Postgres leží starší verze řádků ve fyzických datových souborech pro každou tabulku a nazývají se nadýmání . Operace k odstranění zastaralých verzí řádků se nazývá vakuum . Postgres spouští proces na pozadí zvaný autovacuum , který sbírá kandidátní tabulky (na základě konfigurovatelných parametrů) a vysává je za vás.
Bloat zpomaluje operace s tabulkami a plýtvá místem na disku a může utéct is autovakuem. Je vyžadováno monitorování nadýmání jako absolutního počtu bajtů i procenta (mrtvých dat k celkovým datům). To lze provést na úrovni databáze jako součtu napříč všemi tabulkami, s možností ponořit se do „nejnabušenějších tabulek“.
Akce:Průběžně sledujte celkové nafouknutí jako bajty a procenta, upozorněte, pokud hodnoty překročí nastavenou hranici.
Jak na to:
Použijte check_postgres orpgmetrics k získání odhadů nadýmání. Více informací naleznete na wiki.
4. Index nafouknutí napříč všemi indexy
Nafouklé indexy mohou zpomalit vkládání a snížit výkon vyhledávání. Sledujte nadýmání indexů jako absolutní hodnotu (počet bajtů) i jako procento. Indexy budou muset být přestavěny, až budou příliš nafouklé.
Akce:Průběžně sledujte celkové nafouknutí jako bajty a procenta, upozorněte, pokud hodnoty překročí nastavenou hranici.
Jak na to:
Použijte check_postgres orpgmetrics k získání odhadů nadýmání. Více informací naleznete na wiki.
5. Dlouho běžící transakce
Příliš dlouho otevřené transakce nejsou pro PostgreSQL dobrou zprávou. Dlouhotrvající transakce mohou způsobit uchování souborů WAL, mohou viset na zámcích a zabránit vakuu. Aplikace by měly být navrženy tak, aby doby trvání transakcí byly co nejnižší.
Backend provozující dlouhotrvající transakci lze zabít pomocí pg_cancel_backend() a pg_terminate_backend() funkce.
Akce:Nepřetržitě sledujte počet transakcí, které probíhají déle než nastavenou dobu, upozorněte, pokud hodnoty překročí nastavenou hranici.
Jak na to:
-- 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. Zablokování
V PostgreSQL backendy implicitně umisťují zámky na řádky a tabulky, jak probíhá provádění dotazů, které upravují řádky. Dotazy mohou také umístit explicitní zámky (jako SELECT .. FOR UPDATE ). Stejně jako ve vícevláknovém programování mohou dvě transakce umístění zámků, ať už implicitně nebo explicitně, v opačném pořadí, vést k uváznutí.
PostgreSQL detekuje zablokování a vrátí zpět jednu ze zahrnutých transakcí (všechny zámky držené transakcí jsou uvolněny, když je potvrzena nebo odvolána zpět). Podrobnosti budou zaznamenány v cíli protokolování PostgreSQL.
Aplikace by měly být navrženy tak, aby se zabránilo možnosti uváznutí. Mohou se také rozhodnout opakovat transakci v případě uváznutí.
Akce:Monitorujte počty zablokování za každý den/týden, přepracujte aplikaci za účelem snížení počtu, prozkoumejte změny.
Jak na to:
Výskyty uváznutí spolu s dalšími informacemi se zaznamenávají do souboru protokolu PostgreSQL. K extrahování těchto informací použijte pgmetrics, pgbadger nebo jiné nástroje pro zpracování protokolů specifické pro PostgreSQL.
7. Nejstarší vysavač
Pravidelné vysávání stolů, ať už autovakuem, nebo s naplánovanými úlohami, nebo ručně je nutností pro udržení rychlého provozu stolu. Vysavače však mohou selhat z různých důvodů, včetně dlouho probíhajících transakcí, neaktivních replikačních slotů atd.
Protože pravidelné vysávání stolů je ve světě Postgresu poměrně důležité, je nejlepší pravidelně kontrolovat, zda byly všechny stoly vysávány alespoň jednou v nastaveném intervalu.
A ačkoli bývají v nedohlednu a mimo mysl, systémové katalogové tabulky by se také měly vysát.
Akce:Průběžně kontrolujte, zda některý stůl nebyl vysát v posledním nastaveném počtu hodin/dnů, případně upozorněte.
Jak na to:
-- 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. Nejstarší analýza
Chcete-li provést své SELECT dotazy, plánovač dotazů připravíprováděcí plán který popisuje, které indexy a tabulky je třeba číst a jak. Aby plánovač přišel s efektivním plánem provádění, potřebuje mít statistiky o distribuci hodnot, velikostech n-tic a tak dále. Tyto statistické informace o datech v tabulce jsou shromažďovány a udržovány pomocí analýzy operace. Tabulky s aktuálními statistikami vedou k rychlejším dotazům a menšímu počtu I/O.
Výše zmíněný proces autovakuování obvykle také běží ANALYZE na stole vysává, aby byly tyto informace aktualizovány. To však samo o sobě nemusí poskytnout dostatečné pokrytí analýzou vašich tabulek. Budete chtít doplnit spuštěním ANALYZE jako naplánované úlohy nebo po významných tabulkových mutacích.
V zájmu výkonu dotazů je nejlepší průběžně kontrolovat, zda byly všechny tabulky analyzovány alespoň jednou v nastaveném intervalu.
Akce:Průběžně kontrolujte, zda některá tabulka nebyla analyzována během posledního nastaveného počtu hodin/dní, případně upozorněte.
Jak na to:
-- 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;Shromažďování těchto metrik
Výše uvedené části poskytují příkazy SQL pro extrahování potřebných metrik ze spuštěného serveru Postgres. Pokud nechcete psát skripty sami, podívejte se na open source nástroj pgmetrics. Může shromažďovat výše uvedené metriky a další a hlásit je v textových formátech a formátech JSON.
Zprávy pgmetrics můžete přímo zasílat naší komerční nabídce pgDash, která tyto zprávy ukládá a zpracovává za účelem zobrazení grafů a provádění výstrah.
Další
Další část této série se bude zabývat metrikami na úrovni tabulky, indexu a systému. Zůstaňte naladěni!