Trocha péče a péče o vaše nasazení PostgreSQL výrazně zajistí výkon, zabrání nepříjemným objevům a zajistí jistou předvídatelnost. Zde je 7 věcí, na které byste si měli dát pozor.
Tabulka nadýmání
PostgreSQL implementuje transakce pomocí techniky zvané MVCC. MVCC je příliš dlouhé a zahrnuje téma na podrobnou diskusi, ale existujítři věci, které musíte vědět o tom:
- Odstraněním řádku jej pouze označíte jako „neviditelný“ pro budoucí transakce.
- Aktualizací řádku se vytvoří nová verze řádku. Stará verze je označena jako neviditelná pro budoucí transakce a nová verze je označena jako viditelná.
- Pravidelně se někdo potřebuje podívat na všechny aktuálně probíhající transakce a říct:OK, nejstarší transakce je zde #42, takže každou verzi řádku, která je pro #42 neviditelná, lze fyzicky smazat, aniž by byla narušena konzistence dat.
Tak funguje MVCC (v podstatě) a z toho vyplývá, že aktualizace budou zvětšit prostor úložiště fyzické databáze a odstranění nebude snížit. MVCC zní jako líný způsob, jak dělat věci, ale je populární, protože poskytuje konzistenci i výkon.
Nechtěné, zastaralé verze řádků v tabulce se nazývají nadýmání (nebo mrtvé ). Proces, který dokáže odstranit nadýmání, se nazývá vakuum . PostgreSQL má automaticky spouštěný vakuový proces s laditelnými prahy nazývanými autovacuum a samozřejmě příkaz VACUUM.
Obecně platí, že bloat může také zpomalit dotazy kvůli nepřesným mapám viditelnosti a plýtvání I/O disku.
Z tohoto důvodu byste měli pravidelně:
- monitorujte množství nadýmání v databázi
- pravidelně vysávejte
- monitorujte, zda se vakuum pravidelně spouští u všech stolů
Existuje několik dotazů SQL, které poskytují odhady nadýmání podle tabulky. Open source toolpgmetrics poskytuje odhady nadýmání a také poslední provozní doby ručního a automatického vakua.
Index nadýmání
Indexy mohou také nafouknout. Přestože je vnitřní struktura indexů pro uživatele SQL neprůhledná a liší se podle typu indexu (BTree, hash, GIN, GIST atd.), obecnou myšlenkou zůstává, že když jsou řádky, na které se index odkazuje, odstraněny, prostor zabírá související informace. uvnitř indexu je pouze logicky odstraněn a není uvolněn zpět do souborového systému. Logicky odstraněný prostor může být později znovu použit indexem.
Existují dva způsoby, jak přimět Postgres, aby zmenšil fyzickou velikost indexu:
- PLNÁ verze příkazu VACUUM
- REINDEX
Nafouknutí indexu musí být monitorováno, abyste si byli vědomi alespoň zbývajícího nevyužitého prostoru. V tabulkách s vysokým počtem řádků není neobvyklé nastavit pravidelné úlohy obnovy indexu.
Index bloat lze také získat stejnými dotazy jako dříve a také prostřednictvím pgmetrics.
Dlouhotrvající transakce
Transakce by měly být co nejkratší, zejména v systému MVCC.
Představte si, že transakce začala včera a těsně poté následovalo vakuové spuštění. Dokud je tato transakce otevřená, další vakuování jsou k ničemu, protože naše transakce bude muset podle definice vidět všechny řádky všech tabulek tak, jak byly, když naše transakce včera začala. I když je naše transakce pouze pro čtení, stále tomu tak je.
Výsledkem je, že dlouhodobé transakce vytvářejí nadýmání. Také visí na systémových prostředcích, drží neopuštěné zámky a zvyšují šance na uváznutí.
Nejlepší způsob, jak si dávat pozor na dlouho běžící transakce, je nastavit upozornění na počet transakcí, které probíhají déle než určitou dobu. Můžete to získat ze zobrazení statistikpg_stat_activity , asi takhle:
-- number of transactions that have been open for
-- more than 1 hour
SELECT count(*) FROM pg_stat_activity WHERE xact_start < now()-'1 hour'::interval;Prodleva replikace
Když se streamingová replikace používá k replikaci všech změn z primárního PostgreSQL serveru do horkého pohotovostního režimu (neboli repliky pro čtení), existuje obvykle malé zpoždění mezi okamžikem, kdy dojde k aktualizaci řádků na primárním serveru, a okamžikem, kdy jsou změny viditelné pro aplikace připojené k pohotovostnímu režimu. .
Existují však případy, kdy se toto zpoždění může zvýšit:
- pohotovostní systém není schopen přijímat a aplikovat změny z primárního dostatečně rychle, aby s ním držel krok, obvykle kvůli vysokému zatížení nebo nedostatečnému zabezpečení
- degradovaná síť nebo disk
- konflikty dotazů
Pohotovostní režim s vysokým nebo ještě horším, rostoucím zpožděním replikace může vést k dotazům na pohotovostní režim, které vracejí zastaralá data, a pohotovostní režim, který není vhodný pro přepnutí při selhání.
Pokud máte nastavenou streamovanou replikaci, je monitorování zpoždění replikace mezi každým primárním a pohotovostním párem velmi důležité a budete chtít nastavit upozornění, abyste zjistili, zda zpoždění replikace nepřekročí minutu nebo jakýkoli práh, který má pro vaše nastavení smysl.
Tento příspěvek obsahuje mnohem více o tom, jak měřit a monitorovat zpoždění replikace z primárního i pohotovostního režimu.
Neaktivní replikační sloty
Použití replikačních slotů, představených v PostgreSQL 9.4, dělá streamingreplication robustnější a efektivnější. V podstatě pohotovostní režim hlásí průběh replikace primárnímu zařízení, které tyto informace ukládá do „replikačního slotu“.
Z tohoto důvodu nyní primář vždy ví, jak daleko za pohotovostním režimem. To umožňuje primárnímu ponechat dostatečné množství nevyřízených souborů WAL (které jsou potřeba k obnovení replikace), když pohotovostní režim přejde do režimu offline. Když se tedy pohotovostní režim vrátí, dokonce i po dlouhé době, může primární zařízení stále zaručit, že replikace může být obnovena.
Před replikačními sloty může primární vyčistit staré soubory WAL, protože neměl jak vědět, zda je pohotovostní režimy potřebují nebo ne. Pokud je odstraněn soubor WAL potřebný pro astandby, neexistuje způsob, jak obnovit replikaci; musí se znovu nastavit od nuly.
Primární chování při uchovávání souborů WAL na dobu neurčitou však vede k dalšímu problému. Pokud byl pohotovostní režim vyřazen a přidružený replikační slot nebyl odstraněn, soubory WAL budou zachovány navždy. Soubory WAL uchovávané z tohoto důvodu nepodléhají limitům stanoveným max_wal_size a další možnosti konfigurace.
Tato situace bude přetrvávat, dokud soubory WAL nezaberou celý diskový prostor, a to ani bez varování v souborech protokolu PostgreSQL.
Netřeba dodávat, že neaktivní replikační sloty je třeba řešit, když jsou detekovány. Najděte své neaktivní replikační sloty pomocí:
SELECT slot_name FROM pg_replication_slots WHERE NOT active;Analyzovat stav
ANALÝZA se spouští na tabulkách za účelem shromažďování a aktualizace statistických informací o obsahu tabulky. Tyto informace používá plánovač dotazů k přípravě plánu provádění pro každý dotaz SQL. Aktuální statistiky o obsahu tabulky vedou k lepšímu plánu provádění, což zase vede k rychlejšímu dotazování.
Démon autovacuum obvykle po VACUUM spouští ANALYZE. To však pro ANALYZE nemusí být dostatečně časté. Pokud distribuce dat v tabulce se často mění, měli byste spouštět ANALYZE častěji.
Typicky se ANALYZE chová docela dobře – potřebuje pouze zámky pro čtení, nespotřebovává příliš mnoho zdrojů a dokončí se v rozumném čase. Je bezpečné toerr na straně běžet to častěji než ne.
Dávat si pozor na stoly, které nebyly nějakou dobu analyzovány, je dobrý nápad. Zjistěte, kdy byly vaše tabulky (automaticky) analyzovány naposledy pomocí dotazu:
SELECT schemaname || '.' || relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables;Využití zdrojů
Sledování zátěže procesoru, paměti a využití disku značně přispívá k zajištění toho, že budete mít po ruce dostatečnou kapacitu pro uspokojení rostoucích potřeb aplikací využívajících vaši databázi.
PostgreSQL vytvoří jeden proces pro zpracování jednoho připojení. I když to v dnešní době možná není nejvíce škálovatelná architektura, hodně přispívá ke stabilitě. Díky tomu je průměrná zátěž OS smysluplnější. Jako obvykle PostgreSQLboxy provozují pouze PostgreSQL, průměrná zátěž řekněme 3 obvykle znamená, že existují 3 připojení čekající na zpřístupnění jader CPU, která mohou být naplánována. Sledování průměrné maximální zátěže během typického dne nebo týdne může poskytnout odhad nadměrně nebo nedostatečně zásobované jednotky na přední straně CPU.
Paměť a volné místo na disku jsou samozřejmě standardní věci, které je třeba sledovat. Více připojení a déle běžící transakce kladou vyšší nároky na paměť. A při monitorování volného místa na disku nezapomínejte sledovat jej podle tabulkového prostoru.