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 - _Tomáš_

Stran: 1 ... 3 4 [5] 6 7 ... 47
61
Server / Re:Update kernelu na VPS
« kdy: 23. 02. 2023, 11:01:32 »
A ono je běžné, že by hostingy jako VPS nabízeli kontejner? Znám vpsfree, ty používají lxc a kvm, co si vybavuji, ale ostatní?

62
Server / Re:Update kernelu na VPS
« kdy: 22. 02. 2023, 14:57:18 »
to je různé. Někteří používají svoje kernely s určitými úpravami. Není nic jednoduššího než se zeptat na podpoře nebo zapátrat ve znalostní databázi, či se na ten kernel podívat, zkusit ho vyměnit a uvidíš co se děje.

Osobně nenechávám kámen na kameni a všude si nasazuji vlastní linux s latest stable kernely, zatím mi to funguje bez problémů u většiny hostingů, dokonce i u ovh jsem to dokázal dát dohromady.

Obecně by mělo platit, že kernel bys měl mít možnost libovolně vyměnit (v rámci nějaké kompatibility k HW, což u virtuálů bývá šumák). Pokud tam má hosting nějaké custom kernel s vlastními moduly, raději bych uvažoval o změně hostingu.

Pokud prozradíš hosting, třeba já nebo někdo jiný bude vědět konkrétně. Kernel samozřejmě musí virtualizovaný HW podporovat, případně pokud je použit nějaká tenká virtualizace s virtio, musí to opět kernel mít zapnuté a podporovat. Ve výchozím stavu to ale u většiny distribucí bývá vše ok.

63
Sítě / Re:Monitoring sítě
« kdy: 20. 02. 2023, 22:10:06 »
Pouziva niekto ntopng ?

používá. Otázka měla znít spíše, jestli to používá někdo, kdo tomu i rozumí. Na tom nástroji je vlastně vše špatně, při větším provozu je nepoužitelný a zatím jsem neviděl use case, kde by dobře fungovat, možná leda na interních serverech, kde není běžný internetový provoz. Raději mám pořád zeek a spousty časem vyladěných filtrů.

64
Server / Re:Postgres: pg_checksum v kontejneru
« kdy: 16. 02. 2023, 12:06:11 »
zastav docker, spušť si nový s přetíženým entrypoint, tam buď přímo nebo v shellu spušť ten pg_checksum, bude to trvat nějakou dobu v závislosti na velikosti databáze. Je nutné mít shodné prostředí (uživatel, data dir, konfigurace) jako má běžně spuštění. Vypočítá se checksum pro všechny soubory a nastaví se příznak, že se má checksum počítat. Pak můžeš zase spustit běžný docker s pg.


65
Studium a uplatnění / Re:Platové ohodnocení PHP
« kdy: 15. 02. 2023, 21:51:24 »
Ja se zeptam znalcu mistnich pomeru - pouziva se PHP u nejakych vetsich projektu, nebo je to porad spise domena malych projektu pripadne uprav nejakeho web publishing systemu?

co je velkej projekt? PHP je pořád dost rozšířené, damejidlo, uloz.to, zasilkovna.cz, root.cz (resp. celý internet info), rohlik.cz a spousty dalších. Z těch, které jdou do světa, tak třeba keboola je v php

66
za 17500 bez DPH jí mohu mít novou. Nabízím za ní 10000 czk.

67
Server / Re:Dvě verze PHP v rámci jednoho serveru
« kdy: 01. 02. 2023, 08:44:57 »
Mezitim v debian svete solved behem 5 minut diky Ondrovi a fpm.

Obecne bys mel zvazit containers.

ale tady je možné úplně stejné řešení, https://remi.mirror.karneval.cz/enterprise/9/, ale je to pořád řešení mimo distribuci a to asi scientificu vadí a tak se ptá, jestli to není možné dělat nativně přímo v distribuci.

68
Server / Re:Proxmox - IOMMU/VT-d přemapování IRQ
« kdy: 01. 02. 2023, 00:01:41 »
viz https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#Bypassing_the_IOMMU_groups_(ACS_override_patch) a https://www.kernel.org/doc/html/v5.10/x86/intel-iommu.html

Můžeš jít cestou přes virtuální ovladač, ale předpokládám, že chceš pci passthrough, tam vím jen o patchování linux kernelu, viz odkaz na archu. Nevidím v datasheetu, že by ta deska to nějak uměla konfigurovat.

