Příspěvky

181

Studium a uplatnění / Re:IT od nuly

« kdy: 12. 08. 2020, 12:29:04 »

Pokud se Vám sejde víc než 8 lidí, tak ty kurzy vycházejí finančně dobře. Nicméně velké množství kurzů (zvláště těch specializovaných) jsou pro 3-4 osoby. Učebny typicky mívají 12 míst, nicméně programátorské kurzy (zvlášť pro začátečníky) se v 12 lidech nedají dělat - a je to pro školitele docela rasovina. Co vím z Gopasu - tak nejlepší byznys jsou kurzy Excelu - je jich dost a jsou plné. Znám Gopas, ICT, a pár dalších společností - a není to špatný byznys, ale ani náhodou to není tak, jak si to malujete.

Presne tak. Tento vzorec 1200e x 20 lidi x 4 tydny = 96000e / 2.5M CZK je scifi . Proste ľudia netušia, o čom rozprávajú. Ja som mal max 8 ľudí na kurze (Python); priemer je možno 3-5 ľudí. Nezriedka mám na školení aj 1-2. Rekvalifikačné kurzy sa robia pár krát
za rok.

Predstava, že si vyhandlujete každý týždeň z úradu práce financie a nájdete 20 ľudí je úplne mimo realitu. Naposledy som mal vo februári na Javu 5 ľudí; študenti, pracujúci a nezamestnaní. Museli sme zložito žonglovať s termínmi, aby každý vedel prísť. Učilo sa to po víkendoch.

Aj keby ste nejakým zázrakom neustále mali financie, vedeli zladiť termíny, a našli tých 20 ľudí, školiteľ to nezvládne. Ideál je 5-6 ľudí. Študent spraví nezriedka 2, 3 chyby, ku každému treba ísť zvlášť, opraviť chyby, vysvetliť. Každý má svoje otázky na veci, ktoré mu nie sú jasné.

Šuster, drž sa svojho kopyta ...

Však ale vy nie ste závislí od jedného kurzu a na jedinom lektorovi. Práve preto tam máte ďalších x zbytočných kurzov (ktoré sa dajú vyučovať aj paralelne), aby ste vykryli situácie, keď nie je záujem napr. o javu alebo python, ale spraví sa kurz napr. na excel. Ja netvrdím, že ste vďaka tomu v ťažkej vate, ale ten biznis vynáša pomerne slušne, za nič a na účet daňového poplatníka. Bez peňazí od štátu by ste totiž museli buď radikálne zmeniť biznis model, znížiť ceny alebo by ste proste zavreli krám. Taká je proste realita.

Dotaci nedostanete na kurz jako takový, ale na odškolený kurz nějakého konkrétního člověka. Takže to rozhodně není za nic. Navíc je s tím 100x víc papírování (a poměrně dost stresu) - kurz je nahlášený dopředu, může tam přijít kontrola (a chodí), všechno musí být formálně správně - školící místnost musí být speciálně označena, osnovy kurzu musí být nahlášené dopředu, seznam osob musí být nahlášený dopředu, atd, atd. To, co živí školící střediska rozhodně nejsou státní instituce, a dotace. Drtivá většina příjmů bude pocházet z korporací - banky, telco, velké fabriky.

Ale fakt si to představujete jak Hurvínek válku - něco jiného jsou přednahraná videoškolení - které vyrobí v Indii, a přehraje te je tisíckrát, a něco jiného je školení s expertem, který má znalosti a navíc cit pro lidi, který umí vysvětlit detaily, dovysvětlit některé díry  ve znalostech, které lidem chybí, který vnímá pozornost lidí, jejich únavu - musíte měnit rytmus, musíte udržet pozornost. Lidi jsou různí, a jsou různí i po profesní stránce. Na školeních se školitelem je výhoda možnosti individuálního přístupu. Samozřejmě, že to není levné, ale za kvalitu se platí. Šunt je laciný nebo zadarmo.

182

Server / Re:Tabulka v MySQL (MariaDB)

« kdy: 04. 08. 2020, 18:28:03 »

