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 - Pavel Stěhule

Stran: 1 2 3 [4] 5 6 ... 31
46
Server / Re:Automatický restart PostgreSQL
« kdy: 19. 01. 2023, 18:39:26 »
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.

Nemám pocit, že by někdo reportoval problémy s automatickým restartem, a přiznám se, že mám pocit, že se to v případě Postgresu ani nijak extra neřeší. Většina restartů je způsobená neodborným zásahem admina (použítím killu) nebo OOM killerem. Může se stát, že se hitne chyba Postgresu (ale to není časté). Ve zmíněných případech by k poškození db dojít nemělo a neslyšel jsem, že by docházelo. Osobně bych se restartu Postgresu nebál, protože co udělá normální admin - zkusí Postgres nastartovat co nejdřív a případnou investigaci nechá na později - nebo bude řešit, pokud Postgres nenastartuje. Dost firem používá dohledové systémy nebo různé stupně HA, které při nedostupnosti Postgresu samy zkusí Postgres nastartovat nebo restartovat. Nevidím moc rozdíl jestli restart udělá systém, HA nebo admin.

Samozřejmě, že po jakémkoliv restartu chce udělat investigaci proč - nemělo by k tomu docházet - a pokud by k tomu docházelo z hw problémů, tak je to průser. Mám pocit, že jsem to za posledních 10 let nezažil. Nějaké nechtěné restarty mohou způsobit chyby v extenzích nebo špatně použité extenze (untrasted languages), ale moc se to neděje. Často používané extenze už jsou poměrně odladěné a prověřené. Dneska se doporučuje zapnout kontrolní součty na datových stránkách (pozor by default jsou vypnuté), a pokud by docházelo k nechtěným restartům, tak je něco špatně a chce to investigovat. K poškození databáze by dojít nemělo, pokud nedojde k poškození filesystému.

U jednoho zákazníka jsem kdysi řešil restarty Postgresu cca 3x za den - zákazník provozoval aplikaci několik měsíců bez poškození databaze, ale s nepříjemnými důsledky na dostupnost. Dodavatel jen doporučil výkonnější hw, což byla samozřejmě blbost. Pak se ukázalo, že dost nešťastně používají untrusted pl perl, a že si nevědomky permanentně rozbíjejí obsluhu jednoho signálu. Dalo se to fixnout během několika minut, když člověk věděl, že jak to funguje a jaké jsou tam souvislosti.

47
Vývoj / Re:Je Zig jazyk buducnosti?
« kdy: 29. 12. 2022, 05:24:35 »
Dřív to asi platilo, ale z těch "rozšířených" to dneska neumí skoro žádnej: Java ne (potřebuje JVM), C# asi ne (moc ho neznám, ale taky asi potřebuje nějakou VM), Python, JS, Ruby, PHP ne (všechno skriptovaný bazmeky)... vlastně mě žádnej garbage-collected jazyk kromě Go nenapadá.
C# je opajcnutá Java, v 90-tych rokoch boli okolo toho aj súdy, vtedy M$ robili dokonca aj J#, ale to bol príliš okatý opajc, tak J# nakoniec zarezali.
 Samozrejme vývoj ide ďalej oboma smermi a dnes sa jazyky už tak nepodobajú, ale stále má C# kompiláciu do byte-kódu ako Java a aj jeho interpretáciu (ako Java).

Interně je .NET a JVM dost jine - https://stackoverflow.com/a/1625090/406691 - Teď už to nemohu najít, ale mám pocit, že alespoň z části .NET navazoval na výzkum z ETH Curych, kde ještě před Javou řešili efektivitu přenositelných aplikací. C# se pak Javě  podobá (i když mně osobně to nepřijde), ale je to jazyk z 90 let, kdy všechno muselo mít objekty a všechno muselo mít garbage collector. Jinak koncept interpretace byte code, a jeho interpretace je ze 70 let - to není vynález ani Sunu a ani Microsoftu (a Microsoft měl relativně rychlou a efektivní implementaci ve Visual Basicu). .NET původně cílil na mswin desktop a síťování se řešilo víc skrze RO. Java se víc motala kolem internetu. Microsoft u .NET skoro vůbec neřešili nezávislost na platformě. .NET byl původně čistě MS záležitost. Naopak Java byla od začátku multiplatformní.

48
Zdravím všechny,

máte někdo zkušenosti s KB a jejich inkubátorem? Mají o mě zájem, moc se mi tam nechce (HPP, korporát, peníze), zase si ale říkám, že by nemuselo být špatné mít zkušenost z bankovního sektoru, techstack mají docela moderní, asi jak chtějí tu "novou digitální banku".

