PostgreSQL DB na Linuxu roste nad všechny meze

Re:PostgreSQL DB na Linuxu roste nad všechny meze
« Odpověď #15 kdy: 06. 05. 2020, 18:53:52 »

Už jsem blízko vakuování, jen dvě otázky:
- má smysl předtím pustit vacuum analyze ?
- tabulka má velikost 14GB, ale místo v / je jen 3.8GB (proto to celé dělám) Dojede to do konce ? pokud ne, vadí to ?
Ještě jednou moc díky

Ne, proč? Pokud má bloat faktor vysoký, tak se to může povést, pokud ne, tak se to nepovede a spadne vám to na nedostatek místa na disku. U toho nedostatku místa na disku je relativně malá šance na poškození databáze, pokud byste tam měl nějakou starší neaktualizovanou verzi PG a zároveň dělal další operace. Pokud má tabulka 14GB a místo na disku je 3.8GB, a nic moc jste tam nepromazal (obsah dat je 12-14GB), tak to moc smysl nedává. Pokud budete mít stejně nějakou odstávku, tak můžete podropovat nějaké indexy, tím si uvolníte prostor na disku, a pak je znovu vytvoříte.

A tak si říkám, jak pak asi zálohujete.


Re:PostgreSQL DB na Linuxu roste nad všechny meze
« Odpověď #16 kdy: 06. 05. 2020, 20:00:14 »

Už jsem blízko vakuování, jen dvě otázky:
- má smysl předtím pustit vacuum analyze ?
- tabulka má velikost 14GB, ale místo v / je jen 3.8GB (proto to celé dělám) Dojede to do konce ? pokud ne, vadí to ?
Ještě jednou moc díky

Ne, proč? Pokud má bloat faktor vysoký, tak se to může povést, pokud ne, tak se to nepovede a spadne vám to na nedostatek místa na disku. U toho nedostatku místa na disku je relativně malá šance na poškození databáze, pokud byste tam měl nějakou starší neaktualizovanou verzi PG a zároveň dělal další operace. Pokud má tabulka 14GB a místo na disku je 3.8GB, a nic moc jste tam nepromazal (obsah dat je 12-14GB), tak to moc smysl nedává. Pokud budete mít stejně nějakou odstávku, tak můžete podropovat nějaké indexy, tím si uvolníte prostor na disku, a pak je znovu vytvoříte.

A tak si říkám, jak pak asi zálohujete.
Díky moc. ....tak to moc smysl nedává... co nedává smysl, dělat to vacuum ?
S tím zálohováním, já se nechci moc odkopat, ale mám obraz té mašiny, nic jiného ani nejde. Navíc je to clusterované , tak ji v nejhorším přeinstaluju.
Problém je v tom, že ta tabulka pg_largeobject je 40x větší než zbytek databáze, tak není moc co podstatného smazat.
Musím něco udělat s ním, zkusím asi to vacuum ?

Edit .. kdepak, místo došlo asi po minutě. Zkusím napřed nafouknout LV.

« Poslední změna: 06. 05. 2020, 20:05:14 od FKoudelka »

Re:PostgreSQL DB na Linuxu roste nad všechny meze
« Odpověď #17 kdy: 06. 05. 2020, 20:18:51 »

Už jsem blízko vakuování, jen dvě otázky:
- má smysl předtím pustit vacuum analyze ?
- tabulka má velikost 14GB, ale místo v / je jen 3.8GB (proto to celé dělám) Dojede to do konce ? pokud ne, vadí to ?
Ještě jednou moc díky

Ne, proč? Pokud má bloat faktor vysoký, tak se to může povést, pokud ne, tak se to nepovede a spadne vám to na nedostatek místa na disku. U toho nedostatku místa na disku je relativně malá šance na poškození databáze, pokud byste tam měl nějakou starší neaktualizovanou verzi PG a zároveň dělal další operace. Pokud má tabulka 14GB a místo na disku je 3.8GB, a nic moc jste tam nepromazal (obsah dat je 12-14GB), tak to moc smysl nedává. Pokud budete mít stejně nějakou odstávku, tak můžete podropovat nějaké indexy, tím si uvolníte prostor na disku, a pak je znovu vytvoříte.

