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.
Výkon při využívání těchto systémových prostředků současně byl testován rozbalením zdrojových kódů jádra. Zdrojové kódy byly rozbalovány desetkrát po sobě, každá kopie do samostatného adresáře. Pomocí time bylo měřeno, za jak dlouho se rozbalování dokončí.
Testovací proces byl postupně spuštěn na hostiteli2, na jednom KVM 1/1 hostu a jednom Xen 1/1 hostu. Ve všech případech byl test třikrát opakován.
Hostitel | KVM 1/1 | Xen 1/1 | |
---|---|---|---|
minimum | 5 m 10,147 s | 2 m 50,257 s (-45,1 %) | 4 m 54,941 s (-4,9 %) |
průměr | 5 m 11,105 s | 2 m 52,423 s (-44,6 %) | 4 m 56,981 s (-4,5 %) |
maximum | 5 m 12,231 s | 2 m 55,511 s (-43,8 %) | 4 m 58,776 s (-4,3 %) |
Test byl spuštěn sedmkrát paralelně na hostiteli, na sedmi KVM 1/1 hostech a sedmi Xen 1/1 hostech. Test byl třikrát opakován.
Hostitel | KVM 1/1 | Xen 1/1 | |
---|---|---|---|
minimum | 26 m 17,560 s | 22 m 45,506 s (-13,4 %) | 44 m 47,015 s (+70,3 %) |
průměr | 38 m 43,156 s | 71 m 57,967 s (+85,9 %) | 50 m 55,523 s (+31,5 %) |
maximum | 46 m 25,065 s | 137 m 40,253 s (+196,6 %) | 57 m 53,668 s (+24,7 %) |
Práce s diskem je naopak pro virtualizované prostředí poměrně problematická zátěž – většina práce sestává z operací s virtualizovaným hardwarem, které je nutné „přeložit“ pro hardware skutečný – to se v tomto testu také ukázalo. Samotné rozbalování nebylo příliš náročné na CPU a zátěž se tak v podstatě skládala ze zápisů mnoha souborů na disk3.
Poměrně překvapující je proto výsledek virtuálních strojů 1/1, které při samostatném běhu rozbalování zdrojových kódu jádra dosáhly kratšího času než samotný hostitel, KVM dokonce výrazně kratšího. S největší pravděpodobností je to důsledek ukládání zapisovaných dat do paměti se zpožďováním skutečného zápisu na disk.
Při paralelním běhu byl výkon KVM podstatně horší. Zatímco Xen si s paralelním rozbalováním poradil poměrně dobře, testovací běh KVM způsobil velké přetížení hostitelského systému – při vzdálené práci přes SSH byla odezva na stisk klávesy řádově několik vteřin a v dmesg se objevovala hlášení typu
BUG: soft lockup – CPU#0 stuck for 135s! [kswapd0:179] INFO: task pdflush:1648 blocked for more than 120 seconds.
a podobná. Oproti Xenu také trvalo déle úlohu zpracovat.
Poznámka – zatímco Xen u této úlohy při každém běhu podával víceméně stejné výkony, KVM z nějakého důvodu podávalo při každém běhu různé – při jednom běhu dosáhlo všech sedm hostitelů času okolo půl hodiny, při jiném naopak všem hostům trvalo zpracování stejného testu hodiny dvě. Pokud někoho napadne, čím by to mohlo být způsobeno, nechť dá vědět v diskuzi.
K dobru je zde KVM možné přičíst to, že po dokončení testů se situace vrátila do normálního stavu, s hostitelem i hosty bylo možné normálně pracovat a žádný host nezhavaroval. Také je zde vhodné uvážit, že takováto zátěž, kdyby měla být provozována v produkčním prostředí, by si zasluhovala více než jeden fyzický stroj.
2 Ve všech případech, kdy se na hostiteli testuje úloha využívající souborový systém, je tento souborový systém vytvořen na LVM oddílu. V případě, že na hostiteli běží několik testů paralelně, je na LVM vytvořeno tolik oddílů, kolik úloh běží.
3 To s sebou hlavně při paralelním běhu testovacích úloh navíc přináší nutnost neustále měnit polohu hlaviček disku, což se podepisuje na výkonu i při běhu na hostiteli.
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