S rozhazováním cpu jader nemám vůbec zkušenosti, když už rozhazujeme celé sockety.

69
Server / Re:Dvě verze PHP v rámci jednoho serveru
« kdy: 31. 01. 2023, 23:49:23 »
Zdravím,
pokud je potřeba provozovat na jednom http serveru více php verzí nevidím v tom problém běžně se to řeší přes FPM nebo FCGI a http dns vhost.

Neřešil bych vůbec co Vám dává distribuce za php runtime, pro chod webu můžete mít více php instancí a každá sajta je obsluhována jiným runtimem na stejném portu 80 nebo 443 a ani jedna nemusí využívat php z distribučních mirrorů.
Běžně se to tak dělá.
Pokud se Vám s tím nechce patlat na howtoforge máte navody na ispconfig a podle toho to zvládnete.

a běžně se takové php instance bokem neaktualizují, že jo. Předpokládám, že scientific se na to ptá právě proto, že se nechce starat o aktualizace a řešit nic navíc, jen by rád měl více verzí php najednou out of box.

ispconfig je skvělá věc, pokud člověk chce mít na serveru potenciálně spousty zranitelností.

Spíše než použití fpm/fscgi na jiných portech/socketech jde o konfigurace k php, všechny balíčky počítají s /etc/php a tam se i instalují další pluginy, které zároveň triggerují restarty a reloady. Více verzí znamená kompletně zdvojit strom všeho na čem php zavisí a co závisí na něm, což je třeba příklad toho remi.repo.

Kombinování více verzí php na redhat klonech nelze bez ruční práce nebo neoficiálních repositářů, osobně doporučuji containery (docker, podman, systemd-nspawn atd.) nebo virtuály/více serverů.

70
Vývoj / Re:Dokumentové databáze a relační data
« kdy: 31. 01. 2023, 10:29:49 »
třeba relační databáze se těžko horizontálně škálují, ale zase mají ACID

Ne, škálují se stejně jako nerelační (dokumentové), když mi stačí je mít jako key-value uložiště. Problém se škálováním právě nastává, když chci využít jeji ACID, transakčnost, spolehlivost, pak se to škáluje špatně, ale to je dáno teoretickým omezením (CAP).

Jsem fanouškem všech různých druhý neklasických databází, u spousty z nich jsem si tak prohloubil znalosti, až konzultace a správu nabízím jako službu. Pořád ale platí, že pokud si nechci hrát a nechci mít starosti, mariadb/postgresql mi poskytnou rychlejší odezvu, lepší správu, nižší HW nároky, stabilnější provoz než většina nerelačních databází a obě mohu vždy používat jako dokumentové, pokud chci.

Lámat se to začne až s velkým provozem (např. ustát 1M qps nebo 99th do 5ms či uložit 100 TB dat) chce už jiný přístup a tady relační databáze ztrácí, ztrácí hodně a bývá levnější je nepoužít. Pokud je někdo použije, je nutné investovat do mikrooptimalizací, úpravy kódu, přizpůsobení aplikace a struktury dat, už tu není ta efektivita a flexibilita. O tom se ale nebavíme, jen většina argumentů se právě o tyhle vlastnosti opírá (viz tvoje výtka se škálováním).

71
Vývoj / Re:Dokumentové databáze a relační data
« kdy: 30. 01. 2023, 21:08:39 »
já bych jako velkou nevýhodu dokumentové databáze viděl evoluce struktur a spousty různých runtime checků, aby ti aplikace nespadla, když tam je něco jiného než kód čeká. Pokud se k projektu vrátíš po nějaké době, relační model ti řekne hodně, obsah dokumentové databáze nic.

72
Server / Re:Dvě verze PHP v rámci jednoho serveru
« kdy: 30. 01. 2023, 19:26:22 »
spíše tvůj use case je nesystémový :), chceš mít dvě verze php jako systémový balíček, na což není redhat a jeho klony postavený, je to věc balíčkovacího systému a toho jak je postavený repositář, redhat umí dobře jednu verzi a ne dvě.