A tak si říkám, jak pak asi zálohujete.
Díky moc. ....tak to moc smysl nedává... co nedává smysl, dělat to vacuum ?
S tím zálohováním, já se nechci moc odkopat, ale mám obraz té mašiny, nic jiného ani nejde. Navíc je to clusterované , tak ji v nejhorším přeinstaluju.
Problém je v tom, že ta tabulka pg_largeobject je 40x větší než zbytek databáze, tak není moc co podstatného smazat.
Musím něco udělat s ním, zkusím asi to vacuum ?

Edit .. kdepak, místo došlo asi po minutě. Zkusím napřed nafouknout LV.

To nedává se vázalo na VACUUM ANALYZE. Samozřejmě, že netuším, co v těch blobech je, ale pokud se používají, tak jsou běžně řádově větší než zbytek databáze. Kdysi u jedné aplikace měli vystavený formulář s možností přílohy. Za pár let měli docela slušnou sbírku virů. Databáze měla 300GB, a bloby možná 250.

Re:PostgreSQL DB na Linuxu roste nad všechny meze
« Odpověď #18 kdy: 06. 05. 2020, 22:35:47 »
Postgres boptna, protoze se chova k prostoru na disku podobne jako Java k pameti, "naalokuje co muze". Resp. kdyz budete mit tabulku, kde mate hodne UPDATE a DELETE tak se zachovavaji transakce i data, postgres si oznaci data jako smazane, ale neuvolni misto na disku pro system. Cili to pak vypada, ze vam vytece z disku, ale on nevytece, v pripade, ze zacne mit kriticky malo mista na disku, 1-2GB tak teprve potom zacne tyhle "sektory" pouzivat znovu, sam pro sebe. Autovacuum vam nepomuze, resp. ted nevim jestli je to od verze 11 nebo 12, ale doporucuju udelat FULL VACUUM, bohuzel to ma exklusivni locky, takze opatrne (u 12 ma prikaz vacuumdb moznost nezamikat tabulky - viz manual). Doporucuju vybrat "top 10" nejvetsich databazi, seradit vzestupne dle velikosti, per databazi pak udelat to same s tabulkama a pustit full vacuum per tabulka. Kdyz zacnete s mensima, uvolni to misto na vacuuming vetsich tabulek. Pocitejte, ze na tabulky 1GB je treba 2GB na disku na full vacuum, proto zacinat od mensich, uvolni misto pro vetsi.

Jak na to vsechno viz dokumentace: https://wiki.postgresql.org/wiki/Disk_Usage

Takto se to samozřejmě nechová. V detailech jste úplně mimo. Nic ve zlém, ale pokud něčemu nerozumím, tak je lepší mlčet. Bohužel internet je zaplněný špatnými dobrými radami.

Bez přihlášení do db žádnou administraci neuděláte. Lze něco detekovat na souborovém systému, ale je to dost pracnější, a navíc hloupost - pokud zákazník si databázi neadministruje sám, a ani nezplnomocní k tomu Vás, tak to jednou musí dopadnout špatně a je to signál, že něco ve vztahu vy, váš zákazník je špatně.

Podívejte se do tabulky pg_stat_activity jestli nenajdete neuzavřenou transakci - state: "idle in transaction". To blokuje VACUUM, a pokud VACCUUM neaktualizuje mapu volného místa v datovém souboru, tak engine neví, že tam volné místo a zvětšuje soubor. Zkontrolujte log - dost často se jedná o aplikační chybu - čistící funkce padají na syntaktických chybách, timeoutech, ..  Podívejte se jestli nějaké tabulky nejsou přefouklé https://wiki.postgresql.org/wiki/Show_database_bloat - pak aplikujte VACUUM FULL. Zkontrolujte jestli si zákazník nevypnul autovacuum.

Zdravim Pavle,