Nástup je až od 1.2. Dle Vašeho názoru, mám do toho jít, nebo se ještě něco snažit najít na OSVČ? Nutno podotknout, že by to byl můj první job jako porogramátor (nikoli jako ajťák).

Díky za odpověď

Nedávno jsem tam školil - a ti lidé tam byli docela v pohodě. Je to korporát, a je to banka, to je jasné. Na druhou stranu školil jsem v republice i v jiných korporátech, a měl z toho horší pocit. Kdekoliv platí, že hodně záleží pod jakého šéfa se dostanete.

49
Server / Re:OOM-Killer zabíjí MariaDB
« kdy: 10. 12. 2022, 05:13:14 »
Nejsem expert na MariaDB, a vlastně ani na OOM killer. Nicméně obecná rada pro Postgres je mít vždy aktivovaný swap a hlídat si, že se nepoužívá. Bez swapu je limit pro OOM killer poměrně nízko, a dost paměti nebude využitá. Databáze na trochu větších datech používají hodně paměti - cache, sort, hash tables, a je to to co chcete.

50
Server / Re:Snapshot aktuálního stavu v MariaDB
« kdy: 27. 11. 2022, 07:03:48 »
na lokálnom stroji mám
...
Kópia /var/lib/mysql?
Toto jsem používal a funguje to celkem dobře. Je to krapet "ošklivé", hrabat marii takhle do střev, ale funkční.

Pokud se to udělá při vypnuté databázi, tak by to mělo být úplně v pohodě (pro libovolnou db). Aby se zabránilo kopírování všech dat, lze použít rsync. Jen je potřeba si ověřit, že se kopíruje celá db. V Postgresu se mohou db objekty uložit i do jiných než default adresářů skrze tablespace

51
Server / Re:Optimalizace MariaDB na čtení nebo zápis
« kdy: 07. 11. 2022, 05:44:11 »
Ked si vezmem "CAP theorem" a chcem mat jednu MariaDB instanciu optimalizovanu na konzistenciu(zapis) a druhu instanciu zase optimalizovanu na dostupnost(citanie), su pre nu nejake specificke nastavenia ktore sa oplati riesit, ci ani nie?

Pokud bys chtěl aplikovat CAP theorem na MySQL, tak jedině na nějaký replikovaný cluster. MySQL je klasická transakční relační databáze. CAP theorem má smysl na distribuované databáze, což instance MySQL není.

52
Vývoj / Re:Jaký jazyk bych se měl učit?
« kdy: 31. 10. 2022, 21:23:30 »
Tak například Rust, APL/BQN/J (nebo podobný polní jazyk), nějaký ten LISP, Haskell, Idris 2, OCaml, Prolog, Ada (+SPARK), SQL.

Až na to SQL je to jedna zbytečná nepraktičnost vedle druhé. Proč ho matete?
SQL je naopak skvělá volba. Snadný jazyk, který se naučí za rozumný čas. Vysokoúrovňový jazyk. Užitečný jazyk. A dokonce i ta aritmetika a funkce tam jsou. Já jej doporučuji jako první ideální volbu.

SQL je základ. Kdo neumí SQL je amatér.

53
Vývoj / Re:Jaký jazyk bych se měl učit?
« kdy: 31. 10. 2022, 05:01:31 »
Tak například Rust, APL/BQN/J (nebo podobný polní jazyk), nějaký ten LISP, Haskell, Idris 2, OCaml, Prolog, Ada (+SPARK), SQL.

Citace
Můj učitel říká, že se nejdřív musím naučit Python a Javu a potom další jazyky
Eh, to člověku zase moc nedá...

Podle mne je úplně jedno, v čem se člověk učí programovat, a jestli začne Pascalem nebo Lispem nebo Basicem. Já jsem začínal papírovým počítačem, pak programovatelnou kalkulačkou, Basicem, a assamblerem. Pak jsem přešel na Pascal  a C, a pak Visual Basic a .NET, atd. Nikdo neříká, že první programovací jazyk, který se člověk učil na škole bude pak celý život používat. Je dobré si projít víc programovacích jazyků, víc technologií - víc databází. Rozšířit si obzor, a zjistit, co člověku vyhovuje a co ho baví. Není jedna nejlepší technologie - jeden programovací jazyk. Kolem každé technologie existují dneska tuny knihoven, vývojářských nástrojů, komunita, trenéři, lektoři a blogeři, trochu jiná kultura.

Docela smutný pohled je na kodéry, kteří v životě pracovali pouze s jednou technologií, a při přechodu na jinou technologii nejsou schopní akceptovat jinakost té jiné technologie, nebo vůbec netuší jak široký záběr má IT.  Jednak mají malý rozhled, druhak si nevypěstují technický cit, neřeší co na co použít, jak a proč. Kolikrát ani netuší, že jim chybí nějaká technologie, znalost, nebo že něco implementují hrozně tupým, nešikovným nebo špatným způsobem.