i tech nekolik operaci byva v souctu rychlejsi, prave diky dokonalejsi komprimaci vetsinou pracujete s mensim mnozstvim dat.

Vertika neni uplne nejlepsi priklad state of the art sloupcove databaze https://clickhouse.tech/benchmark/dbms/

prezentace, ktera vyvraci to tvrzeni Michaela Stonebrakera https://www.percona.com/sites/default/files/ple19-slides/day1-pm/clickhouse-for-timeseries.pdf

V tom dotazu, který jsem tady uvedl, načítáte jednu datovou stránku a několik málo stránek indexu. Tam Vám komprimace nemůže pomoct. Tu prezentaci jsem si prohlédl, a nikde tam nevidím nic, co by vyvracelo moje předchozí tvrzení. V těch benchmarkách se mluví o time series dotazech, a když jsou uvedeny, tak jsou tam agregace nebo window funkce. Jakmile začnete agregovat, tak je to něco jiného. Tam mají sloupcové databáze neskutečnou výhodu - a to nejen v komprimaci - i kdybyste měl data v paměti, tak agregace nad sloupcemi se dá udělat výrazně rychlejší. Ale pokud tam nemáte agregaci, tak tam není důvod, proč by to mělo být rychlejší - když načítám pár záznamů z indexu.

183

Server / Re:Tabulka v MySQL (MariaDB)

« kdy: 04. 08. 2020, 16:30:33 »

selekt vsech sloupcu podle primarniho klice je rychly. Primarni klice jdou vyselektovat poddotazem nad materializovanym pohledem s tim neprimarnim indexem id. Asi se to lisi v ruznych DB. Neni to uplne primocare, ale podle me stale rychlejsi a uspornejsi na prostor nez v radkovych DB.

To nemůže být z principu - u tohoto typu dotazu prostě sloupcová databáze musí udělat víc operací než řádková databáze - bez ohledu na skutečnost, že sloupcové databáze dost často mají větší velikost stránky. A pokud uděláte materializovaný pohled (projekci ve Vertice), tak jste si defacto vyrobil řádkovou verzi vašich dat, za kterou samozřejmě zaplatíte při aktualizacích (prostor na disku, IO operace). Neexistuje formát (způsob) uložení dat, který by byl efektivní pro hromadné operace i pro operace nad jedním řádkem. Stonebraker (jeden z autorů Postgresu a Cstore (prototyp Vertiky)) dokazoval, že takový formát existovat nemůže.

184

Server / Re:Tabulka v MySQL (MariaDB)

« kdy: 04. 08. 2020, 15:51:27 »

prave mazani po celych dnech partioningem resit lze, ale diky mnohem mensim narokum na misto muzete mazat i po delsich intervalech.

zajimal by me konkretni selekt nad jednou tabulkou, ktery je v libovolne radkove databazi rychlejsi nez napr. v clickhouse, podle me budete mit problem jen vytvorit tak velkou tabulku v radkove databazi na beznem HW, na ktere by se sloupcova databaze zapotila.

SELECT * FROM tab WHERE id = 29292;

a id bude nad oindexovanym sloupcem s mene nez 1% vyskytu, a tabulka bude mit 20-30 sloupcu.

Jakmile byste zacal vic joinovat, a stale by se vyplatil nested loop, tak by se to sloupcovym databazim moc nelibilo. Mezi sloupcovymi databazemi jsou dost velke rozdily - ale pokud bych vzal ty, ktere maji podporu SQL - Vertika, Vectorwise, Monet, .. tak jsou optimalizovane pro OLAP ulohy nad denormalizovanym star schema, snowflake schema modelem. Tam funguji spickove, pro OLTP, a OLTP obvykle dotazy mohou byt pomalejsi - resp. to co je vyhodou pro OLAP je nevyhodou pro OLTP.

185

Server / Re:Tabulka v MySQL (MariaDB)

« kdy: 04. 08. 2020, 06:58:16 »

Pouzit sloupcovou databazi, ty jsou primo stavene pro tento use case. Selekty nad miliardami zaznamu v realnem case nejsou problem. Vetsinou maji mnohem dokonalejsi komprimaci, nahravani byva mnohem rychlejsi, mazani po dnech doporuceny zpusob. Nektere maji i rozhrani z/do mysql.