z nejakeho duvodu mate jinou zkusenost nez mam ja. Priklad uziti https://moodle.org/mod/forum/discuss.php?d=68558, kdyz pustite napr skript co vam prepise linky v db napr: https://docs.moodle.org/38/en/Search_and_replace_tool , vic dat, vetsi efekt. Postgres vam naboptna celkem hezky, si to klidne vyzkousejte: https://www.percona.com/blog/2018/08/06/basic-understanding-bloat-vacuum-postgresql-mvcc/

https://www.postgresql.org/docs/12/routine-vacuuming.html
https://www.postgresql.org/docs/9.5/routine-vacuuming.html

A chovalo se mi to jak jsem psal, kdyz uz musite ten full vacuum udelat a je malo mista, dobry zacit od mensich tabulek.

@FKoudelka:
Po full vacuum uvidi system vice volneho mista. Kdyz by vam to s volnym mistem nevyslo, tak postgres to ustoji, nic vam nespadne, teda alespon mne nespadnul (uprime jsem cekal ze spadne). To co full vacuum nepretridi , uvolni, budete zpatky kde jste byl "na 3.8GB". Jestli se vam nechce riskovat, tak si treba soupnete nektery tabulky na jinej disk jestli muzete.

Re:PostgreSQL DB na Linuxu roste nad všechny meze
« Odpověď #19 kdy: 07. 05. 2020, 06:03:10 »
Postgres boptna, protoze se chova k prostoru na disku podobne jako Java k pameti, "naalokuje co muze". Resp. kdyz budete mit tabulku, kde mate hodne UPDATE a DELETE tak se zachovavaji transakce i data, postgres si oznaci data jako smazane, ale neuvolni misto na disku pro system. Cili to pak vypada, ze vam vytece z disku, ale on nevytece, v pripade, ze zacne mit kriticky malo mista na disku, 1-2GB tak teprve potom zacne tyhle "sektory" pouzivat znovu, sam pro sebe. Autovacuum vam nepomuze, resp. ted nevim jestli je to od verze 11 nebo 12, ale doporucuju udelat FULL VACUUM, bohuzel to ma exklusivni locky, takze opatrne (u 12 ma prikaz vacuumdb moznost nezamikat tabulky - viz manual). Doporucuju vybrat "top 10" nejvetsich databazi, seradit vzestupne dle velikosti, per databazi pak udelat to same s tabulkama a pustit full vacuum per tabulka. Kdyz zacnete s mensima, uvolni to misto na vacuuming vetsich tabulek. Pocitejte, ze na tabulky 1GB je treba 2GB na disku na full vacuum, proto zacinat od mensich, uvolni misto pro vetsi.

Jak na to vsechno viz dokumentace: https://wiki.postgresql.org/wiki/Disk_Usage

Takto se to samozřejmě nechová. V detailech jste úplně mimo. Nic ve zlém, ale pokud něčemu nerozumím, tak je lepší mlčet. Bohužel internet je zaplněný špatnými dobrými radami.

Bez přihlášení do db žádnou administraci neuděláte. Lze něco detekovat na souborovém systému, ale je to dost pracnější, a navíc hloupost - pokud zákazník si databázi neadministruje sám, a ani nezplnomocní k tomu Vás, tak to jednou musí dopadnout špatně a je to signál, že něco ve vztahu vy, váš zákazník je špatně.

Podívejte se do tabulky pg_stat_activity jestli nenajdete neuzavřenou transakci - state: "idle in transaction". To blokuje VACUUM, a pokud VACCUUM neaktualizuje mapu volného místa v datovém souboru, tak engine neví, že tam volné místo a zvětšuje soubor. Zkontrolujte log - dost často se jedná o aplikační chybu - čistící funkce padají na syntaktických chybách, timeoutech, ..  Podívejte se jestli nějaké tabulky nejsou přefouklé https://wiki.postgresql.org/wiki/Show_database_bloat - pak aplikujte VACUUM FULL. Zkontrolujte jestli si zákazník nevypnul autovacuum.

Zdravim Pavle,

