it-swarm-eu.dev

Jsou pravidelné VACUUM ANALYZE doporučeny podle 9.1?

Používám PostgreSQL 9.1 na Ubuntu. Jsou naplánovány VACUUM ANALYZE stále se doporučuje, nebo je autovakumát dostatečně postaráno o všechny potřeby?

Pokud je odpověď „záleží“, pak:

  • Mám obrovskou databázi (30 GiB komprimovaná velikost výpisu, 200 GiB datový adresář)
  • Do databáze dělám ETL, importuji téměř 3 miliony řádků týdně
  • Tabulky s nejčastějšími změnami jsou všechny zděděny z hlavní tabulky bez dat v hlavní tabulce (data jsou rozdělena podle týdnů)
  • Vytvářím hodinové souhrny a odtud denní, týdenní a měsíční přehledy

Ptám se, protože naplánované VACUUM ANALYZE má vliv na mé hlášení. Trvá to déle než 5 hodin a musel jsem to zabít dvakrát tento týden, protože to mělo dopad na pravidelné importování databáze. check_postgres nehlásí žádné významné nadýmání v databázi, takže to ve skutečnosti není problém.

Z dokumentů by se autovacuum mělo postarat také o obal ID transakcí. Otázka zní: Potřebuji ještě VACUUM ANALYZE?

postgresqletlvacuum
38
François Beausoleil

VACUUM je potřeba pouze u aktualizovaných nebo odstraněných řádků v dočasných tabulkách. Je zřejmé, že děláte spoustu INSERTů, ale z popisu není patrné, že také děláte spoustu UPDATE nebo DELETE.

Tyto operace lze sledovat pomocí pg_stat_all_tables view, konkrétně n_tup_upd a n_tup_del sloupců. A ještě více je zde n_dead_tup sloupec, který podle tabulky uvádí, kolik řádků je třeba vysát. (viz Statistiky monitorování v dokumentu týkající se funkcí a pohledů souvisejících se shromažďováním statistik).

Možnou strategií ve vašem případě by bylo potlačení plánovaného VACUUM, sledování tohoto pohledu a kontrola, na kterých tabulkách je n_dead_tup výrazně stoupá. Potom aplikujte agresivní VACUUM pouze na tyto tabulky. To bude vítězství, pokud existují velké tabulky, jejichž řádky se nikdy neodstraní ani neaktualizují a agresivní VACUUM je opravdu nutné pouze na menších stolech.

Ale pokračujte v analýze ANALYZE, aby optimalizátor měl vždy čerstvé statistiky.

32
Daniel Vérité

Ve vaší otázce nevidím nic, o co by se autovacuum nestaral. Z velké části to závisí na vzorci vašich písemných aktivit . Zmíníte 3 miliony nových řádků týdně, ale INSERT (nebo COPY) obvykle nevytvářejí nadýmání tabulek a indexů. (autovacuum se musí starat pouze o statistika sloupců , mapa viditelnosti a některé menší úlohy). UPDATE a DELETE jsou dominantní příčinou nadýmání tabulek a indexů, zejména při cílení na náhodné řádky. Ve vaší otázce nic z toho nevidím.

autovacuum prošel dlouhou cestu a dělá skvělou práci v Postgres 9.1 nebo novější. Podíval bych se na nastavení autovacuum . Pokud má vysávání tendenci narušovat vaši pracovní zátěž, podívejte se také na „Nákladové zpoždění vakua“ . Manuální vysávání by mělo být vzácnou výjimkou.

Pokud máte spoustu náhodných UPDATEs, možná budete chtít nastavit FILLFACTOR na něco menšího než 100, abyste mohli HOT aktualizace okamžitě a snížit potřebu VACUUM. Více o HOT aktualizacích:

Také si všimněte, že dočasné tabulky vyžadují manuální VACUUM & ANALYZE. Cituji příručka k CREATE TABLE :

autovacuum daemon nemůže získat přístup, a proto nemůže vysát ani analyzovat dočasné tabulky. Z tohoto důvodu by měly být prováděny vhodné operace vakua a analýzy pomocí příkazů SQL relace. Pokud se například dočasná tabulka použije ve složitých dotazech, je rozumné spustit po dočasné naplnění ANALYZE v dočasné tabulce.

25
Erwin Brandstetter

Přestože souhlasím s tím, že použití automatických funkcí je nejlepší místo toho, aby byla spuštěna celá databáze, ve většině případů je nutné vyladění podle tabulky.

Nesouhlasím s návrhem výběru postgresu, který by spojil vakuum a analýzu, viděl jsem několik případů, kdy databáze, které provádějí mnoho vkládání/aktualizací, ale malé mazání, nikdy neprovádějí analýzu a nezačnou hrát špatně.

Řešením je přejít do tabulek, které se intenzivně využívají a jsou předmětem velkých dotazů, a nastavit nastavení automatické analýzy pro tyto tabulky na něco, na co se analyzují jednou nebo každý druhý den.

K nastavení jednotlivých tabulek se dostanete v grafu na kartě auto vakua a uvidíte tam analýzu nastavení, která můžete nastavit nezávisle na vakuu.

Nastavení končí v tabulce relopcí a lze jej zobrazit pomocí dotazu

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

a tam může být ukázková hodnota agresivní analýzy

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Chcete-li zjistit, kdy byl váš stůl naposledy analyzován automaticky analyzovaným dotazem

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;
6
MvcCmsJon