Hlavní navigace

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...

Článek je starý, nové názory již nelze přidávat.

  • 25. 9. 2014 4:01

    coder

    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

  • 25. 9. 2014 9:48

    lqw (neregistrovaný) 88.103.8.---

    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.

  • 26. 9. 2014 0:09

    coder

    Děkuji za vysvětlení. Je pěkné, že když selže redakce, najde se někdo v diskuzi, který tématu rozumí.

  • 25. 9. 2014 14:29

    Seph (neregistrovaný) 195.113.180.---

    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.

  • 26. 9. 2014 13:56

    Pavel Tišnovský

    Ajo, 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 :)