Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - geekyfreak

Stran: [1]
1
Dekuji ti Pivotale za reakci. Neresim apriory jak se tomu branit, treba v praci tvuj setup nastavit nemuzu, presto diky za dobre tipy.

Prijde mi proste uhozene, kdyz bych sel do obchodu a pak by sel nekdo za mnou a nejlepe az domu, nebo by uplne stacilo, kdyz by me zamestnanec pozoroval jak nakupuju a delal si zapisky.

Chci tim rict, ze v realu jsou takove veci poburujici a nepripustne, kdezto na internetu jsou zcela bezne a jeste se na tom stavi byznys. Asi plati stare dobre "co oci nevidi, srdce neboli", blby je, kdyz to vidite.


2
Windows a jiné systémy / Re:Android ve firmě
« kdy: 29. 05. 2020, 14:41:45 »
nainstalovat OTP a uz to mi je trochu proti srsti
Jenom tak ze zvědavosti: proč?

OTP je přece neškodná aplikace, která ani nepotřebuje žádná zvláštní práva.

Je to neco co potrebuju k praci a proto preferuji mit veskere aplikace na pracovnim telefonu. Jinak jiste mate pravdu, je to neskodne. I tak si myslim, ze obecne si clovek spis zasvini osobni telefon nez pracovni.

3
Zdravim Koreni a Korenky,

mam osobni dilema a rad bych znal Vas nazor, idealne nasel nejakou smysluplnou odpoved nebo stanovisko. Dam modelove priklady, nechci zabihat do technickych detailu, jde mi predevsim o jistou pravni/osobni/moralni rovinu celeho problemu s "osobnimi daty". Nechci tady psat nejaky elaborat nebo zavery, problem je vsak komplexni. Zajima me co si o tom vy Koreni a Korenky myslite. Prosim neberte vsechno doslova, snazim se vykreslit urcite situace.


Obecna rovina: je hodne javascriptu, ktere jsou pouzivany obrovskou casti internetu, jedna se mi predevsim o Google AdWords, Facebook Thumbs popr. jine predevsim marketingove firmy/skripty. Vi nekdo co vsechno ony skripty vlastne monitoruji/sleduji/paruji? GDPR a podobne smernice a zakony ukazaly i obycejnim smrtelnikum, zac je toho cookie a kolik toho musi odklikat a odsouhlasit, nez "si prectou recept na gulas". Ukazuje to i rozdilnost pravnich systemu, kdy napr. v pravnim systemu USA nelze s podminkami nesouhlasit "decline", ale lze je pouze zrusit "cancel", pravni systemy v evropskych statech vsak umoznuji "nesouhlasit" s podminkami. Toto je casto videt na cookies, ze mate "nutne/minimalni" nebo "doporucene/maximalni".


Firemni rovina: Nastoupil jsem do firmy na pozici "obchodak", dostal jsem firemni laptop se systemem Windows 10, firemni telefon se systemem Android, oboji je centralne spravovane firmou navic firemni auto a vse muzu pouzivat i pro osobni ucely mimo pracovni dobu. Podepsal jsem zamestnaneckou smlouvu, poskytl vypis z trestniho rejstriku a prosel zakladni zdravotni prohlidkou, na moji sexualni orientaci, pocet partneru, uchylky nebo rasu se behem zdravotni prohlidky neptali, jelikoz to je diskriminujici a neeticke/nemoralni. Mam firemni ucty u Microsoft a Google, jelikoz to potrebuji k praci a firma za to plati, pouzivame i spamovou ochranu od nejake firmy Mimecast (nebo podobne), tim padem jsem "odklikal vsechny cookies, policies, agreements atd.", jako zamestnanec, nikoliv jako jedinec/osoba.


Osobni rovina: I presto, ze jsem nikdy doma nevyhledaval "kurzy obchodni komunikace", muj firemni laptop i telefon obcas pripojim doma k WiFi a posleze na firemni VPN, na mem osobnim pocitaci mi zacaly naskakovat reklamy na "kurzy obchodni komunikace". Nemam osobni ucet u zadne z techto velkych firem Google ani Microsoft, jako soukroma osoba se snazim blokovat si v prohlizeci reklamu / (skripty a cookies) tretich stran. Facebook nemam, ale manzelka ho pouziva. Od te doby co tu byl soused minuly tyden a trochu jsme se opili a hledali na jeho telefonu a facebookovem uctu skrze mou WiFi eroticke hracky, manzelce naskakuji reklamy na Facebooku a Amazonu na tyto produkty. Snazim se to tutlat. Vcera mi volal sef a ptal se me, co jsem delal podruhe vcera odpoledne u Motola (jestli jsem vporadku), mel jsem sice pul dne volna, ale uprime, byl jsem na pohovoru u neprime konkurence, myslim, ze sef ma podezreni, bylo to druhe kolo pohovoru. Nevim proc, ale na pohovoru se me ptali jestli jsem nekdy mel problem s alkoholem nebo zdali uzivam marihuanu, firma kde jsem byl dodava techinicka reseni nadnarodnimu obchodnimu retezci kam chodime nakupovat. Manzelka rada organizuje narozeninove party pro kamaradky a plati mou kartou, nejsem si jisty, nemuzu to prokazat, nevim zdali tu novou pracovni nabidku vzit, kdyz se ozvou.


