Vlákno názorů k článku Dlaždice trochu jinak: rozšíření správce Awesome od coder - Autore, pořád mi to vrtá hlavou. Chyba v...
-
Autore, pořád mi to vrtá hlavou. Chyba v tomto případu bude odečítat spotřebu paměti z xmobaru.
Jako základ by bylo vhodné patřičně zveřejnit Vaši konfiguraci ~/.xmobarrc, bohužel ta zveřejněná v článku z 4. 9. 2014 je nefunkční.
Uvádíte:
, Run Memory ["-t","Mem: %"] 10
což nefunguje. Podle dokumentace argument --template / -t bere následující proměnné: total, free, buffer, cache, rest, used, usedratio, usedbar, usedvbar, usedipat, freeratio, freebar, freevbar, freeipat uzavřené z obou stran špičatými závorkami.
Vámi uváděná konfigurace žádné takové neobsahuje, tudíž je nefunkční.
Budu tedy spekulovat, že jste si vybral tisknout proměnnou <used> přestože máte v template přichystané znaménko procenta, které by nasvědčovalo použití <usedratio> které používat samostatně by bylo poněkud neohrabané, protože by byl nutný přepočet na MB. Takže <used>.
No a v tomto tkví jádro celého problému. Nemám chuť hledat, co přesně <used> vyjadřuje ale rozhodně to není ta spotřeba paměti, kterou nám běžně ukazuje např. htop, lxtask, gnome-system-monitor a jim podobné nástroje.
Když mi htop, lxtask a gnome-system-monitor ukazují aktuální celkovou spotřebu paměti 787 MB, xmobar ukazuje 1 002 MB. Tedy o více než 200 MB více.
Když jsem rok a půl používal Xmonad s xmobarem, měl jsem nakonfigurováno pouze <usedration>. Procenta pro orientaci mi stačily, přesné číslo na můj vkus příliš rozptyluje, takže jsem si této nesrovnalosti všiml až díky vašemu seriálu o dlaždicích tady na Rootu.
Takže problém odhalen. To Vás však autore neomlouvá z laxního přístupu k měření spotřeby paměti. I když s porovnáním spotřeby zároveň alibisticky uvádíte svoji metodu měření, 99% čtenářů nemůže tušit, že naměřená čísla nemůže porovnávat, protože nevyjadřují to samé. Příště tedy raději htop.
Přikládám ještě screenshot http://imgur.com/yWtlopy -
lqw (neregistrovaný)
Autor byl uz na tento blud opakovane upozornovan a ze opisuje cisla jejichz vyznamu zjevne vubec nerozumi. Misto aby se chytil za nos a omyl napravil, tak dal pokracuje v demonstraci sve nekompetentnosti. To uz hranici s ignoranstvim.
Memory plugin z xmobaru (pominu ze v clanku byla uvedena nefunkcni konfigurace) skutecnou spotrebu pameti procesu neumi a nikdy neumel a slouzi jen k hrubemu zobrazeni celkove obsazene + rezervovane pameti, tzn. vcetne virtualni o ktere autor evidentne netusi co znamena. Upozornoval jsem na to, ze timhle skutecnou spotrebu nelze merit a ze xmobar k tomu ucelu nabizi monitor TopMem, ale je to marny, je to marny …
Jen pro dokresleni, nainstaloval jsem nejaktualnejsi verzi subtle, awesome 3.5.5, xmonad 0.11 a xmobar 0.21 a uvadim realne obsazeni pameti (RSS, swap vypnuty) a take X (RSS, vliv alokace zdroju spustenym WM):- subtle 14982 (14,6 MiB), X 34112 (33,1 MiB)
- awesome 13548 (13,2 MiB), X 31816 (31,1 MiB)
- xmonad 8320 (8,1 MiB), xmobar 16616 (16,2 MiB), X 26872 (26,2 MiB)
Testovano s vychozi konfiguraci.
p.s. Pro příště: pokud mi u měření srovnatelných jevů vychází diametrálně odlišné číslo, s velkou pravděpodobností je někde chyba a začnu pátrat po příčině. To je ale elementární logika, na kterou stačí selský rozum.
-
Seph (neregistrovaný)
Problém je asi s velikostí alokované virtuální paměti procesu. Já XMonad taky používám a top mi ukazuje VSZ přes 200 MB a RSS kolem 10 MB. Garbage collector haskellu zřejmě rezervuje víc paměti než je běžný u programů napsaných v cécčku s ruční správou haldy. Faktem je jak píše předřečník, že fyzicky obsazená paměť včetně swapu se plus mínus drží kolem těch 10 mega i když běží třeba měsíc v kuse.
-
Pavel TišnovskýZlatý podporovatelAjo, to dava smysl, ta velikost virtualni pameti by se nemela pocitat nikde, to jsou proste skutecne "virtualni" hodnoty, takto dela prealokaci taky JVM a nicemu to nevadi, i kdyz soucet velikosti virtualnich oblasti presahuje kapacitu RAM a neswapuje se :)
