Příspěvky

31

Studium a uplatnění / Re:ChatGPT a AI pro vývojáře

« kdy: 15. 02. 2023, 06:20:24 »

Já mám pocit, že se tenhle stochaisticný přístup k návrhům začne brzy dostávat/asi už dostává i do HW.
Když dáte marketingu vybrat zda chce, aby procesor spočítal se 100% jistotou že 1+1=2 za 10 ms nebo do s 99,99999% pravděpodobností odhadl za 1 ms, co si asi vybere? 10x rychlejší procesor.
I kvantové počítače jdou tímhle směrem.

Jestli správně počítám, tak ta chyba se s pravděpodobností 100% objeví každé 3 hodiny. Když budete louskat hesla, nebo komprimovat video, tak se asi s tím dá žít, ale pro jakékoliv úlohy, kde potřebujete dostupnost, důvěryhodnost, tak si myslím, že je dost těžko použitelné.

Mimochodem v Československu, právě vzhledem k mizerné kvalitě hw, se navrhovaly podobné počítače (odolné k chybám).

32

Studium a uplatnění / Re:ChatGPT a AI pro vývojáře

« kdy: 14. 02. 2023, 13:03:46 »

Jirsák +1.

Já bych to popsal tak, že většinové IT pomalu opouští rigidní matematické procesy, ve kterých se zrodilo, a přesouvá se do měkčích procesů známých třeba z biologie. Místo zdola nahoru se jde shora dolů. Je to lepší, nebo horší? Asi záleží případ od případu, ale určitě to dovoluje mít složitější celky, které z povahy věci prostě musí být tolerantní k částečnému selhání něčeho uvnitř.

Tenhle přístup mne, co by inženýra dost děsí. Trochu mi to zavání rezignací. Nevíme jestli je to evoluce nebo rakovina. Prostě to neumíme nadesignovat, uřídit, tak to necháme jak se to vyvrbí. Evoluce funguje, ale v řádech miliónů let se spoustou slepých uliček a masových vymírání. Jsem stavební inženýr, trochu něco tuším o strojařině, a tam jen idea systémů, které nejsou 100% deterministické je nepřijatelná fantasmagorie.

Jsem 100% pro fault tolerant systémy, nicméně ty systémy stále musí být deterministické. Jinak se inženýrská práce mění v alchymii.

33

Studium a uplatnění / Re:ChatGPT a AI pro vývojáře

« kdy: 14. 02. 2023, 09:09:26 »

Aktuálně to nevypadá, že by programátorů byl dostatek. Naopak, tím, že je napsaného a dostupného čím dál víc kódu, je čím dál víc možností, co se s jeho pomocí dá docela snadno vyřešit. Akorát je potřeba lidí, kteří z těch kostiček ty další a další věci postaví. Myslím, že AI způsobí, že programátoři budou podstatně efektivnější, ale nezpůsobí to, že by přišli o práci. A pořád budou potřeba ti, kteří vymyslí architekturu nebo nějakouo novou optimalizaci nebo nový algoritmus. Ale většině práce už dávno je jenom skládání různých kostiček dohromady, kde se převážně píše stále dokola podobný kód. Který zvládne AI napsat mnohem rychleji. Jako když dnes máte šablony či makra na napsání kostry cyklu nebo getterů a setterů, akorát AI dokáže napsat větší části kódu a lépe je zasadí do kontextu.

To je právě projev krize IT. Místo nástrojů, které by programátorům umožňovaly psát optimální kód, tak tu máme nástroje, které umožňují psát programátorům kód efektivně. Místo toho, aby se řešila komplexita kódu, konzistence API, tak máme nástroje, které umožní produkovat kód v prostředí s nekonzistentním, duplicitním API, nejasnými závislostmi. Za komplexitu se ale vždy platí, vyšší křehkostí (opak robustnosti), vyššími náklady, větší specializací, menší obecností.

34

Studium a uplatnění / Re:ChatGPT a AI

