Byla vydána nová verze 10.2 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Vypíchnout lze nové balíčky Immich, Immich Machine Learning, uv a RustDesk Client.
TypeScript (Wikipedie), tj. JavaScript rozšířený o statické typování a další atributy, byl vydán v nové verzi 6.0. Příští verze 7.0 je kvůli výkonu přepisována do programovacího jazyka Go.
Christian Schaller z Red Hatu na svém blogu popsal své zkušenosti s používáním AI při vývoji open source aplikací pro Linux. Pomocí různých AI aktualizoval nebo vytvořil aplikace Elgato Light GNOME Shell extension, Dell Ultrasharp Webcam 4K, Red Hat Planet, WMDock, XMMS resuscitated (aktualizace z GTK 2 a Esound na GTK 4, GStreamer a PipeWire) a Monkey Bubble. SANE ovladač pro skener Plustek OpticFilm 8200i se mu zatím nepovedl.
Americké firmy Tesla a SpaceX postaví v texaském Austinu moderní komplex na výrobu čipů pro umělou inteligenci (AI). Součástí projektu s názvem Terafab budou dvě moderní továrny na výrobu čipů – jedna se zaměří na automobily a humanoidní roboty, druhá na datová centra ve vesmíru. Uvedl to generální ředitel těchto firem Elon Musk. Projekt by podle odhadů měl stát 20 miliard USD (zhruba 425 miliard Kč).
Byla vydána nová stabilní verze 6.11 (YouTube) multiplatformního frameworku a GUI toolkitu Qt. Podrobný přehled novinek v poznámkách k vydání.
Ubuntu 26.04 patrně bude ve výchozím nastavení zobrazovat hvězdičky při zadávání hesla příkazu sudo, změna vychází z nové verze sudo-rs. Ta sice zlepší použitelnost systému pro nové uživatele, na které mohlo 'tiché sudo' působit dojmem, že systém 'zamrzl' a nijak nereaguje na stisky kláves, na druhou stranu se jedná o možnou bezpečnostní slabinu, neboť zobrazování hvězdiček v terminálu odhaluje délku hesla. Původní chování příkazu sudo
… více »Projekt systemd schválil kontroverzní pull request, který do JSON záznamů uživatelů přidává nové pole 'birthDate', datum narození, tedy údaj vyžadovaný zákony o ověřování věku v Kalifornii, Coloradu a Brazílii. Jiný pull request, který tuto změnu napravoval, byl správcem projektu Lennartem Poetteringem zamítnut s následujícím zdůvodněním:
… více »Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 163 (pdf).
Eric Lengyel dobrovolně uvolnil jako volné dílo svůj patentovaný algoritmus Slug. Algoritmus vykresluje text a vektorovou grafiku na GPU přímo z dat Bézierových křivek, aniž by využíval texturové mapy obsahující jakékoli předem vypočítané nebo uložené obrázky a počítá přesné pokrytí pro ostré a škálovatelné zobrazení písma, referenční ukázka implementace v HLSL shaderech je na GitHubu. Slug je volným dílem od 17. března letošního
… více »Sashiko (GitHub) je open source automatizovaný systém pro revizi kódu linuxového jádra. Monitoruje veřejné mailing listy a hodnotí navrhované změny pomocí umělé inteligence. Výpočetní zdroje a LLM tokeny poskytuje Google.
Upravená jádra Linuxu obou systémů byla obohacena o rozšířený plánovač přidělení CPU. Ten nyní musí obsluhovat jak jednotlivé procesy, tak i virtuální servery. Systémy pro plánovaní přidělení CPU používají technologii Token-bucket. Každému virtuálnímu serveru je přiděleno pouze tolik systémového času, než spotřebuje přidělené tokeny. Konfiguraci lze měnit i za běhu virtuálního prostředí.
Nastavení plánovače a přidělení CPU využijeme například ve chvíli, kdy server potřebuje při startu vyšší výkon než během svého běhu.
V Linux-VServeru nastavujeme počet tokenů (fill-rate), které jsou doplněny do bucket za časový interval (fill-interval). Dále můžeme nastavit počáteční, minimální a maximální množství tokenů.
Ke správné funkci plánovače musíme sestavit jádro Linux-VServeru s volbou CONFIG_VSERVER_HARDCPU=y.
Linux-VServer rozlišuje mezi „tvrdým“ a „měkkým“ limitem plánovače. Virtuálnímu serveru s tvrdým limitem je po vyčerpání tokenů odebrán procesor. Pokud virtuální server vyčerpá svůj měkký limit a na procesor nečeká jiný virtuální server, je tomuto virtuálnímu serveru nastavena velmi nízká priorita, ale může mu být přidělen procesor. Tvrdý limit nastavíme vložením sched_hard do souboru /etc/vservers/<id_of_vserver>/flags. Pro měkký limit vložíme do stejného souboru sched_prio. Metody nelze kombinovat.
Vlastní nastavení plánovače je uloženo v souboru /etc/vservers/<id_of_vserver>/schedule. Tento soubor má šest řádků:
fill rate – počet tokenů přidělených při jedné obrátcefill interval – délka obrátky v tokenechprio bias – hodnota, která je připočítána k ostatním hodnotámPo vyplnění může tento soubor vypadat například takto:
7 32 500 200 1000 0
Virtuálnímu serveru je přiděleno 7/32 procesoru, na počátku má k dispozici 500 tokenů, jejich minimální stav je 200 a maximální 1000. Poslední hodnotou je prio bias. Je-li hodnota nenulová, přičte se k ostatním hodnotám. Pokud by v příkladu byla rovna 5, kontext by dostal 12/37 procesoru, měl by při startu k dispozici 505, minimálně 205 a maximálně 1005 tokenů.
Nastavení plánovače můžeme změnit i za běhu virtuálního serveru. Použijeme k tomu program vsched z balíku util-vserver. Ten má následující syntaxi:
vsched [--xid <xid>] [--fill-rate <rate>] [--interval <interval>] [--tokens <tokens>] [--tokens-min <tokens>] [--tokens-max <tokens>] [--prio-bias <bias>] [--] [*]
Argumentem volby --xid je kontextové číslo virtuálního stroje. To je možné zjistit pomocí utility vserver-stat. Volby --fill-rate, --interval, --tokens, --tokens-min a --token-max po řadě odpovídají pěti řádkům souboru /etc/vservers/<id_of_vserver>/schedule. Program umožňuje nastavit přidělení procesoru i určité aplikaci virtuálního serveru. Tato aplikace je potom posledním argumentem vsched.
Změnu nastavení plánování virtuálního serveru s kontextovým číslem 1000 provedeme následovně:
# vsched --xid 1000 --fill-rate 30 --interval 100 \ > --tokens 100 --tokens_min 30 --tokens_max 200
Nastavení plánování programu ls ve virtuálním serveru s kontextovým číslem 1000 změníme například takto:
# vsched –-xid 1000 --fill-rate 30 --interval 100 \ > --tokens 100 --tokens_min 30 --tokens_max 200 -- /bin/ls
Změnu nastavení plánovače procesoru můžeme provést pomocí dvou přepínačů utility vzctl.
Pro první možnost použijeme přepínač --cpulimit. Hodnota parametru odpovídá procentu času, po který je procesor přiřazen virtuálnímu serveru a po jehož uplynutí je CPU virtuálnímu serveru odebrán. Odpovídá tedy tvrdému limitu. Chceme-li přidělit virtuálnímu serveru 1919 10 % času procesoru, zadáme příkaz následovně:
# /usr/sbin/vzctl set 1919 --cpulimit 10%
Přidělíme-li virtuálnímu serveru více procesorů (přepínač --cpus utility vzctl s argumentem rovnajícím se počtu přidělených CPU) odpovídá celkový čas CPU násobku počtu procesorů. Například se dvěma procesory má hodnotu 200 %.
Druhou variantu zvolíme přepínačem --cpuunits. Ten určuje garantovanou hodnotu takzvaných CPU jednotek (tokenů), které budou přiděleny virtuálnímu serveru. Argumentem je kladné nenulové číslo předávané plánovači CPU. Vyšší hodnota zaručuje více času procesoru přiděleného virtuálnímu serveru. Po vyčerpání jednotek nemusí být procesor virtuálnímu serveru odebrán, pokud žádný jiný server na procesor nečeká. Maximální hodnota je 500000, minimální 8. V celém systému se čas procesoru přiděluje podle poměru těchto hodnot pro jednotlivé servery. Implicitní hodnota odpovídá 1000 tokenům. Nastavení potom může vypadat následovně:
# /usr/sbin/vzctl set 1919 --cpuunits 1000
Hodnotu přidělených CPU jednotek --cpuunits můžeme nastavit i pro VE0, tedy samotný hostitelský systém. Přepínačem je --ve0cpuunits a jako číslo VE uvedeme 0. Nastavení tohoto argumentu na příliš nízkou hodnotu v poměru k hodnotám jiných virtuálních serverů může způsobit nestabilitu celého operačního systému. Autoři doporučují hodnotu mezi 5 - 10 %. Ta se ukládá do souboru /etc/vz/vz.conf (hodnota VE0CPUUNITS) a o její nastavení se stará skript /etc/init.d/vz.
Stejně jako u jiných nastavení pomocí utility vzctl jsou nastavené hodnoty implicitně dočasné. Pro jejich trvalé uložení uvedeme přepínač --save. Nastavení se ukládá do souboru /etc/sysconfig/vz-scripts/<VPS_ID>.conf (hodnoty CPUUNITS a CPULIMIT).
Aktuální hodnoty CPU jednotek zjistíme utilitou vzcpucheck. Jejím výstupem je hodnota spotřebovaných jednotek všemi virtuálními servery a VE0 a maximální možný „výkon“ systému:
# vzcpucheck Current CPU utilization: 6667 Power of the node: 73072.5
/devOba projekty nabízejí jiné položky přístupné implicitně v adresáři /dev, stejně jako jiné přístupy k vytváření dalších speciálních souborů.
Po instalaci základní kostry systému obsahuje virtuální server následující položky:
| full | log | null | ptmx | pts |
| random | tty | urandom | zero | |
Vytvoření dalších souborů není z virtuálního serveru možné. V kontextech není povolena capability CAP_MKNOD ani pro uživatele root, a samotný Linux-VServer nenabízí nástroj, který by byl obdobou mknod. Speciální soubory lze vytvářet pouze z hostitelského systému.
Viditelnost speciálních souborů se mění podle konfigurace počítače. Obecně jsou vytvořené soubory a adresáře:
| console | core | fd | full |
| initctl | kmem | log | mem |
| null | port | ptmx | pts |
| ram | random | shm | tty |
| urandom | zero |
OpenVZ umožňuje vytváření dalších speciálních souborů prostřednictvím svých utilit.
Zařízení v adresáři /dev ve VPS zpřístupníme z hardwarového uzlu pomocí utility vzctl:
# vzctl set VPS_ID --devnodes \ device:r|w|rw|none --save
Příkaz zpřístupní zařízení device (ve tvaru například /dev/hda) s přístupovými právy (r – čtení, w – zápis, rw – čtení a zápis, none – žádný přístup) s trvalým uložením změn v konfiguraci (parametr --save).
Další možností je povolení capability CAP_MKNOD ve VPS z hostitelského serveru:
# vzctl set VPS_ID --capability CAP_MKNOD:on --save
Poté je možné ve VPS vytvářet speciální soubory pomocí mknod. Tato volba však může být možnou bezpečnostní slabinou.
V příštím díle se zaměříme na správu výpočetních zdrojů jako je paměť RAM, počet otevřených souborů atd.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
schedule, ale adresář tohoto jména obsahuje soubory s parametry plánovače - fill-rate interval tokens tokens-max tokens-min.
Tak jsem to asi špatně pochopil a můj závěr je špatný. Co jsem si prostudoval dokumentaci, tak to vypadá tak, že OpenVZ prostě přiděluje každému VPS definovaný počet cpuunits. Po jejich vyčerpání přejde k dalšímu VPS a tak pořád dokola. Cpuunits tedy definují v jakém poměru se na dané VPS dostane čas na procesoru vzhledem k ostatním VPS. V mém případě tedy hostitel a 3 reálné VPS dostávají stejný díl času na procesoru, kdežto zkušebnímu VPS když se dostane na řadu bude přidělena pouze 8/1000 času (oproti ostatním). A když je "Power of the node: 186725", každé z VPS se dostane na řadu 186725/4008 krát za sekundu (cca 46Hz). Jinak řečeno (v mém případě): VE0 jede 5,35ms, pak se systém přepne na VPS1 a to jede 5,35ms, pak na VPS2 opět 5,35ms, pak na VPS3 zase 5,35ms a pak na zkušební VPS a to po dobu 0,04ms. A pak zase VE0 5,35ms .. .
Nevíte o nějakém nástroji, který by nějak souhrnně ukázal, jak je procesor využíván v rámci jednotlivých VPS ? Jde mi o odladění potřebných cpuunits pro jednotlivé VPS. V rámci kontextů je dostupná statistika v /proc/loadavg. Navíc se nějaké užitečné informace dají najít i v /proc/vz/vestat. Ale k tomu by se muselo něco bastlit, šlo mi o to, jestli jsem nepřehlédnul nějaký použitelný nástroj.