Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
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
/dev
Oba 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.