« kdy: 14. 02. 2023, 08:58:52 »

Vývoj na zelené louce znamená nové proškolení zaměstnanců, nové chyby, další náklady s nasazením, úpravami, neznámé neočekávané náklady a více práce, atd atd. Snadno vyměníte blogovací platformu. Relativně snadno vyměníte platformu pro eshop.  Výměna interních velkých systémů - co tak slýchávám po korporátech, tak mám pocit, že téměř nejde, a může to být několik let trvající nákladný proces s nejistým výsledkem.

Přidám zkušenost ze svého okolí. Nejmenovaná zdravotní pojišťovna přešla loni na nový systém. Souhrou blbých okolností nebyli schopni přes 4 měsíce proplatit výkony praktickému lékaři... Prostě kombinací více věcí to ten nový systém dostalo do stavu, kdy takhle dlouho nešlo nic dělat.

Vůbec mne to nepřekvapuje. Čekám to horší a horší.

35

Studium a uplatnění / Re:ChatGPT a AI

« kdy: 14. 02. 2023, 08:20:56 »

takže výsledkem bude víc kódu horší kvality, což znamená víc práce pro údržbu. Možná se sníží cena za vývoj, ale zvýší se cena za údržbu.

To zni strasidelne.
Nicmene proc bych platil za udrzbu kdyz je greenfield vyvoj levnej? Uz dneska chce malokdo udrzbu vubec delat a platit.

Jsou různě důležité provozy, a různé aplikace. U těch kritických se také nikomu nechce platit za údržbu, ale platí se, a to i dost velké částky. A je velký rozdíl jestli jenom platíte - a jinak o tom software neslyšíte, nebo platíte a ještě máte každý měsíc nějaký provozní problém, který vyžaduje servisní zásah. Ono se to projeví na nákladech nebo i ochotě zaměstnanců neměnit práci, jestli pohotovost znamená, že jsem na telefonu a nesmím chlastat ale více méně téměř nikdy k servisnímu zásahu nedojde, nebo jestli k servisním zásahům dochází téměř každou noc.

Vývoj na zelené louce znamená nové proškolení zaměstnanců, nové chyby, další náklady s nasazením, úpravami, neznámé neočekávané náklady a více práce, atd atd. Snadno vyměníte blogovací platformu. Relativně snadno vyměníte platformu pro eshop.  Výměna interních velkých systémů - co tak slýchávám po korporátech, tak mám pocit, že téměř nejde, a může to být několik let trvající nákladný proces s nejistým výsledkem.

36

Studium a uplatnění / Re:ChatGPT a AI

« kdy: 14. 02. 2023, 07:46:01 »

Ještě jsem tu na toto téma nenarazil, tak ho s dovolením zkusím otevřít. Předpokládám, že téměř každý si za poslední rok vyzkoušel ChatGPT nebo třeba Github Copilot. Obojí ve mně poprvé vyvolalo úžas, jak je to dobré. Po pár použitích člověk zjistí, že to má ještě spoustu much, ale pořád je to použitelné. Například, jsem dělal se source generátory v .NETu, o kterých toho zas až tolik na internetu psáno nebylo a ChatGPT mi sice vygeneroval nezkompilovatelný kód, ale rozhodně navedl správným směrem.
Co vidíte ve své křišťálové kouli Vy? Začne poptávka po programátorech klesat? Nebo začneme psát daleko méně kódu a přesuneme se do nějakých AI-powered low code řešení?

Tipoval bych, že to bude mít podobný efekt jako stack-overflow. Dalším lidem to umožní napsat nějaký kód s minimem znalostí. Následně ten kód musí někdo verifikovat, a při větším průseru opravit nebo přepsat, což už musí udělat někdo "postižený" znalostmi. Rozhodně je to nástroj, který zpřístupní programování dalším lidem. Na druhou stranu to není posun k snížení komplexity (je to jen sofistikovanější verze vyhledávače), takže výsledkem bude víc kódu horší kvality, což znamená víc práce pro údržbu. Možná se sníží cena za vývoj, ale zvýší se cena za údržbu.

