Příspěvky

46

Server / Re:Je takýto výkon VPS OK?

« kdy: 19. 04. 2023, 19:54:33 »

Uf, přijde mi, že mícháte dohromady typ hypervizoru a způsob virtualizace. Xen již dávno není jen o paravirtualizaci (PV), umí i úplnou virtualizaci (HVM) a několik variant někde na půli cesty. V některých případech (z hlavy si nejsem jistý, kdy přesně) se EPT využije. Dokonce lze různé způsoby virtualizace kombinovat v jedné instanci Xenu, a QubesOS toho využívá – primárně používá PVH, potom HVM se stubdom (pro PCI passthrough nebo nepodporované OS), a nakonec pár PV (dom0 a stubdom). Nicméně je pravda, že se od původního módu (PV) spíše upouští, zvlášť po Spectre/Meltdown, kde po záplatách byl dopad na výkon celkem drastický.

Pro Xen stále jsou někdy dobré důvody, přinejmenším jsou o tom přesvědčeni autoři QubesOS, kteří u něj při vhodné konfiguraci vidí menší attack surface.

47

Server / Re:Je takýto výkon VPS OK?

« kdy: 19. 04. 2023, 10:05:34 »

Tak třeba v Xenu to tak zřejmě je. Resp. nejsem si 100% jistý, že to platí pro každou myslitelnou konfiguraci, ale moc mě nenapadá, jak docílit něčeho jiného. Xen běží nad „hostitelem“ (tzv. dom0), nebo-li hostitel je v podstatě první virtuálka, která má přístup ke všemu HW (dokud jej nepředá někomu jinému) a může spravovat další VM. Xen spravuje RAM – typicky hostitel se části RAM vzdá a nechá Xen ji přidělit jinému VM. O swap se pak stará až kernel, tedy každá VM zvlášť. Tak mi to funguje v QubesOS, což je OS založený na virtualizaci.

Podobnou situaci bych čekal u hypervizorů s podobnou architekturou, třeba HyperV, na kterém stojí mj. WSL.

A vlastně to dává smysl i u tradičnějších virtualizátorů jako VirtualBox a KVM. Jednak kvůli výkonu (přístup k paměti ve VM by si vyžádal průchod zbytečně mnoho vrstvami), jednak kvůli zmíněným překvapením, a jednak protože takovéto věci typicky běží v kernelu a mohou dělat různé psí kusy…

Zkoušel jsem se – s vědomím, že není vševědoucí a někdy kecá – na tuto otázku zeptat i ChatGPT. Tvrdí, že nezná virtualizátor, který by swapoval guesty, ale že je běžné udělat nějaký overcommit. Neberu to jako jednoznačný důkaz, ale přinejmenším nevyvrátil moji hypotézu.

48

Server / Re:Je takýto výkon VPS OK?

« kdy: 18. 04. 2023, 18:48:19 »

Nejsem si jistý s tím odswapováním VM, ale může záležet na technologii virtualizace. Třeba Xen to IIUC nedovoluje. Intuice říká, že to nedává moc smysl, protože pro guesta je to docela past. Navíc virtualizační software (není-li to emulátor) nebývá obyčejná aplikace, ale typicky jede na úrovni kernelu, ne-li nad ním.

49

Server / Re:Je takýto výkon VPS OK?

« kdy: 18. 04. 2023, 17:49:35 »

Pokud je tam rotační HDD sdílený s ostatními, může přístup na něj docela trvat. Linux (a snad všechny běžné OS) cacheuje často používané soubory v RAM. Pokud ale se RAM využívá až na dřeň, mohou i některé často používané soubory vypadnout.

Tedy IMHO se sejdou dva faktory:

1. Soubor není v RAM cache, a je potřeba jej načíst s HDD. (Proto se to typicky nestane dvakrát hned po sobě.)
2. HDD dost vytěžuje i někdo další.

V CPU bych problém spíš nehledal, i když teoreticky je taky možné, že by jedno jádro sdílela hromada VPS. Ale to by asi nebyl problém jen prvního příkazu.