z nejakeho duvodu mate jinou zkusenost nez mam ja. Priklad uziti https://moodle.org/mod/forum/discuss.php?d=68558, kdyz pustite napr skript co vam prepise linky v db napr: https://docs.moodle.org/38/en/Search_and_replace_tool , vic dat, vetsi efekt. Postgres vam naboptna celkem hezky, si to klidne vyzkousejte: https://www.percona.com/blog/2018/08/06/basic-understanding-bloat-vacuum-postgresql-mvcc/

https://www.postgresql.org/docs/12/routine-vacuuming.html
https://www.postgresql.org/docs/9.5/routine-vacuuming.html

A chovalo se mi to jak jsem psal, kdyz uz musite ten full vacuum udelat a je malo mista, dobry zacit od mensich tabulek.

@FKoudelka:
Po full vacuum uvidi system vice volneho mista. Kdyz by vam to s volnym mistem nevyslo, tak postgres to ustoji, nic vam nespadne, teda alespon mne nespadnul (uprime jsem cekal ze spadne). To co full vacuum nepretridi , uvolni, budete zpatky kde jste byl "na 3.8GB". Jestli se vam nechce riskovat, tak si treba soupnete nektery tabulky na jinej disk jestli muzete.

Jde o to, co a jak jste napsal. Nedá se říct, že to, co jste napsal, by nebyla pravda, ale minimálně to správně nepostihuje popisovaný problém, a může svádět k nesprávným doměnkám o tom, jak se vlastně VACUUM (potažmo Postgres) chová. "Postgres si nenaalokuje co může" - tahle věta je nesmysl. Jde o to, že datový soubor je halda, data jsou umístěna náhodně, a pokud nějaká data smažete, tak se datový soubor nemůže (bez defragmentace - což je to co dělá VACUUM FULL) zmenšit. S tím nedostatkem místa na disku a znovu opětovným použitím prostoru - dělám s Postgresem 20 let a nevím, že by tam byl podobný mechanismus, resp. Vám garantuji, že tam nid takového není. Postgres si DELETEm označkuje data, ale engine je nezačne přepisovat ihned, protože nějaká jiná transakce je ještě může vidět. Začnou se přepisovat až po  a) potvrzení, že smazaná data už nejsou součástí žádného snapshotu aktivní transakce, b) až se aktualizuje free space mapa (aby engine věděl, že datová stránka obsahuje volné místo). Obojí zajišťuje příkaz VACUUM. Ten může být spuštěn ručně nebo automatem (autovacuum), pokud se přesáhne 220% modifikovaných řádků v tabulce (autovacuum_vacuum_scale_factor - výchozí konfigurace) a ne častěji než 1x za minutu (autovacuum_naptime - výchozí konfigurace). Postgres vůbec nesleduje a neví kolik je místa na disku. Jelikož je datový soubor u Postgresu vždy pro jednu tabulku, tak alokované místo na disku bude do VACUUM FULL už vždy alokované pro tu konkrétní tabulku, které ji může využít. Pro tabulku,která má 1GB je třeba 2GB místa na disku - to může platit pro konkrétní aplikaci, ale jako obecné tvrzení je to nesmyslné.  Postgres překopíruje data ze staré tabulky do nové a nad tou novou vytvoří nové indexy. Potřebujete tolik místa, kolik tabulka obsahuje dat. V případě, že nedojde k redukci, tak v jeden moment máte 2kopie jedné tabulky -- tady minimálně u vaší formulace není jednoznačné jestli se těmi 2GB míní celkové místo na disku nebo volné místo na disku (tak to může vyznít) - je to ještě v závislosti, jak bude nová tabulka vypadat.


Re:PostgreSQL DB na Linuxu roste nad všechny meze
« Odpověď #20 kdy: 07. 05. 2020, 09:42:57 »

Už jsem blízko vakuování, jen dvě otázky:
- má smysl předtím pustit vacuum analyze ?
- tabulka má velikost 14GB, ale místo v / je jen 3.8GB (proto to celé dělám) Dojede to do konce ? pokud ne, vadí to ?
Ještě jednou moc díky