Pokud začne klesat poptávka po programátorech, tak bych za tím neviděl UI, ale přirozený tlak na konsolidaci IT a saturaci trhu.

37

Server / Re:Formát čísla v PostgreSQL

« kdy: 04. 02. 2023, 05:40:41 »

Postgresový numeric je uložené číslo (hodně zjednodušeně posloupnost číslic) + počet desetiných míst.
Pokud se potřebujete zbavit koncových null, tj redukovat počet desetinných míst bez změny hodnoty, použijte funkci trim_scale

Vdaka. Jednoducho ma to prekvapilo a citil som potrebu sa snazit pochopit, co to pozorujem.
Slovami dodavatela, ktoreho som dokopal k zmene typu stlpca som "riesil uplnu blbost" .

V tom nejste sám :-). Čím déle člověk dělá s jedním konkrétním softwarem, a pak přejde na něco jiného, tak skoro zákonitě naráží, na to, že ten druhý software se nechová tak jak by čekal. Postgres není 100% kompatibilní s Oraclem. Není to záměr, ale výsledek vývoje, v některých případech dost odlišné filozofii, v některých případech i odlišné architektuře a i jiným chybám v designu, které už nejde z důvodu zpětné kompatibility opravit.

Vlastnosti SQL, vlastnosti datových typů se v Postgresu definovaly hlavně koncem 90 let, tedy 20 let po Oracle, kdy už byly i jiné možnosti dané výrazně větším výkonem a větší RAMkou. Nikoho také v té době nenapadlo, že by někdo migroval z Oracle do Postgresu.

38

Server / Re:Formát čísla v PostgreSQL

« kdy: 02. 02. 2023, 19:07:41 »

Pekne to je vidno na tom, ze NUMERIC(4,2) vam v Oracle zobrazi 1.1 a Postgresql 1.10.

Postgresový numeric je uložené číslo (hodně zjednodušeně posloupnost číslic) + počet desetiných míst. Ten počet desetiných míst může být vynucený definicí nebo pokud není definován, tak vychází ze vstupu a zachovává se. Na rozdíl od Oracle Postgres pokud není formát vynucený, tak Postgres uloží číslo tak, aby jeho zobrazení bylo stejné jako jeho vstup. 1.1 a 1.10 jsou tatáž čísla. Jen se liší počtem desetinných míst. Je potřeba si uvědomit, že v případě typu numeric - numeric bez specifikace neznamená numeric(max, 0). Je to prostě numeric bez specifikace počtu desetinných míst. Neznamená to celé číslo.

Pokud se potřebujete zbavit koncových null, tj redukovat počet desetinných míst bez změny hodnoty, použijte funkci trim_scale

(2023-02-02 19:05:42) postgres=# select trim_scale(10.20000::numeric), 10.20000::numeric;
┌────────────┬──────────┐
│ trim_scale │ numeric  │
╞════════════╪══════════╡
│       10.2 │ 10.20000 │
└────────────┴──────────┘
(1 row)

39

Server / Re:Automatický restart PostgreSQL

« kdy: 30. 01. 2023, 19:10:28 »

Ale zpatky k otazce - zejmena p. Stehule prosim - mate nejake informace ohledne dopadu automatickeho restartu vzhledem k tomu, co je za komentar v dane systemd service?

Ten komentář se vztahuje patrně k nastavení postgresu (postgresql.conf) restart_after_crash, které na redhatu je v defaultu on. Pokud zrovna není zabitý (nebo havarovaný) postmaster, tak se postgres restartne po havárii libovolného procesu. Pokud je zabitý rodičovský proces, tak tato volba už nezafunguje (a OOM killer může zabít hlavní proces).