50

Odkladiště / Re:Je možné získání dat skrze XXE?

« kdy: 08. 03. 2023, 14:53:02 »

Hlavní bylo již odpovězeno, okomentuju jen chybovou hlášku. To sice asi nebude u XXE hlavní cesta, ale obecně bych chybové hlášky nepodceňoval. Když se člověk snaží, někdy dokáže do chybové hlášky dostat zajímavé informace. Vzpomínám si, že jsem si takto kdysi hrál s MySQL, kde nějaká funkce při špatném vstupu jej vypsala do chybové hlášky.

51

Vývoj / Re:Příklad abstraktní třídy

« kdy: 27. 02. 2023, 11:34:20 »

Většinou bych dával spíše přednost rozhraním a kompozici před abstraktními třídami a dědičností. Při kompozici mohu vložit více různých komponent, při dědičnosti mám jasně danou hierarchii.

Nicméně má to i své stinné stránky z hlediska náročnosti na RAM a výkon:

1. Hierarchie tříd nemá žádné další paměťové náklady na každou instanci, oproti tomu kompozice znamená další reference, i pokud tu odkazovanou komponentu používáte opakovaně. (Pokud ji vytváříte pokaždé znovu, je to ještě horší…) U tříd, ke kterým máte pár instancí, asi vyhraje použitelnost kódu, ale třeba u kolekcí je IMHO celkem odůvodněné dát přednost dědičnosti.
2. Volání metody třídy může být levnější než volání metody rozhraní, protože je jednodušší prohledat VMT pro jednoduchou dědičnost než VMT pro vícenásobnou dědičnost. Nicméně hádám, že toto obvykle fakt nemusíte řešit, mj. proto, že JVM spoustu věcí zvládne optimalizovat. (BTW, udělat na to benchmark by mohla být zábava – zejména poprat se s optimalizátorem tak, aby do toho neházel vidle…)

52

Hardware / Re:Může uspání jader CPU způsobit problém?

« kdy: 10. 02. 2023, 21:42:29 »

Některý HW řeší brown-out, tedy při poklesu napětí se vypne, a zapne se až zase po zvýšení. Ale pokud brown-out neřeší (může jít i jen o vypnutou ochranu), pak pokles napětí pod nějakou úroveň může udělat leccos.

Raspberry Pi umí detekovat příliš nízké napětí a upozornit na něj. Aspoň pokud ten pokles není příliš strmý, aby Raspberry Pi nebylo schopno reagovat. Možná bude Odroid mít něco podobného.

A ekonomický pohled: možná investovat pár stovek do dobrého zdroje bude levnější než čas strávený laděním.

53

Desktop / Re:QWERTY klávesnice

« kdy: 30. 01. 2023, 11:06:37 »

Toto je už trochu jiný dotaz, zřejmě bude mít i poněkud jiné řešení. Prosím tedy o oddělení do jiného tématu, ať tu není jedno přes druhé…

54

Desktop / Re:Poraďte zajímavé využití RAM disku v Linuxu

« kdy: 30. 01. 2023, 07:58:28 »

Vím, že byla řeč o rotačáku, ale překvapuje mě, že nastavení dirty_* má až takový vliv na rychlost kompilace. I kdybych počítal 5 % z 8G, máme 400M, a to bych čekal, že zápisy při kompilaci vykryje. Možná dirty_expire_centisecs, ale i tam bych intuitivně čekal, že to bude stačit.

55

Desktop / Re:Poraďte zajímavé využití RAM disku v Linuxu

« kdy: 29. 01. 2023, 06:13:57 »

Jo, eatmydata je někdy fajn, ale je nutná opatrnost a znalost, co to vlastně dělá  Někdy bych to chtěl použít spíše na jeden adresář než na celou aplikaci. (Proto jsem zmínil ten FS nakonfigurovaný tak, aby tolik neřešil konzistenci – u ext4 to celkem šlo.) A když to použiju, může být fajn zajistit, že se ta data nepoužijí v případě neslušného vypnutí počítače.

