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 třetí a poslední část série blogů a pokrývá metriky na úrovni tabulek, indexů a systémů. První pokrýval metriky na úrovni clusteru a druhý pokrýval metriky na úrovni databáze.
Úroveň tabulky
Data v databázi se obvykle řídí pravidlem 80-20. 20 % tabulek obsahuje většinu dat a jsou nejvíce přístupné nebo mutované. Nastavení dodatečného monitorování pouze pro tyto tabulky může poskytnout informace, které jsou důležité, ale mají malý objem.
Zde jsou některé metriky na úrovni tabulky, které stojí za zhlédnutí:
1. Velikost tabulky
Je třeba monitorovat skutečnou velikost disku používanou tabulkou. Ve většině případů tabulka neustále roste, takže zajímavější je tempo růstu.
Často se stává, že se tempo růstu změní po zavedení nové verze aplikace nebo základní změně ve vzorcích provozu/načítání/vstupů samotné aplikace. Takové změny musí být prozkoumány, alespoň pro ověření, že nová rychlost je udržitelná poskytovaným hardwarem.
Akce:Sledujte nárůst velikosti tabulky za každý týden/měsíc, prozkoumejte náhlé změny.
Jak na to:
-- returns the size for each table
SELECT schemaname || '.' || relname,
pg_size_pretty(pg_table_size(schemaname || '.' || relname))
FROM pg_stat_user_tables;2. Nafouknutí stolu
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).
Tato metrika může být monitorována buď na úrovni jednotlivých tabulek, nebo jako agregovaná napříč vybranými tabulkami, případně na úrovni databáze.
Akce:Průběžně monitorujte nadýmání tabulky jako bajty a procenta, varujte, pokud hodnoty překročí nastavenou prahovou hodnotu, podle potřeby VAKUUM.
Jak na to:
Použijte check_postgres orpgmetrics k získání odhadů nadýmání. Více informací naleznete na wiki.
3. Sekvenční skenování
Když jsou prováděny dotazy, které optimálně nevyužívají dostupné indexy, nebo pokud jsou statistické informace spojené s tabulkou příliš zastaralé, Postgres může skončit tím, že bude muset projít každý řádek tabulky. Toto se nazývá sekvenční skenování a není v obecném případě příliš žádoucí. Co by bylo lepší mít, je skenování indexu , kde se k řádkům tabulky přistupuje nepřímo pomocí vyhledávání v indexu.
PostgreSQL vám může říct, kolikrát byla tabulka postupně skenována a kolikrát byl použit index. Můžete to použít ke sledování buď počtu sekvenčních skenů (pokud se jim chcete úplně vyhnout), nebo jako procento z celkového počtu skenů.
Akce:Průběžně sledujte seq. počet nebo procento skenů, upozornění, pokud hodnota překročí nastavenou prahovou hodnotu.
Jak na to:
-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
seq_scan,
round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;Úroveň indexu
1. Velikost indexu
Indexy mohou zabírat značné místo na disku. Každý index tabulky může mít potenciálně tolik diskové stopy jako samotná tabulka. Je užitečné sledovat celkovou velikost indexů v databázi nebo indexy důležitých tabulek, zejména v nasazeních, kde lze indexy vytvářet automatickými procesy.
Nepřiměřeně velké indexy mohou být způsobeny nadýmáním nebo jen špatně navrženým indexem. V obou případech může oprava příčiny (buď přebudováním indexu nebo refaktorizací dotazu/indexu) zkrátit dobu dotazování, takže se vyplatí prozkoumat velké indexy.
Akce:Monitorujte celkovou velikost zajímavých indexů v průběhu každého týdne/měsíce, prozkoumejte, když jsou nepřiměřeně velké.
Jak na to:
-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
pg_size_pretty(pg_total_relation_size(indexrelid))
FROM pg_stat_user_indexes;2. Index nadýmání
Indexy mohou být také nafouklé. Existuje příliš mnoho faktorů, včetně vytížení tabulky, typu indexu, verze Postgresu a dalších, které rozhodují o tom, jak nabušený anindex bude. 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 nadýmání indexu jako bajty a procenta, upozorňujte, pokud hodnoty překročí nastavený práh.
Jak na to:
Použijte check_postgres orpgmetrics k získání odhadů nadýmání. Více informací naleznete na wiki.
3. Poměr návštěvnosti mezipaměti
PostgreSQL ukládá do paměti často používané oblasti indexů (a také tabulek). Pokud jste své dotazy vyladili tak, aby se nedotýkaly tabulek kromě načítání řádků, dalším krokem je zajistit maximální umístění mezipaměti pro ty důležité indexy, které skutečně zrychlují vaše dotazy.
Využití mezipaměti indexu lze měřit poměrem přístupů do mezipaměti, což je procento bloků indexu, které byly přečteny z mezipaměti, k celkovému počtu přečtených bloků.
Akce:Nepřetržitě sledujte procento poměru zásahů do mezipaměti, upozorněte, pokud hodnota klesne pod nastavenou hranici. Prozkoumejte nízké hodnoty u důležitých indexů.
Jak na to:
-- returns the cache hit ratio as a percentage, for each index
SELECT schemaname || '.' || indexrelname AS index_name,
round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 /
pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
FROM pg_stat_user_indexes
WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;Úroveň systému
Kromě metrik PostgreSQL je důležité sledovat i několik metrik počítače nebo virtuálního počítače, na kterém provozujete svůj Postgres. K tomu můžete použít jakékoli oblíbené monitorovací řešení nebo je dokonce uchopit a sledovat sami.
1. Použitá paměť
Moderní systémy Linux mají složité účtování paměti. Doporučujeme sledovat „použitou paměť“, což je paměť zbývající po započítání paměti označené jakovolná , jako vyrovnávací paměti , jako v mezipaměti a jako deska . Vyrovnávací paměti a mezipaměť budou pod tlakem ustupovat, stejně jako většina (obvykle přes 95 %) slabů.
Použitá paměť však musí být měřena po přiměřeně dlouhou dobu. Pokud máte dávkové úlohy, zprávy, ETL atd., které běží o víkendech, pak by období bylo jeden týden. Skutečná metrika, kterou budete muset sledovat, je maximální využitá paměť za toto období.
Obvykle, jak roste velikost vaší databáze, má tato hodnota tendenci narůstat. Budete muset zajistit, aby maximální využití paměti bylo v rámci pohodlného limitu dostupné paměti, například 60–80 %. Pokud toto zanedbáte, vaše pracovní zátěže Analytics/OLAP selžou kvůli nedostatku paměti.
Akce:Sledujte maximum využité paměti během týdne/noc, upozorněte, pokud překročí nastavenou hranici, obnovte.
Jak na to :
Použitá paměť je dána MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab , kde je Mem* pole jsou z /proc/meminfo . Další informace naleznete v tomto článku RedHat.
2. Průměr zatížení
Jednoduchá průměrná hodnota zatížení je stále nejjednodušší a nejrychlejší způsob, jak odhadnout zatížení serveru. To platí zejména pro servery Postgres, protože každý backend je samostatný proces operačního systému a více z nich ve spustitelném stavu zvýší průměrnou hodnotu zatížení.
Pro daný server Postgres by průměrná zátěž měla zůstat v rozumném rozsahu během obchodního cyklu (např. jeden týden, včetně spuštění dávkových úloh).
Akce:Sledujte průměrnou maximální zátěž za každý den/týden a prozkoumejte rostoucí trendy.
Jak na to :
Průměry zatížení 1 minuta, 5 minut a 15 minut jsou první 3 pole prvního řádku v souboru /proc/loadavg .
3. Volné místo na disku
Poslední položka v našem seznamu je nejzřejmější položkou ke sledování:množství volného místa na disku v každém souborovém systému používaném vaším PostgreSQL serverem, včetně tabulkových prostorů, adresářů souborů WAL, adresářů záloh a souborů protokolu serveru. V případech, kdy se v jednom souborovém systému vytvoří příliš mnoho (100 milionů) souborů, zajistěte, aby byl také sledován počet volných inodů. Nedostatek inodů je také hlášen jako nedostatek místa na disku.
Akce:Průběžně sledujte volné místo na disku a využití inodů na všech relevantních souborových systémech a upozorněte, pokud hodnoty klesnou pod nastavenou prahovou hodnotu.
Jak na to :
Volné místo na disku v souborovém systému nelze získat přímo čtením libovolného souboru v /proc . Můžete použít stat -f /path/to/mount nebo dokonce df pro zjištění použitého, volného a rezervovaného místa na disku pro konkrétní připojený souborový systém.
Rychlý průvodce
Zde je úplný seznam všech metrik, o kterých jsme v této sérii dosud diskutovali. Pamatujte, že se jedná pouze o minimální, nejpodstatnější sadu metrik, které musíte monitorovat, abyste odhalili, kdy se s vaším nasazením PostgreSQL chystají zmatkovat.
Úroveň clusteru
- Rozsah ID transakce
- Počet backendů
- Neaktivní replikační sloty
- Backendy čekající na zámky
- Backendy nečinné v transakci
- Prodleva replikace pro aktivní připojení
- Prodleva replikace pro replikační sloty
- Počet souborů WAL
- Počet souborů WAL připravených k archivaci
Úroveň databáze
- Připojení klienti
- Velikost
- Tabulka u všech stolů
- Indexové nafouknutí napříč všemi indexy
- Dlouhotrvající transakce
- Zablokování
- Nejstarší vysavač
- Nejstarší analýza
Úroveň tabulky
- Velikost tabulky
- Nafouknutí stolu
- Sekvenční prohledávání
Úroveň indexu
- Velikost indexu
- Index nadýmání
- Poměr přístupů do mezipaměti
Úroveň systému
- Použitá paměť
- Průměrné zatížení
- Uvolnit místo na disku
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 odeslat do naší komerční nabídky pgDash, která tyto zprávy ukládá a zpracovává za účelem zobrazení grafů a provádění výstrah.