Ne, proč? Pokud má bloat faktor vysoký, tak se to může povést, pokud ne, tak se to nepovede a spadne vám to na nedostatek místa na disku. U toho nedostatku místa na disku je relativně malá šance na poškození databáze, pokud byste tam měl nějakou starší neaktualizovanou verzi PG a zároveň dělal další operace. Pokud má tabulka 14GB a místo na disku je 3.8GB, a nic moc jste tam nepromazal (obsah dat je 12-14GB), tak to moc smysl nedává. Pokud budete mít stejně nějakou odstávku, tak můžete podropovat nějaké indexy, tím si uvolníte prostor na disku, a pak je znovu vytvoříte.

A tak si říkám, jak pak asi zálohujete.
Díky moc. ....tak to moc smysl nedává... co nedává smysl, dělat to vacuum ?
S tím zálohováním, já se nechci moc odkopat, ale mám obraz té mašiny, nic jiného ani nejde. Navíc je to clusterované , tak ji v nejhorším přeinstaluju.
Problém je v tom, že ta tabulka pg_largeobject je 40x větší než zbytek databáze, tak není moc co podstatného smazat.
Musím něco udělat s ním, zkusím asi to vacuum ?

Edit .. kdepak, místo došlo asi po minutě. Zkusím napřed nafouknout LV.
Nevite kam si pri tom vacuum full sype ty docasne soubory, ze bych tam primontoval novy LV fs/ ktery bych pak smazal ? Nafukovat / nechci. A velikost pridaneho mista ... 2x jako tabulka ? Nebo = tabulka ?
« Poslední změna: 07. 05. 2020, 09:47:35 od FKoudelka »

Re:PostgreSQL DB na Linuxu roste nad všechny meze
« Odpověď #21 kdy: 07. 05. 2020, 10:14:33 »

Nevite kam si pri tom vacuum full sype ty docasne soubory, ze bych tam primontoval novy LV fs/ ktery bych pak smazal ? Nafukovat / nechci. A velikost pridaneho mista ... 2x jako tabulka ? Nebo = tabulka ?

pri VACUUM FULL vam budou vznikat datove soubory v podadresari, ktery odpovida databazi - pripadne jeste mohou vzniknout docasne (pracovni soubory) v podadresari datoveho adresare postgresu.

Kdyz si zjistite ve kterem adresari mate db, tak tento adresar muzete presunout na nove LV, a propojit s puvodnim adresarem symlinkem.  Database v postgresu se mapuje do adresare fs. POZOR: PRESUN MUZETE UDELAT POUZE PRI VYPNUTEM POSTGRESU.

Re:PostgreSQL DB na Linuxu roste nad všechny meze
« Odpověď #22 kdy: 07. 05. 2020, 12:17:44 »
Postgres boptna, protoze se chova k prostoru na disku podobne jako Java k pameti, "naalokuje co muze". Resp. kdyz budete mit tabulku, kde mate hodne UPDATE a DELETE tak se zachovavaji transakce i data, postgres si oznaci data jako smazane, ale neuvolni misto na disku pro system. Cili to pak vypada, ze vam vytece z disku, ale on nevytece, v pripade, ze zacne mit kriticky malo mista na disku, 1-2GB tak teprve potom zacne tyhle "sektory" pouzivat znovu, sam pro sebe. Autovacuum vam nepomuze, resp. ted nevim jestli je to od verze 11 nebo 12, ale doporucuju udelat FULL VACUUM, bohuzel to ma exklusivni locky, takze opatrne (u 12 ma prikaz vacuumdb moznost nezamikat tabulky - viz manual). Doporucuju vybrat "top 10" nejvetsich databazi, seradit vzestupne dle velikosti, per databazi pak udelat to same s tabulkama a pustit full vacuum per tabulka. Kdyz zacnete s mensima, uvolni to misto na vacuuming vetsich tabulek. Pocitejte, ze na tabulky 1GB je treba 2GB na disku na full vacuum, proto zacinat od mensich, uvolni misto pro vetsi.

Jak na to vsechno viz dokumentace: https://wiki.postgresql.org/wiki/Disk_Usage

Takto se to samozřejmě nechová. V detailech jste úplně mimo. Nic ve zlém, ale pokud něčemu nerozumím, tak je lepší mlčet. Bohužel internet je zaplněný špatnými dobrými radami.

