it-swarm-eu.dev

Měl bych ručně VACUUM svou PostgreSQL databázi, pokud je zapnuto autovacuum?

Používám software, který vytváří velkou databázi PostgreSQL (je v ní tabulka s miliony řádků) a vývojáři říkají, že bych měl pravidelně VACUUM a ANALYZE. Výchozí databáze PostgreSQL je však zapnuta autovacuum.

Měl bych vůbec vysát/analyzovat? Jaké jsou výhody? Jaký je rozdíl mezi automatickým a manuálním vakuem?

Například v Pgadmin3 mám toto:
enter image description here

15
kissgyorgy

Souhlasím s ETL, že neexistuje krátká odpověď. Velikost není jediná věc, na které záleží - provozujeme poměrně velké PostgreSQL OLTP Databáze (s některými tabulkami> 100 000 000 řádků) při velkém zatížení a v současné době se spoléháme pouze na autovakum.

Přesto se mi zdají důležité dvě věci:

  • Zdá se, že existuje konsenzus, že autovacuum by nikdy nemělo být nikdy vypnuto, pokud nemáte v databázi velmi dobře definovanou pracovní zátěž a přesně nevíte, co dělají. Ale samozřejmě byste mohli udělat další běhy VACUUM a/nebo ANALYZE.

  • Než jsem zvážil další běhy VACUUM, zkontroloval jsem, jak autovacuum udržuje krok. Můžete zkontrolovat, zda jsou některé tabulky nad prahem autovakuum dotazem pg_stat_user_tables a pg_class. Takový dotaz jsem poslal na jiné vlákno, které by mohlo být zajímavé: Agresivní autovacuum na PostgreSQL .

    Bohužel není tak snadné (tj. V současné době to není možné) provést podobnou kontrolu prahů autoanalýzy. Ve výchozím nastavení však autoanalyze začíná dlouho před autovaku a je mnohem levnější. Takže, pokud vaše databáze dokáže držet krok s autovaku, bude pravděpodobně v pořádku i s automatickou analýzou. Poslední data autoanalyze lze také dotazovat od pg_stat_user_tables.

Některé části (nejvhodnější) dokumentace PostgreSQL, které mi připadaly užitečné:

12
pygrac

Autovacuum by to mělo docela dobře pokrýt, pokud jste něco nesprávně nakonfigurovali. Ostatní odpovědi to již pokrývají.

Existuje jeden jasně definovaný případ pro manuálníVACUUM (a co je důležitější: manuální ANALYZE) i když: dočasné tabulky , nejsou autovakomém démonem považovány. Cituji příručka k CREATE TABLE zde :

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.

7

Na to neexistuje žádná krátká odpověď, protože to závisí na mnoha faktorech. Je systém pomalý? Dotýká se auto-vakua této tabulky? atd.

Zde je několik dobrých odkazů na toto téma:

Jasné rozhodnutí vyžaduje pochopení samotné databáze a více podrobností o tom, co se děje.

4
ETL

Nemyslím si, že musíte ručně vakuum, pokud nezačnete vidět zhoršení výkonu. Doporučuji však zkontrolovat nastavení vakua a autovaku a vyladit je podle svých potřeb

Chcete-li zobrazit aktuální nastavení, spusťte tento dotaz:

SELECT *
FROM pg_settings 
WHERE name LIKE '%vacuum%'

Většina polí je samozřejmá, ale zde je k nim dokumentace: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html

Řekl bych, že vaším cílem by mělo být nakonfigurovat autovakum pro důsledné čištění odpadků, ale autovakuum neprovozujte neustále

Nejdůležitější nastavení jsou:

  • autovacuum_vacuum_scale_factor - určuje procento n-tic, které mohou být mrtvé před spuštěním vyčištění. Výchozí hodnota = 0,2
  • autovacuum_vacuum_threshold - minimální počet mrtvých tuplů před spuštěním vyčištění. Výchozí hodnota = 50

Prahová hodnota pomáhá zabránit příliš častému spuštění procesu čištění u malých stolů.

Výchozí nastavení funguje dobře, pokud nemáte velmi velké tabulky. Jednoduše řečeno, pokud náhodou máte stůl, který zabírá 100 GB, nahromadíte 20 GB odpadu, než se spustí autovakum. Obvykle proto doporučuji nastavit faktor měřítka na nízkou hodnotu. Jak nízko byste měli určit sami. Pro svůj aktuální projekt používám 0,05

Prahové hodnoty lze také zvýšit. Mnoho aplikací má několik tabulek, které jsou často aktualizovány a 50 n-tic není tak moc. Zvýšení na 1000 by nemělo vést k žádným problémům, ale samozřejmě byste měli zvážit svůj vlastní případ

Můžete také doladit autovacuum a mít různá nastavení pro některé své tabulky

ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);

Pokud nakonfigurujete scale_factor a prahy, měli byste být v pořádku. Můžete také zvýšit autovacuum_vacuum_cost_limit, což se ve výchozím nastavení rovná vacuum_cost_limit, která je nastavena na 200. Toto je velmi důležitá funkce vakua, která mu neumožňuje spotřebovat všechny zdroje a umožňuje vaší aplikaci pracovat s daty i během procesu vakuování, ale výchozí hodnota je příliš nízká. Zvýšení na 1000 by nemělo vést k žádným výrazným zpožděním, ale umožní vakuovému procesu skončit mnohem rychleji

Vakuum můžete samozřejmě také spustit ručně. V nejjednodušším případě můžete mít jednoduchou cronovou práci, která provede úplné vyčištění každou noc, když vaše DB není často přístupná

Doufám, že to pomůže!

1
Hasan Ammori