Žádná distribuce neumí vše, nic ti ale nebrání si zvolit svoji cestu, není to uzavřené, my hodně používáme containery (podman) na možnost mít více verzí zároveň, tj. pak si to aplikace nese s sebou. Stejně tak, pokud je potřeba třeba více verzí MySQL tak máme prostě více serverů (= single responsibility) a nemícháme to dohromady.

73
Sítě / Re:Software pro dokumentaci síťové infrastruktury
« kdy: 30. 01. 2023, 17:12:27 »
částečně to co chceš umí IP Fabric, dokonce si řadu údajů detekuje i sám, otázka je jen pro jak velkou síť to děláš. Vizualizace portů a jejich propojení ale většinou děláme v RDBMS vlastní cestou, protože často jsou nějaká specifika propojení (lacp, mlacp, backup atd. atd.) a to často závisí na konfiguraci stanic a ne portů samotných.

74
Desktop / Re:Poraďte zajímavé využití RAM disku v Linuxu
« kdy: 29. 01. 2023, 00:00:52 »
Já se netajím, že nejsem velký fanoušek tmpfs. Má svoje využití, ale často lze podobného efektu dosáhnout i lépe. Kernel umí „volnou“ RAM využívat jako cache pro soubory. Z hlediska čtení tak vlastně může stačit spustit něco jako find /some/dir -print0 | xargs -0 cat > /dev/null, abychom načetli adresář do cache. Případně lze použít ionice, aby se prefetch provedl s co nejnižší prioritou. A asi tu budou i lepší prefetchovací nástroje. (Pamatuju si nějaké, které sloužily spíše pro urychlení bootu – zejména ureadahead.)

Z hlediska zápisu se to samozřejmě tmpfs nevyrovná, zejména pokud něco trvá na syncnutí dat na fyzické úložiště. Ale v případě indexů to možná nebude až takový problém. Šlo by si s tím hrát i více a optimalizovat nastavení FS, aby tolik nehrotil konzistenci, ale čekám:

1. Trochu drbačku,
2. Uvažování nad tím, kde to nevadí jak moc ošulit a
3. Často minimální přínos.

na tohle roky používám https://hoytech.com/vmtouch/, dokonce to je součástí mnoha produkcí našich bank, v podstatě tim zajištujeme zahřátí dat do paměti, výhoda je, že to transparentní, velice efektivní a plně konfigurovatelné.

Existuje třeba eatmydata(1), který umí přepsat v glibc fsync funkci a pro daný program jí deaktovat, je pak možné nechat persistování na nastavení kernelu, používám na raspberry pi, aby mi programy příliš často nezapisovali na disk, mám přímo glibc patchovaný.

Pokud jde o využití velké paměti, tak jí mám všude vždy nedostatek. U vývojového stroje zásadné vše kompiluji do tmpfs. Na windows mám zase ramdisk na datový složky pro hry (sync z disku při startu os nebo ručně). Rád třeba věci jako zpracování fotek dělám rovnou z tmpfs, to mi nestačí ani 200GB.

75
Server / Re:K8s, PostgreSQL a replikace na tři nody
« kdy: 26. 01. 2023, 16:04:22 »
Nakoniec som to vyriesil cez gluster replikovany volume na vsetky nody, cize moznost c.3.. Nad tym bezi 1 kontajner postgre, ktory sa v pripade vypadku nodu do 1minuty presunie na iny node. Testujem, zatial to funguje OK.

mít jednu instanci pg je správné řešení, můžeš mít další nastartovanou jako readonly, ale nedoporučuji v téhle konfiguraci dělat master-master.

absolutne netusis o com hovoris :) Cassandra je vsetko len nie mrtva.
Cassandra 5 bude mat ACID transakcie. Na indexy mas SAI (storage attached index).

Ano, nestačí jim paxos, protože s ním latence brousí podlahu, tak zkouší raft, ten jim nesedí, je asi příliš málo závislý na čase, takže si přišli s accordem, který spoléhá jen a pouze na přesný čas, ale třeba nám v březnu řeknou víc, že?

Cassandra nepatří do rukou běžným lidem, to musíš očividně sám vědět, správný návrh schémat, způsob práce s daty se musí řešit na úplně začátku a jakákoliv změna v průběhu je složitá. Vektor použití je hodně jiný než obecná RDBMS a jen tak jí doporučit v diskuzi aniž bys tušil jak daná aplikace funguje je nezodpovědné.

Stran: 1 ... 3 4 [5] 6 7 ... 47