Jsou různé sloupcové databáze - nicméně mezi jejich silné stránky patří agregace nad větším balíkem dat, ale mohou mít pomalejší vyhledávání - právě díky komprimaci, která zlevňuje sekvenční načítání při hromadném zpracování, a naopak prodražuje přístup k nějakému konkrétnímu řádku. Pokud se nepoužije partitioning tak mazání, update záznamů je naopak velice pomalý - výrazně pomalejší než u řádkových databází. Takže hodně záleží na tom, co tazatel potřebuje a dělá, a také na konkrétní databázi - mezi sloupcovými databázemi jsou hodně velké rozdíly.

pochopil jsem dotaz tak, ze update zaznamu tazatel nepotrebuje, jen odmazavani starych zaznamu.

Jednak tam byl nástin seeku, který sloupcovým databázím nemusí být úplně po chuti (díky větší velikosti bloku), a i delete bývá na sloupcových databázích problém (pokud se neřeší partitioningem). Možná jste nemyslel sloupcové databáze, ale time series databáze - https://en.wikipedia.org/wiki/Time_series_database

186

Server / Re:Tabulka v MySQL (MariaDB)

« kdy: 03. 08. 2020, 21:38:00 »

Pouzit sloupcovou databazi, ty jsou primo stavene pro tento use case. Selekty nad miliardami zaznamu v realnem case nejsou problem. Vetsinou maji mnohem dokonalejsi komprimaci, nahravani byva mnohem rychlejsi, mazani po dnech doporuceny zpusob. Nektere maji i rozhrani z/do mysql.

Jsou různé sloupcové databáze - nicméně mezi jejich silné stránky patří agregace nad větším balíkem dat, ale mohou mít pomalejší vyhledávání - právě díky komprimaci, která zlevňuje sekvenční načítání při hromadném zpracování, a naopak prodražuje přístup k nějakému konkrétnímu řádku. Pokud se nepoužije partitioning tak mazání, update záznamů je naopak velice pomalý - výrazně pomalejší než u řádkových databází. Takže hodně záleží na tom, co tazatel potřebuje a dělá, a také na konkrétní databázi - mezi sloupcovými databázemi jsou hodně velké rozdíly.

187

Server / Re:Tabulka v MySQL (MariaDB)

« kdy: 03. 08. 2020, 17:20:10 »

Ahoj, kratce a strucne. Popis situace :
Tabulka MyISAM v MariaDB, jednoducha struktura, asi 10 sloupcu, zadne relace, nic jen ta tabulka.
Pocet zaznamu zhruba 9 milionu, velikost tabulky 12.5 GiB.
Do tabulky se insertuje prubezne v case, zhruba nekolik stovek tisic denne, v case plynule rozprostreno.
Obcas se delaji Selecty, hledani podle jednoho string sloupce, je zaindexovan.
Jednou denne probiha vymaz starych zaznamu, zaznamy starsi nez x dnu jsou deletovany.
Tabulka slouzi vlastne jako cache jistych dat, sbiranych v realnem case.
Funguje to v pohode, nicmene vymazem se to samozrejme fragmentuje, atd.
Zajimaji me nejake zajimave napady, jako by to kdo resil :-) Vic hlav vice vi....

Přesně na tohle je super partitioning

https://mariadb.com/kb/en/partitioning-overview/

188

Studium a uplatnění / Re:IT od nuly

« kdy: 23. 07. 2020, 14:14:20 »

9 dňový kurz za 1200 eur dobrá ryža na štátnych peniazoch, keď ešte aj rok štúdia na vysokej škole stojí menej €€€ a študent tam má Javu 1 - 2 celé semestre + kopu iných zaujímavých kurzov.

Je to asi zbytočné vysvetľovať niekomu, kto sa evidentne nevyzná. 1200€ je zhruba cena 5 dňového kurzu Javy v Gopase, čo je
najväčšie školiace stredisko v Čechách a na Slovensku. Z ceny kurzu treba zaplatiť dane, réžiu, administratívu, manažment a lektora.
Nik tam nejazdí na drahých autách, ani nemajú vily. Väčšina z nás to robí preto, že nás to bavi, nie pre peniaze.