54
Vývoj / Re:Jaký jazyk bych se měl učit?
« kdy: 30. 10. 2022, 14:42:45 »
lidi delate tady v C ?

Dělám - PostgreSQL je napsán v C0čku. Extenze do Postgresu se primárně píší v Céčku.

55
Server / Re:PostgreSQL: objem a obsah WAL logů zpětně
« kdy: 29. 09. 2022, 17:59:11 »
Diky, koukal jsem ted na ten pgbadger a uz jsem taky zjistil, ze to parsuje klasicky log a netyka se to WAL logu.
Moje chyba, spatne jsem to pochopil.
Jinak napad s nastavenim logu a naslednou obnovou je fajn, ale nejspis to v tomto konkretnim pripade nebude mozne.

Tak jestli máte archivované wal logy, tak možná tam budete mít atime v souboru - je otázkou ale jak daleko do historie máte archiv wal - dost často se drží 2 týdny, max měsíc - i když záleží na provozu. Případně transakční log má v sobě nějaké timestampy, minimálně kvůli implementaci recovery_target_time, takže z toho by se dal odvodit čas vytvoření transakčního logu. Na to abyste se podíval, co je v transakčním logu slouží https://www.postgresql.org/docs/current/pgwaldump.html

56
V Postgresu samotném nikde nevidíte historická data. Pro provoz se doporučuje používat aplikace jako je Munin, Zabix, pgwatch2, ... které si metriky z Postgresu sbírají a drží historii. Postgres sám to nedělá. Pokud jste žádný takový tool neměli, tak nic nenajdete.

57
Vývoj / Re:Trendy v PHP
« kdy: 08. 09. 2022, 16:27:24 »
No take objektivne: UT8 stringy - na prvy pohlad super, v realite ciste zlo, milion dalsich typov stringov
UTF8 má po řetězce spousta jazyků, proč je to zlo?
Že má několik typů pro řetězce je fakt, ale dává to smysl, ne? Převod na řetězce à la C nebo na seznam run se řeší všude možně, Go to má, i Fortran, dokonce i v rámci C existuje několik typů třeba na Windows.

Je to vykonova pasca. A mizerne sa s tym pracuje, neustale konverzie zru vykon. Ja viem, ze sa to zda pohodlne, ked sa stringy len spajaju, ale parsovanie cohokolvek je fakt cista bolest. To, ze to ma tak aj Go ma moc nezaujima, je to priserny jazyk.

No rad by som vratil temu k aktualnym trendom v PHP.

Dělám v C, kde podpora UTF8 je minimální, a při parsování stringu v utf8 je jen o pár instrukcí delší. Horší je, když máte ještě podporovat 8bit kódování. V podstatě jedinou problematickou operací, která se mi nad utf8 hůře dělala je reverse search.

58
Hardware / Re:Nový IBM mainframe Z16
« kdy: 29. 08. 2022, 14:11:57 »
@Pavel.Stehule no zrovna cobol ti dovoli fakt slusny hnoje :D

U manuálu COBOLu jsem skončil na 10 stránce, a dál jsem to nedal., takže toho o COBOLu vím málo. Ale pověst ho předchází, takže jsem to myslel spíš na management, že se drží zpátky a není moc kreativní.

59
Hardware / Re:Nový IBM mainframe Z16
« kdy: 29. 08. 2022, 07:36:00 »
Citace
Mali sme asi len raz taky pripad par rokov dozadu, ze u nas vyvinuli batch aplikaciu v Jave ktora bezala niekolko hodin a preto bola prakticky nepouzitelna. Boli sme preto nuteni ju prepisat do COBOLu kde bezala len niekolko minut. Odvtedy take pripady nemame, lebo batche robime prioritne v COBOLe.

V tomhle případě má ten COBOL k datům extrémně blízko, tak to může být opravdu dost rychlé. Je to vlastně analogie uložené procedury naprogramované v C s velice low low přístupem. A vzhledem k tomu, že to je COBOL, tak si nikdo nedovolí vymýšlet nějaké špeky. A COBOL sám je velice efektivní personální filtr :).

60
Hardware / Re:Nový IBM mainframe Z16
« kdy: 28. 08. 2022, 15:28:36 »
Jako základ znalostí o IBM mainframech doporučuji PDF přednášky pana Tomáše Oberhubera:
https://kmlinux.fjfi.cvut.cz/~oberhtom/mainframe/

Kdo by s tím chtěl dělat dobrovolně? Ergonomie 60 let 20 století v 20 letech 21 století.

Stran: 1 2 3 [4] 5 6 ... 31