Bez přihlášení do db žádnou administraci neuděláte. Lze něco detekovat na souborovém systému, ale je to dost pracnější, a navíc hloupost - pokud zákazník si databázi neadministruje sám, a ani nezplnomocní k tomu Vás, tak to jednou musí dopadnout špatně a je to signál, že něco ve vztahu vy, váš zákazník je špatně.

Podívejte se do tabulky pg_stat_activity jestli nenajdete neuzavřenou transakci - state: "idle in transaction". To blokuje VACUUM, a pokud VACCUUM neaktualizuje mapu volného místa v datovém souboru, tak engine neví, že tam volné místo a zvětšuje soubor. Zkontrolujte log - dost často se jedná o aplikační chybu - čistící funkce padají na syntaktických chybách, timeoutech, ..  Podívejte se jestli nějaké tabulky nejsou přefouklé https://wiki.postgresql.org/wiki/Show_database_bloat - pak aplikujte VACUUM FULL. Zkontrolujte jestli si zákazník nevypnul autovacuum.

Zdravim Pavle,

z nejakeho duvodu mate jinou zkusenost nez mam ja. Priklad uziti https://moodle.org/mod/forum/discuss.php?d=68558, kdyz pustite napr skript co vam prepise linky v db napr: https://docs.moodle.org/38/en/Search_and_replace_tool , vic dat, vetsi efekt. Postgres vam naboptna celkem hezky, si to klidne vyzkousejte: https://www.percona.com/blog/2018/08/06/basic-understanding-bloat-vacuum-postgresql-mvcc/

https://www.postgresql.org/docs/12/routine-vacuuming.html
https://www.postgresql.org/docs/9.5/routine-vacuuming.html

A chovalo se mi to jak jsem psal, kdyz uz musite ten full vacuum udelat a je malo mista, dobry zacit od mensich tabulek.

@FKoudelka:
Po full vacuum uvidi system vice volneho mista. Kdyz by vam to s volnym mistem nevyslo, tak postgres to ustoji, nic vam nespadne, teda alespon mne nespadnul (uprime jsem cekal ze spadne). To co full vacuum nepretridi , uvolni, budete zpatky kde jste byl "na 3.8GB". Jestli se vam nechce riskovat, tak si treba soupnete nektery tabulky na jinej disk jestli muzete.

Jde o to, co a jak jste napsal. Nedá se říct, že to, co jste napsal, by nebyla pravda, ale minimálně to správně nepostihuje popisovaný problém, a může svádět k nesprávným doměnkám o tom, jak se vlastně VACUUM (potažmo Postgres) chová. "Postgres si nenaalokuje co může" - tahle věta je nesmysl. Jde o to, že datový soubor je halda, data jsou umístěna náhodně, a pokud nějaká data smažete, tak se datový soubor nemůže (bez defragmentace - což je to co dělá VACUUM FULL) zmenšit. S tím nedostatkem místa na disku a znovu opětovným použitím prostoru - dělám s Postgresem 20 let a nevím, že by tam byl podobný mechanismus, resp. Vám garantuji, že tam nid takového není. Postgres si DELETEm označkuje data, ale engine je nezačne přepisovat ihned, protože nějaká jiná transakce je ještě může vidět. Začnou se přepisovat až po  a) potvrzení, že smazaná data už nejsou součástí žádného snapshotu aktivní transakce, b) až se aktualizuje free space mapa (aby engine věděl, že datová stránka obsahuje volné místo). Obojí zajišťuje příkaz VACUUM. Ten může být spuštěn ručně nebo automatem (autovacuum), pokud se přesáhne 220% modifikovaných řádků v tabulce (autovacuum_vacuum_scale_factor - výchozí konfigurace) a ne častěji než 1x za minutu (autovacuum_naptime - výchozí konfigurace). Postgres vůbec nesleduje a neví kolik je místa na disku. Jelikož je datový soubor u Postgresu vždy pro jednu tabulku, tak alokované místo na disku bude do VACUUM FULL už vždy alokované pro tu konkrétní tabulku, které ji může využít. Pro tabulku,která má 1GB je třeba 2GB místa na disku - to může platit pro konkrétní aplikaci, ale jako obecné tvrzení je to nesmyslné.  Postgres překopíruje data ze staré tabulky do nové a nad tou novou vytvoří nové indexy. Potřebujete tolik místa, kolik tabulka obsahuje dat. V případě, že nedojde k redukci, tak v jeden moment máte 2kopie jedné tabulky -- tady minimálně u vaší formulace není jednoznačné jestli se těmi 2GB míní celkové místo na disku nebo volné místo na disku (tak to může vyznít) - je to ještě v závislosti, jak bude nová tabulka vypadat.