1200e x 20 lidi x 4 tydny = 96000e / 2.5M CZK mesicne. I kdyby lektor mel 250K CZK a pronajem stal 250K CZK, tak je to porad 2M CZK cista ryza... a tohle je jenom jeden kurz.

Pokud se Vám sejde víc než 8 lidí, tak ty kurzy vycházejí finančně dobře. Nicméně velké množství kurzů (zvláště těch specializovaných) jsou pro 3-4 osoby. Učebny typicky mívají 12 míst, nicméně programátorské kurzy (zvlášť pro začátečníky) se v 12 lidech nedají dělat - a je to pro školitele docela rasovina. Co vím z Gopasu - tak nejlepší byznys jsou kurzy Excelu - je jich dost a jsou plné. Znám Gopas, ICT, a pár dalších společností - a není to špatný byznys, ale ani náhodou to není tak, jak si to malujete.

189

Server / Re:pg_start_backup v Posgtresu

« kdy: 29. 05. 2020, 07:21:21 »

Ahoj,
rad bych se zdejsich zkusenejsich zeptal na zkusenosti s pouzivanim online backupu v Postgresu.
Resim situaci, kdy pro base zalohu db v archivnim rezimu vyuzivam pg_start_backup/pg_end_backup.
Domnival jsem se, ze po spusteni pg_start_backup jiz nedochazi k zapisu do datovych souboru a vsechno jde do wal segmentu. Nicmene narazil jsem na situaci, kdy zalohovaci sw vyhodil chybovou hlasku s tim, ze behem zalohy doslo ke zmene velikosti nektereho souboru.
Pri hledani o jaky soubor jde jsem pak zjistil, ze jde o datovy soubor jedne tabulky.
V dokumentaci jsem dohledal, ze jde o normalni situaci ... nicmene pro me tim pada me puvodni vysvetleni toho, jak ta online zaloha funguje ...
Setkal jste se tu s tim nekdo, pripadne umite vysvetlit, proc to tak je?
Diky za pripadnou ochotu!

Vaše doměnka je špatná. Implementace archivace v Postgresu neblokuje zápisy do datových souborů jako jiné databáze. pg_start_backup synchronizuje RAM a IO checkpointem a začne zápis do nového segmentu transakčního logu. Vy můžete zahájit fullbackup, který co se týče datovych souborů nemusí být konzistentní (protože stále dochází k zápisům). Nicméně při obnově tohoto pravděpodobně nekonzistentního backupu (pokud je databáze pod zátěží) postgres přehraje všechny transakční logy, které byly zapsány mezi pg_start_backup a pg_stop_backup. Tím zajistí konzistenci, protože vše, co se teoreticky nezkopírovalo se "přepíše" z transakčních logů. Vše je popsáno v dokumentaci https://www.postgresql.org/docs/current/continuous-archiving.html

190

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« 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.

191

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« 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.

192

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« 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.

193

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« 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.

194

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« kdy: 06. 05. 2020, 16:05:37 »

+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. VACUUM FULL jako side efekt je ochranou proti přetečení transakčních ID (což by mi autovacuum zajistilo taky, ale to může VACUUM FREEZE pustit v nevhodnou dobu), a sekundární side efekt je reindexace. VACUUM FULL vám může posloužit i jako kontrola čitelnosti integrity databáze.

VACUUM FULL určitě není rutinní záležitost - ale jednou do roka neuškodí. A když mám nějaké malé databáze, na kterých VACUUM FULL běží do minuty, a mohu si dovolit risk exkluzivního zámku, tak pokud pustíte VACUUM FULL, a následně VACUUM ANALYZE, tak jste dostal databázi do výchozího téměř ideálního stavu a není tam co dál moc administrovat, řešit. Jednou, 2x do roka jednoduchá a pro drtivou většinu případů dostatečná údržba databáze.

195

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« kdy: 06. 05. 2020, 06:35:59 »

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.