Obchodni rovina: Kamarad provozuje retezec malych obchodu s odevy, ma na dverich upozorneni o kamerovem systemu co ma v obchode a ze detaily smluvnich podminek jsou k nahlednuti na kase, kazdy kdo do obchodu vstoupi automaticky pristupuje na CCTV a obchodni podmiky (vstup je dobrovolny). Ten muj soused mu pomohl nainstalovat skryte kamery do kabinek a na damske zachodky, zaznamy se prodavaji vybranym klientum, sype to vic nez by kdy ten obchody s odevy kdy mohly. Vybira si za pracovnice hezke mlade holky, ne moc chytre, dostavaji firemni mobily a laptopy pro osobni pouziti, maji tam nainstalovany stejny SW jako ja z te firmy kde jeste pracuji, nevedel jsem, ze to umi nahravat skryte hovory a zapinat kameru a mikrofon na dalku, to s tou GPS uz mi doslo.


Robo rovina: Vsadil jsem se se sousedem, ze se den nevydrzi chovat jako prumerna mobilni aplikace. Ze zacatku to byla sranda, ptal se lidi zda mu daji pristup k jejich kontaktum na telefonu, souborum a fotoaparatu. Vetsina si klepala na celo, nekteri byli poboureni az agresivni, i presto, ze vsichni odmitli tak se nektere jal sledovat napr. do obchodu. Zacal si zapisovat co kupuji, jejich navyky a nektere sledoval az k jejich domu. Do par dni ho policie vlekla v poutech jako stalkera, ze je to pry trestne takhle sledovat lidi, vyptavat se jich na osobni udaje a citliva data, kort nezletile. Kdyz jsem se po tydnu prihlasil na svuj soukromy email, ktery je hostovany u mensi spolecnosti, mel jsem tam reklamy na sebeobranu a nabor do bezpecnostnich slozek. Hm, asi mi budou volat policajti kvuli sousedovi.


Nakonec jsem tu novou praci vzal, sveho byvaleho zamestnavatele pozadal o odstraneni osobnich udaju a me historie co o mne nashromazdili firmy co u nich ma firma email a jine sluzby. Sef se mi vysmal, ze mam kontaktovat ony velke firmy. Uz je to rok, myslim, ze muj ticket se dostal konecne od robota k cloveku, ale jisty si nejsem. Zeptal jsem se kdo vsechno dostal me udaje a jake, preci jen, byla tam i ta zdravotni prohlidka (k tomu by ale pristup mit nemeli). V nove praci mam pristup k databazi lidi, kteri si budou brzy kupovat auto, mam jim nabizet nove pojistky a zvyhodneny leasing. Ti lide jeste nevi, ze si to auto chteji koupit, na skoleni nam rekli, ze mame volat jen tem co jsou oznaceni zelene, protoze ti uz zadali relevantni klicova slova do nektere ze spratelenych sluzeb. Tem co jsou oznaceni oranzove volaji kolegove z jineho teamu a nabizeji jim testovaci jizdu v aute od jednoho z nasich partneru. V te same databazi, na sedivem radku, jsem nasel i svou dceru bude si delat pristi rok ridicak, jen nevim, proc tady je sexualni orientace: homosexualni, to bude asi nejaka chyba, vzdyt ma pritele.


Tedka mi prosim reknete, jak je mozne, ze defakto naprosto stejne chovani na internetu je akceptovatelne a shromazdovani dat absolutne v poradku, ale v realu je to povazovano za "stalking" a neco nepripustneho? Je tento problem vubec resitelny? Lze aplikovat soucasne zakony o stalkingu na internetove stranky/skripty? Da se to vubec vymahat? Zabyva se tim nekdo?

PS: Kdyz by si nekdo myslel ze jsem paranoidni a trpym bludy, asi je nas teda vic: https://media.ccc.de/v/33c3-8414-corporate_surveillance_digital_tracking_big_data_privacy/related

