VACUUM a ANALYZE jsou dvě nejdůležitější operace údržby databáze PostgreSQL.
Vakuum se používá k obnovení prostoru obsazeného „mrtvými n-ticemi“ v tabulce. Mrtvá n-tice se vytvoří, když je záznam odstraněn nebo aktualizován (odstranění následované vložením). PostgreSQL fyzicky neodstraní starý řádek z tabulky, ale umístí na něj „značku“, aby dotazy tento řádek nevrátily. Když běží vakuový proces, prostor obsazený těmito mrtvými n-ticemi je označen jako znovupoužitelný pro jiné n-tice.
Operace „analyzovat“ dělá to, co říká její název – analyzuje obsah tabulek databáze a shromažďuje statistiky o rozložení hodnot v každém sloupci každé tabulky. Dotazový stroj PostgreSQL používá tyto statistiky k nalezení nejlepšího plánu dotazů. Jak jsou řádky vkládány, odstraňovány a aktualizovány v databázi, mění se také statistika sloupců. ANALÝZA – buď spouštěná manuálně DBA nebo automaticky PostgreSQL po automatickém vakuování – zajišťuje aktuálnost statistik.
Ačkoli to zní poměrně přímočaře, zákulisí, vysávání a analýza jsou dva složité procesy. DBA se naštěstí o své vnitřnosti moc starat nemusí. Často jsou však zmateni ohledně ručního spouštění těchto procesů nebo nastavení optimálních hodnot konfiguračních parametrů.
V tomto článku se podělíme o několik osvědčených postupů pro VAKUUM a ANALÝZU.
Tip 1:Bezdůvodně nespouštějte ruční VAKUUM nebo ANALÝZU
PostgreSQL vakuování (automatické nebo ruční vakuování) minimalizuje nadýmání stolu a zabraňuje obtékání ID transakcí. Autovakuum neobnovuje místo na disku zabrané mrtvými n-ticemi. Nicméně spuštění VACUUM FULL příkaz tak učiní. VACUUM FULL má však svůj vliv na výkon. Cílová tabulka je během operace výhradně uzamčena, což zabraňuje i čtení na stole. Proces také vytvoří úplnou kopii tabulky, což při spuštění vyžaduje další místo na disku. Doporučujeme nespouštět VACUUM FULL, pokud nedochází k velmi vysokému procentu nadýmání a dotazy jsou velmi špatné. Také pro něj doporučujeme používat období nejnižší databázové aktivity.
Je také osvědčeným postupem neprovádět ruční vysávání příliš často v celé databázi; cílová databáze by mohla být již optimálně vysáta procesem autovakuování. V důsledku toho nemusí ruční vakuování odstranit žádné mrtvé n-tice, ale způsobit zbytečné zatížení I/O nebo špičky CPU. Pokud je to nutné, ruční vysavače by měly být spouštěny po jednotlivých stolech pouze tehdy, když je to potřeba, jako je nízký poměr živých řad k mrtvým řadám nebo velké mezery mezi automatickými vysavači. Ruční vysávání by také mělo být spuštěno, když je aktivita uživatele minimální.
Autovacuum také udržuje statistiky distribuce dat tabulky aktuální (neobnovuje je). Při ručním spuštění ANALYZE příkaz ve skutečnosti tyto statistiky znovu sestaví, místo aby je aktualizoval. Opětovné sestavení statistik, když jsou již optimálně aktualizovány běžným automatickým vysavačem, může způsobit zbytečný tlak na systémové prostředky.
Čas, kdy musíte spustit ANALYZE ručně, je bezprostředně po hromadném načtení dat do cílové tabulky. Velký počet (i několik stovek) nových řádků v existující tabulce výrazně zkresluje její rozložení dat ve sloupcích. Nové řádky způsobí, že všechny existující statistiky sloupců budou zastaralé. Když optimalizátor dotazů používá takové statistiky, může být výkon dotazu opravdu pomalý. V těchto případech je spuštění příkazu ANALYZE ihned po načtení dat za účelem úplného přebudování statistik lepší možností než čekat, až se spustí autovakuum.
Tip 2:Dolaďte prahovou hodnotu automatického vakua
Je nezbytné zkontrolovat nebo vyladit autovakuum a analyzovat konfigurační parametry na postgresql.conf souboru nebo ve vlastnostech jednotlivých tabulek, abyste dosáhli rovnováhy mezi automatickým vakuem a zvýšením výkonu.
PostgreSQL používá dva konfigurační parametry k rozhodnutí, kdy spustit autovakuum:
- autovacuum_vacuum_threshold :výchozí hodnota je 50
- autovacuum_vacuum_scale_factor :výchozí hodnota je 0,2
Tyto parametry společně říkají PostgreSQL, aby spustilo automatické vakuování, když počet mrtvých řádků v tabulce překročí počet řádků v této tabulce vynásobený měřítkovým faktorem plus prahová hodnota vakua. Jinými slovy, PostgreSQL spustí automatické vakuování na stole, když:
pg_stat_user_tables.n_dead_tup > (pg_class.reltuples x autovacuum_vacuum_scale_factor) + autovacuum_vacuum_threshold
U malých až středně velkých stolů to může stačit. Například u tabulky s 10 000 řádky musí být počet mrtvých řádků vyšší než 2 050 ((10 000 x 0,2) + 50), než se spustí automatické vakuování.
Ne každá tabulka v databázi zažívá stejnou rychlost úprav dat. U několika velkých tabulek obvykle dochází k častým úpravám dat a v důsledku toho bude mít vyšší počet mrtvých řádků. Výchozí hodnoty nemusí pro takové tabulky fungovat. Například s výchozími hodnotami bude potřeba, aby tabulka s 1 milionem řádků měla více než 200 050 mrtvých řádků, než se spustí automatické vakuování ((1 000 000 x 0,2) + 50). To může znamenat delší mezery mezi automatickým vysáváním, čím dál tím delší časy autovakuování a co je horší, autovakuum vůbec neproběhne, pokud jej blokují aktivní transakce na stole.
Cílem by proto mělo být nastavit tyto prahové hodnoty na optimální hodnoty, aby k automatickému vakuování mohlo docházet v pravidelných intervalech a netrvalo dlouho (a neovlivnilo uživatelské relace), přičemž počet mrtvých řad je relativně nízký.
Jedním přístupem je použití jednoho nebo druhého parametru. Pokud tedy nastavíme autovacuum_vacuum_scale_factor na 0 a místo toho nastavíme autovacuum_vacuum_threshold na řekněme 5 000, tabulka bude automaticky vakuována, když bude její počet mrtvých řádků větší než 5 000.
Tip 3:Dolaďte prahovou hodnotu automatické analýzy
Podobně jako autovakuum, autoanalýza také používá dva parametry, které rozhodují, kdy autovakuum také spustí autoanalýzu:
- autovacuum_analyze_threshold :výchozí hodnota je 50
- autovacuum_analyze_scale_factor :výchozí hodnota je 0,1
Podobně jako autovacuum lze parametr autovacuum_analyze_threshold nastavit na hodnotu, která určuje počet vložených, odstraněných nebo aktualizovaných n-tic v tabulce před zahájením autoanalýzy. Tento parametr doporučujeme nastavit samostatně na velkých stolech a stolech s vysokými transakcemi. Konfigurace tabulky přepíše hodnoty postgresql.conf.
Níže uvedený fragment kódu ukazuje syntaxi SQL pro úpravu nastavení autovacuum_analyze_threshold pro tabulku.
ALTER TABLE <table_name> SET (autovacuum_analyze_threshold = <threshold rows>)
Tip 4:Vylaďte pracovníky automatického vysávání
Dalším parametrem, který správci databází často přehlížejí, je autovacuum_max_workers , která má výchozí hodnotu 3. Autovakuum není jeden proces, ale několik paralelně běžících jednotlivých vakuových vláken. Důvodem pro určení více pracovníků je zajistit, aby vysávání velkých stolů nezdržovalo vysávání menších stolů a uživatelské relace. Parametr autovacuum_max_workers říká PostgreSQL, aby zvýšil počet pracovních vláken autovacuum, aby provedl vyčištění.
Běžnou praxí správců PostgreSQL DBA je zvýšit počet maximálních pracovních vláken v naději, že to urychlí autovakuování. Toto nefunguje, protože všechna vlákna sdílejí stejný autovacuum_vacuum_cost_limit , která má výchozí hodnotu 200. Každému vláknu automatického vakuování je přiřazen cenový limit pomocí následujícího vzorce:
individual thread’s cost_limit = autovacuum_vacuum_cost_limit / autovacuum_max_workers
Náklady na práci provedenou autovakuovým vláknem se vypočítávají pomocí tří parametrů:
- vacuum_cost_page_hit :toto má výchozí hodnotu 1
- vacuum_cost_page_miss :výchozí hodnota je 10
- vacuum_cost_page_dirty :výchozí hodnota je 20
Tyto parametry znamenají toto:
- Když vakuové vlákno najde ve sdílené vyrovnávací paměti datovou stránku, kterou má vyčistit, cena je 1.
- Pokud se datová stránka nenachází ve sdílené vyrovnávací paměti, ale v mezipaměti operačního systému, cena bude 10.
- Pokud musí být stránka označena jako špinavá, protože vakuové vlákno muselo odstranit mrtvé řádky, bude cena 20.
Zvýšený počet pracovních vláken sníží limit nákladů pro každé vlákno. Vzhledem k tomu, že každému vláknu je přiřazen nižší nákladový limit, přejde do režimu spánku častěji, protože se snadno dosáhne prahové hodnoty nákladů, což nakonec způsobí, že celý proces vakua bude probíhat pomalu. Doporučujeme zvýšit autovacuum_vacuum_cost_limit na vyšší hodnotu, například 2000, a poté upravit maximální počet pracovních vláken.
Lepší způsob je ladit tyto parametry pro jednotlivé tabulky pouze v případě potřeby. Pokud například automatické vakuování velké transakční tabulky trvá příliš dlouho, může být tabulka dočasně nakonfigurována tak, aby používala svůj vlastní limit nákladů na vakuování a zpoždění nákladů. Limit nákladů a zpoždění přepíší systémové hodnoty nastavené v postgresql.conf.
Níže uvedený fragment kódu ukazuje, jak nakonfigurovat jednotlivé tabulky.
ALTER TABLE <table_name> SET (autovacuum_vacuum_cost_limit = <large_value>) ALTER TABLE <table_name> SET (autovacuum_vacuum_cost_delay = <lower_cost_delay>)
Použití prvního parametru zajistí, že vlákno autovacuum přiřazené k tabulce vykoná před usnutím více práce. Snížení autovacuum_vacuum_cost_delay bude také znamenat, že vlákno spí kratší dobu.
Poslední myšlenky
Jak vidíte, změna konfiguračních parametrů pro vakuum a analýzu je přímočará, ale nejprve vyžaduje pečlivé sledování. Každá databáze se liší velikostí, vzorem provozu a rychlostí transakcí. Doporučujeme správcům databází začít tím, že před změnou parametrů nebo zavedením režimu ručního vakuování/analýzy shromáždí dostatek informací o své databázi. Takové informace mohou být:
- Počet řádků v každé tabulce
- Počet mrtvých n-tic v každé tabulce
- Čas posledního vakua pro každý stůl
- Čas poslední analýzy pro každou tabulku
- Poměr vkládání/aktualizace/mazání dat v každé tabulce
- Čas potřebný k automatickému vysávání pro každý stůl
- Upozornění na nevysávání stolů
- Aktuální výkon nejdůležitějších dotazů a tabulek, ke kterým přistupují
- Výkon stejných dotazů po ručním vakuování/analýze
Odsud mohou správci databází vybrat několik „pilotních“ tabulek a začít s optimalizací. Mohou začít měnit vlastnosti vakua/analyzovat u stolů a kontrolovat výkon. PostgreSQL je chytrý databázový stroj – správci databází často zjistí, že je pravděpodobně nejlepší nechat PostgreSQL provádět vysávání a analyzovat místo toho, aby je dělal ručně.