Chapu, vyjadril jsem se dost vagne. Nicmene velikostne, kdyz mate 1GB tabulky, potrebujete 1GB volneho mista na FULL VACUUM. Je to neco co jsem vypozoroval, samozrejme to velmi zalezi na povaze aplikace a dat, takze matematiku za tim nehledejte. To ze postgres nevytece, kdyz delate full vacuum i presto, ze mu dojde misto mi funguje. Bude se to chovat jinak, kdyz budete delat full vacuum tabulky moje_sessions nebo moje_logy atd. Muze se vam stat, kdyz pustite full vacuum na databazi co vam zabira treba 100GB, ze se smrskne na 30GB, fakt zalezi jak dlouho se full vacuum nedelal a kolik se updatlo a smazalo.

Podivejte se na velikosti, indexy atd.: https://www.tutorialdba.com/2018/06/how-to-get-table-size-database-size_26.html
Zjistite si co mate zabloatovano a pustite to treba jenom na par tabulek, co to potrebujou.

Re:PostgreSQL DB na Linuxu roste nad všechny meze
« Odpověď #23 kdy: 07. 05. 2020, 15:31:03 »

+1  :)

Můžu jen dotaz, zda je důvod spouštět ručně FULL VACUUM když mám zapnuté autovacuum?

Těch důvodů může být více - mohou vám neplánovaně narůst tabulky, které pak chcete promazat, a u kterých nechcete riskovat fullscan, který by zbytečně četl 100násobek balastu - aplikační chyby, dos útok, promazání logů, .. autovacuum, připadně samotné vacuum může být z několika důvodů neefektivní - např. dlouho otevřená transakce.

(...)

Děkuji.

Re:PostgreSQL DB na Linuxu roste nad všechny meze
« Odpověď #24 kdy: 08. 05. 2020, 08:50:53 »
Ahoj, vyznáte se v tom někdo ?
Ve struktuře DB na disku a jak se doptat, co se kam píše …
Potřebuju zjistit, proč mi jeden segment na disku bobtná nade všechny meze.
Nevím o této DB nic.
Dík
Ahoj , díky všem. Hodně jsem se naučil. Po  vakuu jsem ušetřil 2GB , což nestačí, tak jsem nafoukl LV a nechám to být.

luvar

  • ***
  • 119
    • Zobrazit profil
    • E-mail
Re:PostgreSQL DB na Linuxu roste nad všechny meze
« Odpověď #25 kdy: 08. 05. 2020, 09:31:52 »
Este ma napadla jedna drobnost. Co vyuziva tu databazu? Ak je tam hibernate ORM na strane aplikacie, tak som pocul o takej lahode, kde sa bloby ukladali rucne (teda za pomoci zle nakonfigurovaneho ORM) do pg_largeobject a odkazovali sa cez idecko ulozene vo varchar stlpci v normalnej tabulke. Nasledne, ked sa povodny odkaz zrusil, tak ORM nespravilo unlink a dany large object zostal donekonecna visiet v "lugte". Nasledne je potrebne nakodit si vlastny "garbage collector" a upratovat takuto DB. Minimalne jednorazovo, ked sa fixne setup ORM-ka.

PS: Pardon za vagnejsi popis, ale tuto info mam z druhej ruky a je to kus davnejsie, co som do hlbky rozumel tejto problematike... Mozno stoji za to precitat https://wiki.postgresql.org/wiki/Largeobject_Enhancement a pripadne sa daco naucit o pouzivani v danom pripade.