4
Windows a jiné systémy / Re:Android ve firmě
« kdy: 27. 05. 2020, 21:39:30 »
Mobily jsou jak pocitace, chovejte se k tomu stejne. Nevim kolik z Vas ve firme pouziva svoje PC/Laptopy ktere nejsou pripojene do AD. Kdyz si vezmete oddeleni jako Personalni, Pravni nebo Ucetni stezi si predstavite scenar s osobnim PC. Na osobni mobil jsem ochoten si maximalne nainstalovat OTP a uz to mi je trochu proti srsti. Kolem a kolem neni zadna zaruka, ze si cas od casu na osobnim mobilu vasi kolegyne zahrajou jeji deti nejakou hru. Dalsi vec je, ze tam mate firemni kontakty popr. i citlive dokumenty. Nejmarkantneji je to videl u uzivatelu jablicek, kteri maji ve zvyku si na firemnim stroji parovat svoje osobni Apple ID. Asi bude jste chvili trvat nez si to vsechny firmy/lidi uvedomi.

5
Software / Re:Údajné zneužití licence SW
« kdy: 27. 05. 2020, 20:49:24 »
Pokud neni jasne odkud logy jsou, tak bych je asi pozadal o vypis logu za posledni 3 roky k one MAC adrese a zbusob jak log obdrzeli, avizoval, ze pocitac chytil virus (nebo s nim bylo neodborne manipulovano) a proto treba ty logy, pozadal je o seznam IP adres jejich licencnich serveru jakozto duleziteho udaje pro analyzu a zkusil spis hrat snimi nez proti nim. Jestli ta firma kde pracujete ma treba 10 licenci na ten soft a 11 byla opomenuta, nebo dokonce nekym cracknuta, nevidel bych to jako zasadni problem. Je totiz prokazatelne, ze je vule a zajem za software platit. Instalaci software nevznikla zadna skoda ani obohaceni (viz cracknu photoshop a zalozim si graficke studio, to neni dobre. Kdyz si budu patlat tutorialy abych se v PS naucil jako chudy student, tam to asi nikoho nepali). Doporucil bych zajit za sefem nebo jednatelem, vysvetlil situaci a predal problem firme at si to vyresi dle uvazeni, nicmene vy byste se od toho mel zcela distancovat, jelikoz to neni vas problem ani vas pocitac. Admin firmy kde pracujete, by mel pocitac reinstalovat, udelat protokol poslat to dane SW firme jako napravu stavu a zduvodnil to jako chybu lidskeho faktoru. Podekoval jim za upozorneni a cekal co oni na to. Kdyz je sjednana naprava, tezko pak budou nekoho za neco zalovat a kdyz, nemyslim si, ze soud by byl ve vas neprospech spis v neprospech vyrobce SW. S tim UOOU nebo GDPR by si totiz asi slusne nabehli, doporucil bych take precist si co maji napsano v licencnich podminkach pri instalaci SW (PS: kliknuti na tlacitko neni pravni zavazek ani v CR ani ve Francii ani jinde).

Kdyz byste meli ve firme tech licenci takto cracknutych vic to je jina, ale kvuli jedne licenci se fakt nikdo soudit nebude.

6
Server / Re:Optimalizacia RDS AWS (PostgreSQL)
« kdy: 27. 05. 2020, 19:59:56 »
U AWS i u Azure plati jedno dulezite pravidlo: "Nikdy nepridavejte/nepouzivejte mensi uloziste nez 1TB" projevi se vam to na IOPS a je to napsane v dokumentaci jako jejich doporuceni. Pokud mate uloziste alespon 1TB tak mate minimalni garantovane IOPS 3000.

Pokud jedete na AWS tak muzete na RDS na kredit jit az na 16 000 IOPS, cili vam to skoci do te extra platby v pripade, ze pustite nejako heavy IO operaci vetsinou napr. reporty (jako bezny provoz).

Pavel ma pravdu s ramkou (caching dotazu), jenze kdyz mate RDS tak nemate moznost "tunit" vsechny hodnoty v postgres.conf , kterymi muzete dosahnout opravdu diametralnich rozdilu ve vykonu, jen nezapomente, ze to je app specific neni zadna stribrna kulka. Pokud chcete maximalni vykon, je lepsi mit vlastni postgres na VMku nez to mit jako managed service (RDS).

Ono AWS RDS PSQL mame tedka na taliri taky, zatim jenom pripravna faze, takze kutame informace a pripravujeme testy. Sam jsem zvedavy jak to dopadne a obecne premyslim, pro koho je vlastne RDS vhodne (krom vyvoje popr. UAT atd.), na produkci asi do urcite velikosti.

Zkousel jste nekdo na AWS RDS pustit PGBadge nebo PoWa idealne v produkci a mate nejaka obecna zajimava cisla?