V praxi jsem to používal na DB pro integrační testy. Pokud by došlo k náhlému vypnutí počítače, stejně testy jely od nuly a s čistou DB. Tehdy byla doba, kdy jsem byl rád za nějaké malé 120GB SSD (jako doplněk k HDD) a o NVMe nebyla ani řeč, mám pocit, že šlo o asi dvojnásobné zrychlení, dnes to možná s NVMe SSD nebude tak výrazné, a indexů v IDE bych se na to úplně vykašlal. Ale tam jsem nakonec místo eatmydata použil nějakou konfigurační volbu v PostgreSQL.

Ještě lze něco podobného použít u buildu Dockerových images. IIRC v Dockerových Debianích imagích jsem viděl podobné nastavení pro apt. Na druhou stranu mě tím Docker trošku zklamal – jednak to mohlo fungovat nějak univerzálněji a jednak to mohlo být omezené jen na některé situace (typicky build), v některých edge cases toto chování úplně nechcete.

Filozoficky jsem se inspiroval trochu zde: https://shnatsel.blogspot.com/2012/05/tmpfs-for-real-life-write-buffering.html

56

Desktop / Re:Poraďte zajímavé využití RAM disku v Linuxu

« kdy: 28. 01. 2023, 19:20:05 »

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.

57

Desktop / Re:QWERTY klávesnice

« kdy: 28. 01. 2023, 19:09:21 »

Též mě kdysi trápila cz qwerty. Svého času fungovala, jak jsem očekával, pak jednak došlo k nějakým změnám, a jednak jsem narazil na Windows, kde to fungovalo ještě úplně jinak, a nebyl jsem tam pořádně schopen psát text s diakritikou. A to celé vlastně jen kvůli QWERTY na telefonu.

Nakonec jsem přešel na CShack. V zásadě us layout (až na AltGr a pár drobností) doplněný o českou diakritiku a různé unicode znaky. Na Windows jsem schopen po přepnutí na US layout psát, dokud nemám psát česky.

58

Studium a uplatnění / Re:Přiměřeně lehká IT VŠ

« kdy: 25. 01. 2023, 10:41:43 »

Tak je otázka, jestli vás zajímá spíše programování, sítě, hardware, …

Já byl na FI MUNI, byla tam hromada oborů, část spadala pod studijní program Aplikovaná informatika (obvykle bývaly považovány za tu lehčí variantu). Nějaká předchozí zkušenost s oborem určitě byla výhodou (to asi všude), ale rozhodně ne podmínkou. Výhoda oproti tehdejší FIT na VUT Brno byla v tom, že člověk měl mnohem větší volnost ve výběru předmětů, což může být fajn, pokud chcete v průběhu studia vybrat zaměření. Taky tam byli celkem benevolentní ke změně oboru v průběhu studia (samozřejmě ale člověk musel udělat předměty specifické pro nový obor).

Moje informace o těchto dvou školách nemusejí být aktuální, ale spíš chci ukázat, že tu jsou možná vhodnější kritéria pro výběr školy. A vybírat si lehkou školu, jen protože s oborem nemáte předchozí zkušenosti, nemusí být ta nejlepší cesta – ať vyberete kteroukoli školu, nejspíš tam budou i další lidé bez předchozích zkušeností.

59

Studium a uplatnění / Re:Přiměřeně lehká IT VŠ

« kdy: 25. 01. 2023, 09:20:57 »

VŠ většinou bývají i pro lidi bez předchozích zkušeností. A hlavně je otázka, kam (aspoň zhruba) míříte, IT je široký obor.

60

Sítě / Re:Horší WiFi na MikroTik hAP ax3

« kdy: 20. 01. 2023, 16:58:39 »

To je něco trochu jiného. Mikrotik umí u WPA2-PSK (a a wave2 asi u WPA3-PSK) zvolit PSK podle MAC.

S WPA* Enterprise by šlo udělat něco podobného, ale vyžadovalo by to komplikovanější nastavení, a hlavně by to asi nepobrala spousta domácí elektroniky (kromě počítačů a telefonů).