Nastavil jsem Restart=on-failure - a systemctl stop funguje naprosto bez problemů. Po killiu postmastera mi systemd nastartoval postmastera automaticky. Myslím si, že ten komentář se může vztahovat na management postavený nad příkazem pg_ctl, což je i debianní skript pg_ctlcluster. S tím že je on-failure tak mi přišlo, že i příkaz pg_ctl stop se chová korektně a podle očekávání. Ale jakmile jsem začal používat pg_ctl tak se mi pid utrhl a i když Postgres běžel, tak o tom systemd nevěděl (jelikož měl jiný pid).

Nejsem expert na debian a jeho skripty pro Postgres jsem se nikdy nenaučil, takže mi může něco uniknout. Teď jsem zkoušel chování na RH, a přišlo mi, že se to chová logicky. Ale aby v tom nebyl zmatek, tak by člověk neměl kombinovat pro nastartování, restart a zastavení Postgresu systemd a pg_ctl (což teoreticky je možné). V systemd pak nebude sedět status.

40

Server / Re:Automatický restart PostgreSQL

« kdy: 27. 01. 2023, 19:50:40 »

neviem co chce checksys... minimalne tu swap bych dal na = RAM.

swap by měl být vždy.

41

Server / Re:Automatický restart PostgreSQL

« kdy: 27. 01. 2023, 18:22:53 »

este by sa mozno oplatilo nastavit naky rozumny statement_timeout. samozrejme po dohovore s developermy.
ono to nejaky cas trva kym sa RAM zaplni ale ked tam na tom experimentuju tak sa to moze stat.

Paměť se i na dnešních velkých serverech zaplnit během několika málo desítek sec. 4GB server tak cca za 3sec. Timeouty nejsou ochranou vůči vyčerpání paměti, ale jsou ochranou proti nechtěnému nadužívání CPU a držení zámků neoptimálně prováděných dotazů.

tak to kazdopadne. ale...
1. potom sa ale nakopne swap a tam uz to tak rychle neni.
2. timouty su ochranou pred long running queries a to okrem CPU vytazuje aj RAM.
3. tazatel riesi development server a nejake sepalenie systemu kvoli nerealistickym queries je viac ako pravdepodobnost.

preto trvam na tom ze ten timeout by predsa len bolo dobre nastavit.

Timeoutem nic nezkazíte - otázkou je kolik? A otázkou je kolik času strávit s laděním konfigurace serveru, kde není hw odpovídající produkci, a kde asi není ani moc dat. V GoodData měl každý vývojář vlastní server ve vlastní virtuální mašině a staral se o něj (rozbíjel si ho) sám. V dev prostředí, pokud nemáte k dispozici slušné železo, a běží to na chcípačích, tak má smysl řešit jedině stabilitu provozu, zvlášť ve sdíleném prostředí. V dev prostředí každý může být super user, a dlouhoběžící dotazy může jednoduše zabít.

Performance testy jsou neskutečně důležité, a dost se podceňují, ale nemá cenu si hrát na bechmarking na poddimenzovaném hw a neadekvátně velkých testovacích datech.

42

Server / Re:Automatický restart PostgreSQL

« kdy: 27. 01. 2023, 08:51:35 »

este by sa mozno oplatilo nastavit naky rozumny statement_timeout. samozrejme po dohovore s developermy.
ono to nejaky cas trva kym sa RAM zaplni ale ked tam na tom experimentuju tak sa to moze stat.

Paměť se i na dnešních velkých serverech zaplnit během několika málo desítek sec. 4GB server tak cca za 3sec. Timeouty nejsou ochranou vůči vyčerpání paměti, ale jsou ochranou proti nechtěnému nadužívání CPU a držení zámků neoptimálně prováděných dotazů.

43

Server / Re:Automatický restart PostgreSQL

« kdy: 20. 01. 2023, 12:02:17 »

Tak byla to zrovna postgresql 13.

Konfigurace pameti je 4GB ram, 2.5GB swap.
Zmeny v postgresql.conf vs defaulut:

Kód: [Vybrat]