7
Server / Re:E-maily chodí v gmailu do blacklistu
« kdy: 27. 05. 2020, 18:38:19 »
nektere spam filtery nemaji rady, kdyz v tele emailu mate treba odkaz password.reset.domain.tld/now a posilate to napr. z mail.dmn.ltd

Dokazete si predstavit tu srandu, kdyz dostane marketingovy team napad? :)

Co se gmailu tyce tak ten me zatim vesmes skoli nejvic, od zacatku roku ma radeji v SPF hardfail nez softfail (pokud mate nekdo jinou zkusenost prosim podelte se).

Gmail vysostne nema rad, kdyz mate spatne nastavene hostname a domain name, coz posleze ovlivnuje (a snad to napisu spravne rozdil mezi domain-origin a email-from). Take vysostne nesnasi relay (nebo jsem zatim neprisel na to jak to spravne nastavit aby se mu to libilo).

Pokud muzete, ozkousejte si jejich Postmaster tools https://support.google.com/mail/answer/81126?hl=en

Nezapomente, ze SPF ma limit 10 lookupu a ze ne vsichni umi napsat spravne SPF zaznam obcas jsem narazil na ruzne extra uvozovky nebo preklepy (stane se, popr. nektere webui to proste procpou spatne).

8
Server / Re:Antispam ochranné techniky
« kdy: 27. 05. 2020, 18:21:01 »
DMARC je fajn, ale nekdo se o to musi starat a to neco stoji. Dalsi z veci je, ze neni jednoduche identifikovat co vlastne spam je a neni. Vetsina nastroju analyzuje obsah emailu (po tom co si zkontroluji SPF a DKIM), takze i kdyz mate vsechno vporadku, muze se vam stat, ze urcite emaily budou i tak vyhodnoceny jako spam a to i presto, ze nejsou a dokonce i kdyz adresat email ocekava.

Doporucoval bych se drzet rad od velkych hracu:
https://sendersupport.olc.protection.outlook.com/pm/policies.aspx
https://support.google.com/mail/answer/81126?hl=en

Cas od casu se vam ale stane, ze nekteri "mensi hraci" vetsinou lokalni telekomy implementuji nove spam ochrany a na zacatku to vzdycky drnca no :)


9
Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze
« 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.

10
Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze
« 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.

11
Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze
« kdy: 06. 05. 2020, 01:31:34 »
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

12
Vývoj / Re:Aplikační vs business vrstva
« kdy: 04. 02. 2020, 22:37:12 »
Muzete se zkusit inspirovat tady: http://trailblazer.to/

13
Vývoj / Re:LXD nebo Docker
« kdy: 04. 02. 2020, 22:34:46 »
Me se zda, ze tady trochu narazime na problem mezi developmentem a deploymentem. Kdyz to budete mit na lokale tak si proste namapujete nejakej adresar /projekty/moje/nodejs a /projekty/moje/python primo z hosta na do dockeru. Kdyz si pak budete chtit pripojit debuger tak uz si zacnete nejako pracovat na Dockerfile, ktery kdyz ho napisete rozume bude kompatibilni jak s podmanem, tak ve finale klidne i s Kubernetes, kde si jenom trochu priohnete ten deployment popr. si to ohnete do docker-swarm. Budete mit teda treba nejaky takovy tri kontejnery jeden s nodejs, druhej s pythonem a treti treba s databazi (nekomu staci na vyvoj sqlite, zalezi). Pokud to budete chtit mit vsechno v jednom a zkouset si na tom "rucni testy" asi bych sahnul spis po LXD a choval se k tomu jako k VM. Az si vyresite dependencies a balicky co to bude chtit, rozbit to do dockerfile, buildnete si svuj image, nekam ho musite hodit atd. uz je relativne primocara cesta. Je na vas jestli chcete vyvijet aplikaci nebo resit deployment proces (ve finale asi budete resit oboji). Jak budete delat treba debug/breakpointy, jak chcete resit assety/cdn, kdyz to mate v dockeru? Jasne, muzete to delat na "remote", pak mate zase dva "dockerfile/envy". Kdyz si pak budete otacet ty kontejnery furt dokola musite pak ty mrtvy mazat atd, nakonec si zabordelite ten svuj docker image, bude se vam to buildovat mozna dyl nez byste chtel a misto developmentu budete cekat na buildy.

Rad bych se zeptal mistnich jestli to vidi jinak nebo jestli mi neco unika. Prijde mi proste delat jednodussi delat devel na lokale "po staru" a pak to proste nekam pushnout a tam at se to buildne a testne o tom zadna, ale rad se neco priucim a vyslechnu si jiny nazor.

Stran: [1]