Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Práce s pamětí nebyla měřena žádným benchmarkem, můžeme nicméně srovnat, jak obě virtualizační technologie s pamětí pracují a jaké z toho pro ně plynou výhody a nevýhody. Částečně se přitom zaměříme i na to, jak dostupné mechanismy umožňují přidělit hostům více paměti, než má hostitel.
K čemu je to dobré? Málokdy se stane, že by všichni hosté najednou potřebovali využít všechnu paměť, která je jim přidělena. Rozdáním většího množství paměti je tedy možné hostitele využít intenzivněji, aniž by tím výrazně utrpěl výkon.
Poměrně často používaná technologie je „balónový ovladač“, který zabere paměť v hostovi tak, aby ji nebylo možné použít; tuto paměť je poté možné vrátit hostiteli k využití jinde. Jak KVM, tak Xen (a další) tento mechanismus využívají. Je nicméně potřeba brát v potaz, že tento mechanismus vyžaduje spolupráci hosta, který musí danou paměť nějak uvolnit, když je to po něm požadováno.
S tím souvisí i fakt, že přinejmenším u KVM je tento ovladač (virtio_balloon) zcela obyčejný ovladač6, je ho tedy možné vyjmout z jádra, pokud se k tomu správce hosta rozhodne. Uvolňování paměti tímto způsobem tedy není příliš spolehlivé.
V jádře 2.6.32 se objevila technologie KSM, což je mechanismus, který periodicky prochází fyzickou paměť hostitele (a tedy i hostů) a hledá identické stránky. Tyto stránky následně sloučí – ve fyzické paměti nechá pouze jednu kopii, paměť zbylých kopií je uvolněna k použití jinde.
KVM tuto technologii přijalo poměrně rychle, prakticky ihned po vydání jádra 2.6.32 (od 2.6.33 je možné sloučené stránky odswapovat), ve kterém se KSM objevilo poprvé. Xen od verze 4.0 umožňuje něco podobného (nedohledal jsem, jestli používá nějak upravené KSM nebo svůj vlastní mechanismus). Od verze 4.0 Xen také umí využít mechanismus přechodné paměti, který ještě nebyl začleněn do hlavní řady jádra a KVM jej nepoužívá.
Velmi důležitý rozdíl je ale ve způsobu, jak oba virtualizační mechanismy pracují s pamětí hostitele a jak ji přidělují hostům. Xen mapuje paměťové stránky hostů přímo do hardwarových tabulek stránek hostitele – neumožňuje tedy systému správy paměti v hostiteli s těmito stránkami nijak pracovat, což mimo jiné znamená, že tyto stránky nelze odswapovat.
Virtuální stroj KVM z pohledu operačního systému vypadá jako běžný (téměř) proces – jeho paměť tedy lze odswapovat – záležitosti s tím spojené řeší mechanismus stínových stránek nebo hardwarová podpora přímo v CPU. To určuje i způsob, jak je možné na hostech nasadit nejčastěji praktikovanou metodu využívání více paměti, než je fyzicky k dispozici – swapování. Zatímco u KVM je možné prostě hostům přidělit více paměti a žádný swap (swapování vyřeší hostitel), u Xenu je nutné dát každému hostovi k dispozici jeho vlastní swap, což je méně flexibilní a navíc to vytlačuje víc práce s diskem směrem k hostovi.
Lze tedy říci, že KVM je na tom díky spolupráci se správou paměti hostitele v mezních situacích o něco lépe. Prakticky se to ale může projevit jenom v případě, že je hostům přiděleno více fyzické paměti, než má hostitel k dispozici. Pokud se ji všichni hosté pokusí využít zároveň, všechny výše zmíněné mechanismy pravděpodobně selžou – v takovém případě KVM začne swapovat, kdežto Xen (pokud si dobře pamatuji) zastaví některý z virtuálních strojů.
6 Například pro VMware platí to samé.
Iozone je nástroj pro benchmarkování souborového systému (a v podstatě tedy i hardwaru pod ním, pokud je souborový systém stejný). V nejjednodušším volání (iozone -a) provádí několik typů testů (zápis, přepis, čtení, náhodné čtení, …) na různě velkých datových souborech (od 64 kB do 512 MB) s různě velkými záznamy (od 4 kB po 16 MB). Výstupem je objem dat za sekundu, který lze daným způsobem zpracovat.
Původně se výsledky tohoto testu měly objevit mezi benchmarky výše, ale při paralelním běhu se v naměřených datech objevily nesrovnalosti: Xen podle průměrných hodnot podal lepší výkon než KVM (ztráta oproti hostiteli 20 %, KVM mělo cca 40 %), nicméně na všech virtuálních strojích KVM testy doběhly do cca 10 minut, kdežto na virtuálních strojích pod Xenem běh trval tři hodiny. Zjištěná data by tedy bylo nutné dodatečně upravovat a vypovídací hodnota takových výsledků by pravděpodobně nebyla nijak velká.
Při běhu na jednom hostu KVM podalo o cca 20 % větší výkon než hostitel (pravděpodobně vliv cache), Xen o 4 % horší.
Jak je vidět, z těchto měření nelze nijak dobře vyvozovat, které z virtualizačních řešení je lepší. Za normálního provozu je výkonnost srovnatelná a pokud hostitele přetížíme, je přetížen bez ohledu na to, jak virtualizujeme.
Před vydáním Xenu 4.0 bylo KVM trochu ve výhodě, co se vlastností týče, nyní je situace víceméně vyrovnaná. Při rozhodování, které řešení nasadit, je nicméně zapotřebí brát v potaz i to, že KVM začleněné v hlavní řadě jádra rychle přijímá nové vlastnosti (z nichž většina zlepšuje výkon). Uživatelé Xenu musí čekat na to, až vyjde verze pro novější jádro.
Tato lepší spolupráce s hlavní řadou jádra společně s faktem, že za KVM se postavil Red Hat, jsou důvody, proč mnoho vývojářů věří, že KVM nakonec nad Xenem zvítězí jak co se výkonnosti, tak co se počtu nasazení týče.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Ano, to je velice nepříjemná věc v debianu (u mě squeeze) - musí se instalovat balík "qemu-kvm", protože balíček "kvm" je VELICE a značně zastaralý, způsobuje výkonnostní anomálie, padání guestů, ...
Prvne diky moc za clanek.
Kdyby na to nekdy byla chut, tak bych moc rad videl aspon zakladni porovnani behu widli na Xen a KVMku. Sam jsem si hral s Win 2k3 serverem a na obojim se chova proti Linuxu mnohem hur. Na Xenu widle doslova staly na miste kvuli desivejm odezvam. Na KVM to bylo lepsi, ale zase se dost desne chovaly disky.
Lidi, jakou mate zkusenost s virtualizaci widli? Zaslech jsem, ze velmi dobre chodi vmware server, ale zrovna nemam volnej HW na testovani.
Protože se KVM poměrně rychle vyvíjí, byla použita verze z Debianu Unstable – v té době nejnovější jádro 2.6.31 (balík linux-image-2.6.31-1-amd64) a kvm-85 (85+dfsg-4.1).Opravdu bylo použito poslední KVM? kvm-85 je poměrně starý balík. Aby nedošlo ke zmatení čtenářů... Sám používám na desktopu unstable a používám balík qemu-kvm, teď ve verzi 0.12.3+dfsg-4. V dokumentaci se lze dočíst v
/usr/share/doc/qemu-kvm/changelog.upstream-kvm.gz
, že tento balík je založen na kvm-88 [12 july 2009]. Sám jsem používal chvíli kvm-85 a měl problémy s virtualizovanými Windoze. Po čase jsem si všiml balíku qemu-kvm (s novějším KVM). V tom mě Windoze běžely o řád lépe (to už je tak 3/4 rok zpět). Tedy nevím kdy tyhle testy proběhly, ale o aktuálnosti user-space části KVM lze dost pochybovat?
No a co se týče XENu, tak ten je teď samozřejmě v kernelu 2.6.32 připravován pro Squeeze také zřejmě v novější podobě.
Nechtěl by si někdo dát práci a ty testy zopakovat?
Opravdu bylo použito poslední KVM?V té době... je to cca půl roku, spíš víc, nechá se to odvodit i podle "nejnovějšího jádra" 2.6.31. Holt docela dlouho trvalo to sepsat.
qemu-kvm (0.11.0+dfsg-1) unstable; urgency=low * Package qemu-kvm (stable series) instead of kvm (snapshots) * Simplify the packaging, remove support for external module source * Move old debian/changelog to debian/changlog.kvm -- Jan Lübbe <jluebbe@debian.org> Mon, 02 Nov 2009 11:49:28 +0100Zrejme ty testy probehly jiz v roce 2009...
Bohuzel spatne dopadl test site a spousteni.Teď jsem ještě zkusil netperf -t TCP_STREAM mezi KVM Linux hostem (virtio síť) a fyzickým strojem (ne hostitelem) a vyšlo cca 920×10^6 b/s na gigové síťovce. Stejný fyzický stroj proti hostiteli dá 940, takže tu síť bych opravdu tak špatně neviděl. netperf AFAIK používají k benchmarkování i vývojáři jádra, takže špatným nástrojem to IMO taky nebude...
Zalostne taky dopadlo rekurzivni spousteni skriptu. Linux Host mel 1:25 (v minutach), XEN guest mel 1:34, windows xp host s cygwinem sam mel 20:31.Zatímco v Linuxu, jako ostatně ve většině unixů, jsou procesory "lehké" (light-weight) a jejich spouštění přes
fork()+exec()
relativně nenáročné, ve Windows jsou procesy relativně "těžkotonážní", fork()
není nativně v dispozici (Cygwin ho musí emulovat) a mnohem víc se využívají lehká vlákna. Pokud se na
Windows provozuje program silně používající unixový styl (např. právě ono rekurzivní spouštění skriptů), je logické, že výsledek dopadne takto žalostně.
Pamatuju si, jak jsem kdysi musel při portování jednoho svého programu z Linuxu na Windows přepsat volání externích utilit na používání knihoven, protože to, co Linuxu běžel celkem slušně, bylo ve Windows nepoužitelně pomalé - rozdíl v rychlostech byl téměř o řád a většinu zátěže spotřebovalo spouštění oněch externích utlilit (užívaných jako "filtry" na načítání vstupních a ukládání výstupních obrázků).
Tisk bez diskuzetak dostanes cely clanek...
Asi tolik ke slavne virtualizaci