effective_cache_size = 2751MB
effective_io_concurrency = 200
random_page_cost = 1.1
shared_buffers = 982MB
work_mem = 12MB

Kód: [Vybrat]

Out of memory: Killed process 543258 (postgres) total-vm:8059544kB, anon-rss:2024860kB, file-rss:0kB, shmem-rss:0kB, UID:111 pgtables:13904kB oom_score_adj:0

Kód: [Vybrat]

Jan 19 14:13:40  kernel: [1139300.451096] Free swap  = 0kB
Jan 19 14:13:40  kernel: [1139300.451097] Total swap = 2670588kB
Jan 19 14:13:40  kernel: [1139300.451098] 1048441 pages RAM
Jan 19 14:13:40  kernel: [1139300.451098] 0 pages HighMem/MovableOnly
Jan 19 14:13:40  kernel: [1139300.451099] 41986 pages reserved
Jan 19 14:13:40  kernel: [1139300.451100] 0 pages hwpoisoned

Ja myslim, ze proste vyvojarum dosla pamet na jejich sql dotazy

4GB server se uz moc nevidi :-). Jeste je otazka, jak mate nastavene max_connection?

Postgres - stejně jako všechny ostatní databáze optimalizují dotaz i vůči dostupné paměti, a pokud by potřeboval víc paměti, tak se jede přes dočasné soubory. Takže za normálních okolností by se měl vejít jeden dotaz do nějakého nnasobku work_mem, což je u vás 12 MB. Postgres má hiearchickou správu paměti - dost paměti se uvolňuje při po dopočtu řádku, další po dopočtu dotazu a nakonec prakticky vše se uvolní po dokončení transakce. Je otázkou jak máte velkou db, a co tam vyvádíte.

44

Server / Re:Automatický restart PostgreSQL

« kdy: 20. 01. 2023, 10:36:10 »

Zrovna databáze je aplikace, která by neměla padat nikdy. Pokud dojde k pádu databáze, znamená to, že je někde nějaký problém – chyba paměti, disku apod. Je dost pravděpodobné, že máte poškozená data, když nad tím databázi necháte znovu nastartovat, nejspíš dojde k tomu, že se bude poškození dat šířit dál.

K tomu poškození db by mělo dojít jen výjimečně, pokud dojde k poškození filesystému. Ale je fakt, že pokud admin musí explicitně nahodit db, tak ho to spíš dokope udělat nějakou investigaci. Na druhou stranu drtivá většina adminů tu investigaci stejně neudělá.

Diky, doufal jsem v komentar od Vas.

V tomto pripade zauradoval OOM killer. Asi do te automatiky pujdeme, poskozeni dat muze vzniknout i nenapadneji, nez restartem atd, od toho mame pak zalohy.

Dotaz na tu datovou integritu - netusite, jaky to ma vykonnostni dopad?

Co myslíte datovou integritu? Kontrolní součty na datových stránkách? Na dnešních CPU by to nemělo mít viditelný dopad.

Jinak to, že byl Postgres zabit OOM killerem může znamenat špatnou konfiguraci Postgresu nebo chybějící swap. Nemělo by se to také stávat. U starších verzí byl občas problémový hash aggregate, ale to by od 13 mělo být pořešené.

45

Server / Re:Automatický restart PostgreSQL

« kdy: 19. 01. 2023, 18:44:38 »

Zrovna databáze je aplikace, která by neměla padat nikdy. Pokud dojde k pádu databáze, znamená to, že je někde nějaký problém – chyba paměti, disku apod. Je dost pravděpodobné, že máte poškozená data, když nad tím databázi necháte znovu nastartovat, nejspíš dojde k tomu, že se bude poškození dat šířit dál.

K tomu poškození db by mělo dojít jen výjimečně, pokud dojde k poškození filesystému. Ale je fakt, že pokud admin musí explicitně nahodit db, tak ho to spíš dokope udělat nějakou investigaci. Na druhou stranu drtivá většina adminů tu investigaci stejně neudělá.