abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 18:44 | Zajímavý článek

    Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).

    Ladislav Hagara | Komentářů: 0
    včera 16:11 | Nová verze

    Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.

    Ladislav Hagara | Komentářů: 0
    včera 15:55 | Komunita

    Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.

    Ladislav Hagara | Komentářů: 2
    16.7. 21:22 | IT novinky

    Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.

    Ladislav Hagara | Komentářů: 13
    16.7. 16:22 | IT novinky

    Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.

    Ladislav Hagara | Komentářů: 24
    16.7. 15:33 | Upozornění

    Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapyAI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.

    bindiff | Komentářů: 8
    16.7. 13:33 | Bezpečnostní upozornění

    Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).

    Ladislav Hagara | Komentářů: 5
    16.7. 00:11 | Nová verze

    Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.

    Ladislav Hagara | Komentářů: 0
    15.7. 20:44 | IT novinky

    Americký výrobce čipů Nvidia získal od vlády prezidenta Donalda Trumpa souhlas s prodejem svých pokročilých počítačových čipů používaných k vývoji umělé inteligence (AI) H20 do Číny. Prodej těchto čipů speciálně upravených pro čínský trh by tak mohl být brzy obnoven, uvedla firma na svém blogu. Americká vláda zakázala prodej v dubnu, v době eskalace obchodního sporu mezi oběma zeměmi. Tehdy to zdůvodnila obavami, že by čipy mohla využívat čínská armáda.

    Ladislav Hagara | Komentářů: 10
    15.7. 17:22 | Nová verze

    3D software Blender byl vydán ve verzi 4.5 s prodlouženou podporou. Podrobnosti v poznámkách k vydání. Videopředstavení na YouTube.

    Ladislav Hagara | Komentářů: 0
    Jaký je váš oblíbený skriptovací jazyk?
     (59%)
     (27%)
     (7%)
     (3%)
     (0%)
     (1%)
     (4%)
    Celkem 409 hlasů
     Komentářů: 16, poslední 8.6. 21:05
    Rozcestník

    Dotaz: Zobrazení zátěže systému

    11.10.2013 19:48 lertimir | skóre: 64 | blog: Par_slov
    Zobrazení zátěže systému
    Přečteno: 745×
    Příloha:
    Můžete mi pomoci porozumět, jak a co vlastně měří zátěž? Posílám snapshot části obrazovky, kde je odleva (KDE Plasma witget)/(KDE Monitor systému)/(htop v shelu). To co je zcela jiné je, že monitor systému má naprostou většinu času jedno jádro na 100%, Plasma witget se někde plácá ve střední zátěži a htop nikdy neoznámil více než 10% zátěže na jádro. To co probíhá a je hlavní zátěží je přenos velkého souboru obrazu virtuálního stroje vdmk přes sshfs. celkem chápu, že šifrování ho může zatížit v jednom jádru dost, ale proč jsou odpovědi tak různé a komu se tedy dá věřit?

    Řešení dotazu:


    Odpovědi

    Jendа avatar 12.10.2013 10:24 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: Zobrazení zátěže systému
    Věřil bych ukazateli Load average.
    12.10.2013 12:17 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Zobrazení zátěže systému
    Co je Load Average se tady už řešilo před 3 roky. Je to něco zcela jiného než zatížení CPU, moje otázka je spíš, odkud to ty měřáky kruci berou, když dostávají tak různý výsledky.
    12.10.2013 16:46 pavel
    Rozbalit Rozbalit vše Re: Zobrazení zátěže systému
    Něco podobného jsem řešil zde, jak se to dělá je třeba tady.

    Krátce - údaje berou a počítají se z /proc/stat a /proc/pid/stat.

    Výpočet by byl jednoduchý, kdyby bylo v PC jen jedno jádro procesoru.

    V případě více jader je možné použít buď průměrnou hodnotu nebo počítat zatížení programu pro každé jádro zvlášť.

    Sranda je, pokud program používá více jader, a to nerovnoměrně v závislosti na čase. Jaká potom bude zátěž procesoru? Pokud budeš mít čtyři jádra a program se "kousne" a začne zatěžovat jedno jádro na 100%, průměrná zátěž bude 25%. Je tedy ještě třeba zohlednit při výpočtu zatížení počet jader, které proces využívá...
    12.10.2013 17:03 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Zobrazení zátěže systému
    Jenže všechny tři měřiče, které tam mám zobrazeny tvrdí, že měří zátěž pro každé jádro zvlášť. Ne že průměrují zátěž na celý procesor. Proč má každý měřič zátěž, ale úplně jinou.
    12.10.2013 20:16 pavele
    Rozbalit Rozbalit vše Re: Zobrazení zátěže systému
    Protože v každém jednotlivém jádru běží jiné procesy, musí mít každé jednotlivé jádro jinou zátěž. Pokud budeš kompilovat a zatížíš první jádro na 90%, bude se ti zobrazovat 90% zatížení na prvním jádru a jiné zatížení na dalších jádrech.
    13.10.2013 00:59 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Zobrazení zátěže systému
    No myslím, že jste si úvodní otázku nepřečetl a na screenshot se nepodíval. Otázka není proč mají jádra jiné zátěže, ale proč Applet v Plazmě, Monitor systému v KDE, a htop uvádí pro jednotlivá jádra naprosto jiné údaje o záteži. A samozřejmě takové, které nejdou vysvětlit libovolným přečíslováním jader.
    13.10.2013 10:02 pavele
    Rozbalit Rozbalit vše Re: Zobrazení zátěže systému
    Htop bere prumer za nejaky cas, Plazma bere prumer za nejaky cas a Monitor systemu bere prumer za nejaky cas...
    13.10.2013 10:12 potato
    Rozbalit Rozbalit vše Re: Zobrazení zátěže systému
    Nastav všechny tři, aby při výpočtu loadu průměrovaly za nějaký dlouhý čas, např. 5 s. Stále se výsledky podstatně liší?
    14.10.2013 21:11 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Zobrazení zátěže systému
    stejně to sice nastavit nejde, ale když se časy přibližují je to také bližší.
    Řešení 2× (rADOn, Šangala)
    16.10.2013 14:20 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: Zobrazení zátěže systému

    Měřáky se berou z /proc/stat.

    Zátěž není spojitá veličina, natož spojitě diferencovatelná. V daném časovém okamžiku je u jednoho procesoru vždy buď 0% nebo 100%. Tedy celkové zatížení systému například se 4 procesory je v daném okamžiku vždy přesně 0%, 25%, 50%, 75% nebo 100%.

    Protože diferenciálně krátký okamžik je celkem nezajímavý a o ničem příliš nevypovídá, všechny utility zobrazují průměrnou zátěž za delší dobu. Jednoduše řečeno, odhadne se doba, kterou procesory strávily prací a kterou strávily nicneděláním. Zátěž je pak doba strávená prací během určitého časového intervalu dělená délkou tohoto intervalu. To například znamená, že pokud čtyři procesory strávily během jedné vteřiny dohromady 150% času prací, celková zátěž systému bude 150% / 400%, tedy 37,5%. Například mohly 3 z nich pracovat každý 50% času, případně všechny čtyři 37,5% času nebo třeba jeden na 100%, dva další na 25% a ten poslední během dané vteřiny nepracoval.

    Odhad času, který procesory tráví prací, se dá provádět dvěma způsoby.

    Primitivní způsob, který s několika modifikacemi používá Linux, využívá pravidelný tik hodin ke kontrole stavu procesorů. Když nachytá procesor při nicnedělání, zaznamená to. Když najde na procesoru běžící vlákno, přidá celý hodinový interval do časového účetnictví daného vlákna. Poté, co byl pravidelný hodinový tik odstraněn, bylo samozřejmě nezbytné postarat se o správné počítání času i na procesorech, které si dlouhodobě žádný timer nenaplánují. Nicméně hodnoty v souboru /proc/stat stále předstírají, jako by každý procesor zpracovával 100 tiků za vteřinu a u každého tiku zaznamenával aktuální stav. Odhad celkové zátěže je na Linuxu (nepřesně řečeno) tím přesnější, čím víc je procesorů, tedy například na 32-procesorovém stroji přibude do první řádky /proc/stat celkově 3200 tiků každou vteřinu, zatímco na dvouprocesoru pouze 200 tiků.

    Tento jednoduchý způsob má samozřejmě své chyby, protože vlákno ve skutečnosti může běžet po dobu mnohem kratší než doba mezi tiky hodin, ať už kvůli vypršení plánovacího kvanta, kvůli migraci na jiný procesor nebo kvůli uspání z velmi široké škály možných důvodů. Idea je ovšem taková, že i přes drobné nepřesnosti bude v průměru a z dlouhodobého hlediska účtování času korektní, tedy pravděpodobnost výrazných systematických odchylek je z pohledu statistiky velmi malá.

    Přesnější, ale náročnější způsob účtování času má například Solaris (Illumos, OpenIndiana) a AIX. V těchto systémech se při každé změně stavu procesoru explicitně přečte vhodný nanosekundový čas (tj. časomíra s velkým rozlišením, kterou většina moderních platforem implementuje) a na základě tohoto času se pak přesně počítá, jak dlouho byl procesor v userspace, jak dlouho byl v systému, jak dlouho obsluhoval interrupty, jak dlouho provozoval virtuální stroje — každý interval mezi dvěma sousedními změnami stavu se dá zaúčtovat velmi přesně. V Solarisu se to jmenuje microstate accounting. Tohle ovšem s sebou nese vysokou daň v podobě doby potřebné pro přečtení přesného času. Jakkoliv se to může zdát překvapivé, čtení přesného času je drahé a odpovídá desítkám až stovkám aritmetických instrukcí. (Důvodem je, že se zpravidla jedná o čítač tiků procesoru, který musí fungovat jako pipeline, protože inkrementace čítače se obecně nedá realizovat v jednom tiku. Čtení čítače vyžaduje čekání na dosažení definovaného a čitelného stavu a navíc různá opatření, která kompenzují vliv čtení na rychlost postupu čítače.) Jestliže se tedy například Linux chlubí, že přerušení dělí od příslušného handleru pouze 18 instrukcí (což se člověk dočte ve slavné zprávě „Have you ever kissed a girl?“; dnes už to bude zcela jistě úplně jinak), přidání přesného časovače by mohlo způsobit za jistých okolností zhoršení výkonnosti. (Dlužno připomenout například registrová okénka na platformě SPARC, o jejichž správu a přepínání se musí postarat kernel, když na to přijde, a může na to přijít velmi často.) (Jakmile ovšem musí handler přerušení sáhnout kamkoliv do paměti, která není zrovna v lokální cache na procesoru, cena takového přístupu odpovídá stovkám až tisícům aritmetických instrukcí, takže zůstává otázkou, jak moc velký negativní vliv vlastně microstate accounting má.)

    Ať už je způsob měření času jakýkoliv, vždy nakonec dojde na průměrování přes delší časový úsek. Právě volba tohoto delšího časového úseku vede k různým výsledkům pro různé utility. Například průměr za dobu jedné minuty by jistě všechny utility vypočítaly téměř stejně. Jenže tento průměr příliš nevypovídá o změnách zátěže během té minuty. Naopak průměr za sto milisekund velmi rychle (z lidského hlediska) reaguje na změny zátěže, ale potíž je v tom, že je extrémně nestabilní a těžko se z něj (pouhým okem) odhaduje nějaký průměr nebo trend.

    Monitorovací utilita v KDE (ksysguard) implicitně vykresluje zátěž pro každý procesor zvlášť. Ta bude samozřejmě mnohem méně stabilní než celkový průměr. Často bude některý z procesorů pravidelně skákat na 100%, protože například zrovna zpracovává data související s šifrováním filesystémů, SSH, VPN, dekódováním hudby a tak podobně, zatímco ostatní procesory budou častěji idle. Tedy to, co vidíš na tom screenshotu, je naprosto normální. V ksysguard si lze u každého sešitu nastavit interval měření, tedy ten interval, přes který se zátěž průměruje. Pak bude vidět, že dlouhý interval produkuje pěkný hladký průběh, ale neukazuje rychlé fluktuace zátěže, zatímco pro krátký interval platí přesný opak. Je méně stabilní, ale změny zátěže (i krátkodobé) jsou hned vidět. Tedy je to věc jakéhosi kompromisu.

    Lepší způsob výpočtu zátěže (je-li třeba odhad zátěže aktualizovat často a nepravidelně) je založený na exponenciálním klouzavém průměru, jehož vzorec se trochu poupraví pro „práci se zlomky“ (extrémně vágně řečeno). Výhodou takového postupu je absence pravidelného intervalu, který by přinášel nestabilitu, a možnost aktualizovat odhad zátěže libovolně často. Nicméně i klouzavý průměr potřebuje předem znát konstantu, která představuje kompromis mezi rychlou odezvou na změnu zátěže a stabilitou hlášených hodnot. Nepřítomnost předělů mezi časovými intervaly s sebou ovšem nese jistou daň v podobě malého rezidua z minulosti, bez kterého by ovšem odhad neměl „hladší“ průběh. Pokud vím, současné utility pro měření zátěže klouzavé průměry nepoužívají. Použil jsem tuto techniku v projektech, u kterých byl hladký a zároveň přijatelně přesný odhad zátěže velmi důležitý a kde nebylo žádoucí měřit zátěž v předem daných pravidelných intervalech.

    Sečteno a podtrženo, zátěž není žádná přesná a spojitá veličina; je to něco, co se dá mnoha různými způsoby definovat, mnoha různými způsoby měřit a odhadovat. Proto dává každý měřák jiné hodnoty.

    rADOn avatar 16.10.2013 17:34 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Zobrazení zátěže systému
    Tak tomu říkám Odpověď.
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    17.10.2013 01:13 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Zobrazení zátěže systému
    Díky.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.