db.dobo.sk

Postgres – vsetko, co si chtel vediet, ale bal sa spytat svojho seniora, aby si nevypadal ako jelito 02 – vakuova pumpa

bez komentára

VACUUM je automaticky a rucny sposob, ako si precistit tabuulky od bloatu (nevadidnych spinavych zaznamov). Ako znie slavny bonmot – vakuujte, co to ide.

 ako dochadza k bordelu

Postgres pouziva multi-version concurrency control pre zabezpecenie konzistencie dat v priebehu transakcneho zpracovania. Znamena to, ze kazda transakcia prebieha nad svojim vlastnym snapshotom databaze a preto pripadne delety neznamenaju hned vymazanie tuple, ale jeho oznacenie za nevalidny (a pri naslednom dotazovani dat sa aplikuje visibilty filter nad nevalidnymi datami). Potom sa spusti upratovacia rutina, ktora vsetky nevalidne tuples zlikviduje – a to je vacuum. Pokial sa vacuum nespusti, tak databaza funguje, dava validne vysledky, ale vyrazne rastie jej velkost kvoli mrtvym datam. A jej aj pomalsia, of course.

co v skutocnosti vaccuming robi

4 veci:

  • - oznaci dead rows za schopne zapisovat nove data (v skutocnosti ich samozrejme nemaze)
  • - updatne visibility map
  • - ochranuje pred problemom transaction ID wrapparound tym, ze robi freezing transaction IDs
  • - spusta rutinu ANALYZE, ktora skuma zmenovost tabuliek a pripravuje planovac pre VACUUM. Sucast statistickeho kolektoru.

typy vakuovania

VACUUM pracuje v 2 rezimoch – AUTOVACUUM (alebo concurrent vacuum) a FULL VACUUM. Rozdiel je v tom, ze ten prvy sa standardne spusta automaticky (nastavenie v hlavnom konfigu) a dovoluje z tabulky medzitym citat, tak full vacuum vyhradne zamkne tabulku a nazdar. Vacsinou sa spusta rucne a mimo produkcne okno.

Kedy prebehol VACUUM a akeho typu?

SELECT relname, last_vacuum, last_autovacuum, last_autoanalyze FROM pg_stat_user_tables;

je nutne vakuovat? ako su na tom data?

Pro posudzovani zabordelenia databaze se sleduje:

pocet bloatov v tabulkach (dead rows/tuples): SELECT relname, n_dead_tup FROM pg_stat_user_tables;

velkost 10 najvecsich tabuliek v DB na disku:

SELECT relname, pg_size_pretty(pg_table_size(C.oid))
FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT IN (‘pg_catalog’, ‘information_schema’) AND nspname !~ ‘^pg_toast’ AND relkind IN (‘r’)
ORDER BY pg_table_size(C.oid)
DESC LIMIT 10;

 bezna diagnostika spojena s vakuovou pumpou

bezi daemon autovacuum? – ps -ef | grep autovacuum

je povoleny autovacuum pre databazu?  – SELECT name, setting FROM pg_settings WHERE name=’autovacuum’;

Je povoleny statisticky kolektor? – SELECT name, setting FROM pg_settings WHERE name=’track_counts’;

Pozor! Aj pri povolenom autovacuum v Db je mozne, ze su tam tabulky, ktore maju autovacuum zakazany. Ktore to su? – SELECT relname, reloptions FROM pg_class WHERE reloptions=’{autovacuum_enabled=false}’;

Prehlad vsetkych parametrov autovacuumu (defalut i overadj) v systemovom katalogu – SELECT * from pg_settings where category like ‘Autovacuum’;

kedy sa spusta autovacuum?

Autovacuum sa spusta, ked pocet dead_rows (bloat tuples) dosiahne cislo X. Cislo X s apocita formulou (k premennym vid predchadzajuci dotaz k parametrom autovacuumu):

X = autovacuum_vacuum_threshold + (autovacuum_vacuum_scale_factor * estimated number of rows in the table)

Co to znamena? Scale faktor som videl v produkcii nastaveny na 0.1 a 0.2. T.j. pokial je dead rows aspon 50 a je to jedna desatina/jedna patina poctu datovych rows, mal by sa spustit autovacuum.

specialne problemy

Dlhe transakcie – lockuju rows. Zaznam o sessnach a tym padom i o idle dlhych transakciach je pristupny cez pg_stat_activity – SELECT xact_start, state, usename FROM pg_stat_activity;

Lock konflikt pri VACUUM – plny vakuum zaklada zamok SHARE UPDATE EXCLUSIVE LOCK, ktory je v pripadnom konflikte s inymi lockmi pochadzajucimi od transakcii.

 

special: pg_repack

Vacuum ma tu nevyhodu, ze nejakym sposobom na chvilu vzdy tabulku odstavi (rozne typy lockov) – v pripade vacuum full zamkne celu tabulku pre ready i writy. V realnom produkcnom prostredi tak napr. full vacuum nie je mozne spustit nikdy…

Existuje extension pg_repack, ktora pracuje tak, ze vytvori kopiu tabulky, zkopiruje do nej data zo starej tabulky (cim tu haldu “strepe” dole) a vytvori nad nou novy index. Potom switchne sessny na novu tabulku. to bez toho, aby tam bol nejaky lock nad tabulkou…

Dobry blog k nasadeniu pg_repack je na strankach percony.

píše: ďobo

Júl 15th, 2018 o 10:32 am

chlievik: postgresql

okomentuj