Bylo vydáno Ubuntu 20.04.6 LTS, tj. šesté opravné vydání Ubuntu 20.04 LTS s kódovým názvem Focal Fossa. Přehled novinek v poznámkách k vydání a v přehledu změn.
Připojit neznámý USB flash disk do počítače může být nebezpečné. Dokonce může jít i o život. Někdo rozeslal ekvádorským novinářům USB flash disky, které po připojení do počítače explodují [BBC, Twitter].
Byla vydána nová verze 7.4 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu.
Byla vydána verze 11.0 s kódovým jménem Aramo linuxové distribuce Trisquel GNU/Linux. Založena je na Ubuntu 22.04 LTS a podporována bude do roku 2027. Trisquel patří mezi svobodné distribuce doporučované Nadací pro svobodný software (FSF).
Mozilla založila startup Mozilla.ai a vložila do něj 30 milionů dolarů. Cílem je vývoj důvěryhodné, nezávislé a open source AI.
Po půl roce vývoje od vydání verze 43 bylo vydáno GNOME 44 s kódovým názvem Kuala Lumpur. Přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře. Krátké představení na YouTube.
Letošní Turingovou cenu (2022 ACM A.M. Turing Award) získal Bob Metcalfe za vynalezení, standardizaci a komercializaci Ethernetu.
Svobodná webová platforma pro sdílení a přehrávání videí PeerTube (Wikipedie) byla vydána ve verzi 5.1. Přehled novinek i s náhledy v oficiálním oznámení a na GitHubu.
Byla vydána Java 20 / JDK 20. Nových vlastností (JEP - JDK Enhancement Proposal) je 7. Nová Java / JDK vychází každých 6 měsíců. LTS verze je 17.
Google spustil konverzační AI Bard. Vyzkoušet lze zatím pouze ve Spojených státech a Spojeném království. Více v Bard FAQ.
Musím se předem přiznat, že s monitorováním RAM a disku moc zkušeností nemám, ale o zatížení CPU něco vím. Takže se ve své odpovědi omezím na CPU a snad objasním aspoň z malé části, jak se to dá monitorovat.
Jednoduchá odpověď je „v /proc/[pid]/stat
“, ale zkusím to trochu rozvést. Tady je jednoduchý load monitor, který se dá rovnou spustit a vyzkoušet:
( # Vyrobíme nějaký proces k monitorování. (for ((;;)); do stress -c 1 -t 1; sleep 1; done >/dev/null;) & # Poznamenáme si, který proces to byl a že ho máme zabít. trap 'kill "$PID"' EXIT PID="$!" # Naprogramujeme výpočet vytížení procesoru v awk. AWK_SCRIPT=' BEGIN { getconf = "getconf CLK_TCK" getconf | getline TCK close(getconf) } { uspace = $14 kernel = $15 kids_uspace = $16 kids_kernel = $17 kvm_uspace = $43 kvm_kernel = $44 total_ticks = uspace + kernel + kids_uspace + kids_kernel kvm_ticks = kvm_uspace + kvm_kernel } NR > 1 { print (100 * (total_ticks - last_total_ticks) / TCK) "% total,", (100 * (kvm_ticks - last_kvm_ticks) / TCK) "% in KVM" } { last_total_ticks = total_ticks last_kvm_ticks = kvm_ticks }' # Každou sekundu načteme statistiky vytížení procesoru do awk. for ((i = 0; i < 20; ++i)); do cat "/proc/${PID}/stat" sleep 1 done | awk "$AWK_SCRIPT" )Co tohle dělá, v kostce:
stress
uje jeden procesor na 100%. Poznamená si to PID toho subshellu (nikoliv však PID stress
u ani PID jednoho dalšího potomka, kterého stress
zplodí).awk
čte informace o tom, kolik tiků příslušný proces spotřeboval od minulého čtení (před sekundou) a na základě toho ukazuje vytížení procesoru v procentech. Protože stress
nic nevirtualizuje, bude druhá vypisovaná hodnota v tomto případě vždycky nula. Protože děti toho shellu, jehož PID sledujeme, vždy jednu sekundu stress
ují a jednu sekundu spí, právě tomu bude odpovídat první vypisovaná hodnota. Co znamenají které hodnoty v daném /proc/[pid]/stat
souboru nebo v globálním /proc/stat
souboru, se dá snadno nalézt v man 5 proc
.stress -c 3
, bude chvílemi ukazovat například vytížení 300%. To je zcela normální a očekávaný jev. Aby člověk získal hodnotu od 0 do 100%, musí to normalizovat třeba počtem virtuálních procesorů toho KVM.Ke KVM musím dodat, že se mi teď zrovna nechce logovat na některý z mých KVM serverů a tudíž jsem hodnoty typu kvm_ticks
ani náznakem neotestoval. Takže tam můžu mít celkem značnou spoustu chyb jak ve sloupcích, které dané hodnoty obsahují, tak i v jejich interpretaci. To už si musíš dořešit. Každopádně manuálová stránka říká, že hodnoty pro virtualizaci, tedy
kvm_uspace
a kvm_kernel
, jsou už zahrnuté v hodnotách pro děti daného procesu (kids_uspace
a kids_kernel
), takže není radno všech šest políček sečíst. První dvě plně stačí pro procesy bez dětí, druhá dvě je třeba přičíst, když je to (jako v tomto případě) nějaký shell nebo stress
s potomky a ta poslední dvě jsou asi tou slibovanou třetinou odpovědi na tvou otázku — udávají, kolik se strávilo virtualizací. Ovšem pokud někomu počítáš vytížení jeho KVM stroje, podle mě bys měl počítat všechny userspace
+ kernel
+ kvm_uspace
+ kvm_kernel
tiky daného KVM procesu, protože to, co proces virtuálního stroje dělá mimo virtuální stroj (údržbu kdovíčeho, mapování paměti, přístupy k disku a k virtuálním zařízením všeho druhu atd. atp.), by se rozhodně mělo taky „účtovat“ tomu klientovi. Děje se to přece kvůli podpoře běhu toho příslušného virtuálního stroje a že při tom procesor není zrovna ve virtualizačním režimu a nevykonává přímo instrukce toho KVM, to není až tak rozhodující.
Tiskni
Sdílej: