Jak vám kyne linux?

30.9.2007 01:49 | Přečteno: 3559× | Linux | | poslední úprava: 30.9.2007 08:48

Předně bych se chtěl omluvit za trochu bulvární nadpis. Řeč nebude ani tak o kynutí jádra nýbrž o postupném bobtnání samotných aplikací.

Kde je jádro pudla?

Víte co popřát programátorovi píšicímu v jazyce bez garbage collectoru na dobrou noc aby měl zaručeně noční můru? Ať se mu zdá o memory leaku. Je to jeden z problémů, který se v rozsáhlém projektu velmi obtížně ladí. A to i přes použití nástrojů jako efence. Podle průzkumu v mém okolí je to nejčastější pčípad aplikace Ostrichova algoritmu. Zřejmě tomu bude podobně i jinde.

Trocha teorie

Opravdu jen trošku, ikdyž toto téma by si zasloužilo několik článků. Snad někdy příště. Předně je třeba uvědomit si, že všechny běřně používané utility čerpající z /proc/PID/statm a status, tedy v podstatě vše od ps,top až po gtop a ksysguard ukazují nepřesné až irelevantní údaje. Slíbil jsem, že do podrobnosti se pouštět nebudu takže jen zkratkovitě.

Hodnota VIRT z top nebo VSZ z ps nevypovída v praxi vůbec o ničem. Jedná se pouze o velikost virtuálního adresního prostoru namapovaného daným procesem. Stačí, že aplikace provede mmap velkého souboru, nebo naalokuje velkou oblast paměti, na kterou po dobu běhu programu nešáhne (vzhledem k tomu, jak linux přiděluje paměť je to "legální") a hodnota ihned vyletí do astrálních rozměrů.

RSS má o něco větší vypovídací hodnotu. Hlavním problémem je to, že se zde nezapočítává odsvapovaná paměť a naopak sdílená paměť se započítává do všech procesů. První problém lze snadno vyřešit: swapoff -a. Druhý je mnohem náročnější a současně ho nejde zanedbat. Takto nasdílená paměť nezřídka tvoří podstatnou část RSS zejména gnome a KDE aplikací. Nemůžeme ani odečíst od RSS hodnotu SHARED. tím bychom se dopustili opačné chyby. Aplikace používající jako jediná velkou knihovnu (které se stejně objeví v SHARED) by tímto byla "ošizená" o tuto paměť. Je potřeba provést analýzu namapované pamšti blok po bloku na základě /proc/PID/smaps, jak to delá např prelovský skript smem. Ještě lepsí je provést per-page analýzu, což dělá exmap s pomocí modulu zavedeného do jádra. Následně můžeme sdílenou pamět spravedlivým dílem rozpořítat mezi všechny aplikace, které ji používají.

A nakonec problém nejzákeřnější. Co když nejaká aplikace klade kukaččí vejce do jiné? Zní to sice divně ale v linuxu je to běžné. Aplikace s GUI např. využívají zdroje Xserveru. V tomto případě je řešením utilitka xrestop ale pro každý takový případ musí být jiná utilita, žádné obecné řešení existovat nemůže. Pojďme dále. Co když aplikace používá pro rendering textu X a přinutí ho tím nahrát příslušný font a vyrenderovat příslušné řezy do paměti. Téměř nezměřitelná věc. Co když aplikace používá jako datový backend třeba mysql (mythtv, amarok takto umí pracovat, ...). Má se v této situaci připočítat zdroje obsazene přes mysql k tomu programu? Rozpočítat mezi programy? Co když kvůli jednomu mysql naalokuje více paměti než kvůli druhému. To se prakticky nedá změřit.

Doufám, že jsem alespoň nastínil problematiku, a až příště spustíte top nebo htop kvůli zjištění která aplikace to žere tolik paměti, budete vědět na co si dát pozor. Abych vás uklidnil- aplikace čerpající z /proc/meminfo a informující o volné paměti tedy free, top a nespočetná grafická udělátka jako gkrellm taktéž neukazují zcela korektní hodnoty... Ale to je zase na jiný článek.

Největší bumbrlíčci

Vyzbrojení jemným nástinem teorie se pojďme podívat na to, jak může vypadat obsazení paměti na desktopu. Jako pokusný králík poslouží můj počítač s 4GiB paměti.

free
             total       used       free     shared    buffers     cached
Mem:       4050512    4023220      27292          0       6588     619052
-/+ buffers/cache:    3397580     652932
Swap:            0          0          0

swap je vypnutý abychom mohli čerpat ze sloupce RSS orientační hodnoty. Podíváme se ještě na výstup rfree abychom zíkali lepší přehled kolik zabírá slab.

rfree
             total       used       free       slab    buffers     cached
Mem:       4050512    4010180      40332      53968       4264     609656
-/+ buffers/cache:    3342292     677244      30976
Swap:            0          0          0

O utilitce rfree jesem psal v jiném blogpostu.

3.3GB "natvrdo" obsazené paměti, pouhých 600MB zůstalo na diskovou cache. Co tak nenažraného mam spuštěno ptáte se?

ps -eo pid,rss,comm,start_time --sort=-rss
  PID   RSS COMMAND         START
13290 989792 kaffeine       Sep23
 3028 945768 opera          Sep20
31172 536832 beryl          Sep12
 5046 232972 emerald        Sep06

Při takových velikostech nemusíme řešit sdílenou paměť. kaffeine 0.8.5 po 6 dnech používáni nabobtnalo na reálnou velikost téměř jednoho gigabajtu. Je schované v trayi, nic aktuálně nepřehrává a playlist je prázdný.

Opera 9.23 se statickou qt narostla za 9 dnů na 945MiB přičemž paměťová cache je nastavená na 64MB a otevřených je 9 tabů. Jedinym pluginem je flash player, který je ovšem out-of-process v operapluginwrapper.

Beryl, 17 dnů, 536MiB. Relativně experimentální věc. Kyne rychlostí 22MB/den. Dekorátor emerald taktéž. Kyne rychlostí 8MB/den.

Výše zmíněné programy (nebo jimi používané knihovny) leakují paměť. Postupně prostě rostou nedbaje na mnořství volné paměti. Není to tedy žádná cache. Navíc obrovské části této paměti podle smaps nejsou využívány. Po hibernaci zustanou ve svapu po věky věkoucí dokud aplikace nespadne.

ani Xorg 7.2 neudří moč

  PID   RSS COMMAND         START
 4850 317320 X              Sep06

xrestop - Display: localhost:0
          Monitoring 35 clients. XErrors: 0
          Pixmaps:   75050K total, Other:    1382K total, All:   76433K total

res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
2000000  2253   43    1  125  206    19908K     59K  19968K  5046 emerald
1200000    71   52    5 19685 12342    11358K    297K  11655K  4955 KDE Desktop
0600000   226   32   12 1255  510     7204K     30K   7234K  3028 Opera
1000000    26    1    1   18 9871     6653K    232K   6886K   ?   beryl
3000000   158   87    9 14065 9160     5739K    229K   5968K  5532 sim
3400000   488  120    5 1456  972     4512K     42K   4554K 10729 Amarok
2e00000   217   31    1   71   75     4309K      8K   4317K  7163 NastavenĂ­ programu
4c00000   317   91    5 11043 6928     3002K    176K   3179K 13290 Kaffeine Player
...

Zde vidíme kukaččí vejce s celkovou velikostí 75MB. Na celkové velikosti X se podílí nezanedbatelně. Současně je třeba říct, že X nezávisle na této hodnotě taktéž kyne. Podle smaps a podle velikosti která se nahraje po hibernaci soudím, že se využívá cca 120MB paměti (tato hodnota se s časem téměř nemění). Celkově odhaduji "kynutí" na cca 8M/den.

ostatní programy

  PID   RSS COMMAND         START
27574 55476 python          Sep15
10729 36916 amarokapp       Sep21
 4957 21428 kicker          Sep06
 7163 23896 audacious       Sep15
 5104 21020 konsole         Sep06
 5532 20424 sim             Sep07

python, ve kterém běží screenlety (všeho všudy dva) roste rychlostí 2M/den. Amarok při intenzivním používaní si vezme 10MB/den. Já ho ovšem pouštím málokdy. Std. KDE aplikace a sim nekynou neebo jen zanedbatelně. Podívejme se, jak je na tom konsole z hlediska sdílené paměti.

perl ./smem.pl 5104
VMSIZE:      98764 kb
RSS:         21428 kb total
              4712 kb shared
              5660 kb private clean
             11056 kb private dirty

Tato aplikace s 5 otevřenými taby a 1000 řádkovou historií zabírá 21428kB z čehož 4712kB se sdílí.

Co z toho?

Jak vidíte tak nemám spuštěno nic speciálního. Žádné vývojové prostředí. Žádná megaaplikace v javě. Neběží žádný virtuální stroj (dva běžně spuštěné jsem musel vypnout aby proběhl swapoff). Jediná odchylka oproti průměru je, že mam vše spuštěné dlouho. A to je pro odhalování leakujících programů nejlepší. Na autory opery a kaffeine je třeba bez pochyby tlačit aby tuto situaci řešili. Pokud máte velký swap tak je to skoro jedno jelikož leaknutá paměť se vetšinou odswapuje a už nepřekáží. Kdo ještě říká, že 4GiB RAM na desktopu jsou k ničemu?

       

Komentáře

[Luk]

Program nemusí doopravdy leakovat, aby "kynul". Často programy alokují paměť a neuvolňují ji, protože by ji mohly potřebovat. Sice neznám detaily fungování heap managera v glibc, ale podle toho, jak vídám programy volat brk(), "hystereze" je hodně velká. Souvisí to jistě i s fragmentací heapu, byť se ji správce určitě snaží omezit.

[David Watzke]

Často programy alokují paměť a neuvolňují ji, protože by ji mohly potřebovat.

Ale co jim brání ji uvolnit a alokovat až zase bude potřeba?

[D-Evil]

Nebrání jim nic, ale zajišťujou si tak zřejmě plynulej běh bez velký potřeby swapovaní. Myslim, že u desktopovejch aplikací to neni špatný chování. Přijde mi užitečnější mít plynule pracující aplikaci a swapovat při spouštění něčeho novýho, než naopak.

[Luk]

To se swapováním vůbec nesouvisí. Aby jádro stránku neodswapovalo, musela by být zamčená v paměti. Jinak ji může odswapovat, jakmile jen stránka neaktivní. Naopak, kdyby ji aplikace uvolnila, žádné swapování není potřeba.

Jde o něco jiného. Když má heap manager dostatek paměti, může ji přidělovat rovnou, aniž by žádal jádro. Tím spíš, že když paměť uvolní a pak ji u jádra znovu alokuje, při prvním zápisu do každé stránky dojde znovu k výpadku, jehož obsloužení chvilku trvá.

Důležité proto je, aby měl proces vždy v zásobě nějakou paměť, která se nedávno používala, a tedy není ani čerstvá, ani odswapovaná. Ale zase se to nesmí přehánět. A jde právě o to, kde hledat ten kompromis.

[Josef Kufner]

Na tohle by mohlo být fajn nějak říct jádru něco jako: "Tenhle blok dat můžeš kdykoliv zahodit, ale pokud to uděláš, nastav tento flag." Pak by stačilo mít možnost ovlivnit prioritu, aby se zahazovalo co je nejméně potřebné... a vedle malloc a free by přibylo třeba tempfree a recall (které by se prostě občas nepovedlo).

[Luk]

Na tohle by mohlo být fajn nějak říct jádru něco jako: "Tenhle blok dat můžeš kdykoliv zahodit, ale pokud to uděláš, nastav tento flag."

To tam je a jmenuje se to madvise(). Když se to zavolá s MADV_WILLNEED, říká to jádru, že ta paměť bude brzy potřeba. Naopak MADV_DONTNEED říká opak. Bohužel to ale AFAIK nefunguje podle očekávání - MADV_WILLNEED jen vynutí přednačtení ze swapu nebo souboru, ale nemění prioritu stránek při pozdějším odswapovávání.

[miho]

Takove chovani ale lze docela dobre poznat. Aplikace naroste do nejake velikosti (odpovidajici pametove nejnarocnejsi uloze, kterou zpracovavala) a pak uz neroste. Kdezto napr. kaffeine prokazatelne naroste s kazdym prehranym videem o nekolik MB

Kazdopadne se mi toto chovani ne zcela libi. Krom brzdeni hibernace to zmensuje dostupnou pamet pro diskovou cache. S implicitnim nastavenim swapiness jadro vyhazuje neaktivni stranky do swapu velmi neochotne a radsi ukrajuje z diskove cache.

[zde]

Jojo. Tohle byl (nebo stále je?) problém glibc. malloc(100M) -> sbrk(100M). malloc(1M) -> sbrk(1M). free(100M) -> NIC (vrátit původní brk nejde, protože uvolnovaná paměť není na konci). Novější malloc knihovny vůbec brk() nepoužívají, a velké bloky spravují přes mmap/munmap(), takže tento problém nehrozí. Trvalé postupné kynutí ale asi bude opravdu způsobeno leakováním samotné aplikace.

[alblaho]

Díky za výborný post!

Pamatuju si, jak jsem v diplomce (C++) nechal memory-leak, protože bylo týden do odevzdání a já neměl čas to lovit a odvahu opravovat. Byla to desktopovka na jakousi analýzu čehosi, takže to bylo jedno.

V podstatě už nejsem ochotný psát v jazyku bez GC, tohle klidně svěřím stroji a budu se věnovat vlastnímu problému. Leak se dá vyrobit i v Javě nebo Pythonu, ale na jiné úrovni a lépe dohledatelný a opravitelný.

Na leaky se asi bude kašlat čím dál víc, protože díky virtuální paměti je to míň nebezpečné, než přístup do předčasně uvolněné paměti (segfault nebo přepsání jiných dat). Prostě to "jenom" žere swap a adresový prostor. Když se na 64bitovém stroji vyhradí nějakých 20 giga na swap, tak to může leakovat jaxviňa a člověk, který desktop na noc vypíná nepozná nic. Nelíbí se mi to, ale je to tak.

[Deleted [8409]]

Osobně zastávám názoru, že pokud si programátor není schopný uhlídat leaky, tak jeněco špatně, prostě C/C++ není pro každého

[Luboš Luňák]

valgrind --tool=memcheck --leak-check=full

[miho]

To pisteautorum aplikaci a ne me, aj to znam :) Vsechny tyto utilitky ukazou, kde byla alokovana pamet, na kterou se nekde pozdeji ztratila reference. Od teto informace k zjistenei kde a kdy mela byt uvolnena je cesta trnita...

[Lu-Tze]

A nakonec problém nejzákeřnější. Co když nejaká aplikace klade kukaččí vejce do jiné? Zní to sice divně ale v linuxu je to běžné. Aplikace s GUI např. využívají zdroje Xserveru. V tomto případě je řešením utilitka xrestop ale pro každý takový případ musí být jiná utilita, žádné obecné řešení existovat nemůže.

No můžu tu aplikaci ukončit. A budu mít k dispozici údaje od jednotlivých procesů před a po. Snad by z toho šlo taky něco vidět.

[miho]

U tech Xek by se to dalo, tam vicemene funguje, ze kdyz kukacka chcipne tak Xka vyhodi nahnivajici pukavce z hnizda. Obecne to ale rici nelze.

[Miloslav Ponkrác]

Ano, memory leak je problém. Já osobně se bráním memory leakům z největší části tak, že už samotná architektura programu jim předchází.

Jinak neexistují jen memory leaky. Vzhledem k tomu, že mnoho programovacích jazyků s garbage collectorem sice uvolňuje paměť, ale má problémy s automatickým uvolňováním jiných zdrojů - třeba handlů systému, lze i tam se dostat do zajímavých situací. Osobně jsem viděl program v Javě, kde programátor spoléhal na to, že finalize() uvolní zdroje systému, ale zapomněl na to, že to může JVM udělal klidně až za řadu hodin. A mezitím se mu v nepoužívaných blocích paměti nashromáždilo tolik neuvolněných grafických objektů čekajících na finalize(), že javovský proces překročil max. počet grafických objektů a přestal zobrazovat. Hledání této chyby bylo daleko horší a zdlouhavější, než hledání jakéhokoli memory leaku, co jsem kdy zažil. Chyba se projevovala dost náhodně.

Takže nic a žádná automatika Vás nezachrání před velmi obtížně hledatelnými chybami.

[Heron]

finalize se nemusí zavolat vůbec. Na to by žádný programátor spoléhat neměl a měl by cizí zdroje zavírat hned jak je přestane používat.

[Miloslav Ponkrác]

Ano ano, nicméně když jsem tuto chybu hledal v cizím javovském programu - bylo pro mě velké poučení, že záludná chyba se dá vyrobit v podstatě všude a všelijak.

Koneckonců kromě memory leaků a neuvolněných zdrojů systému je možné také týdny nespat hledáním proč ve Vašem složitém a efektivním algoritmu to dává špatný výsledek - a hledat zasunutou logickou chybu. A máte ještě asi tisíc dalších způsobů jak se budit hrůzou ze spaní jako programátor.

Nevím, proč má memory leak tak špatnou pověst, když se v podstatě nakonec dá vždycky v podstatě nechanicky nalézt - dříve či později, dokonce na to existují i vynikající nástroje. Ale taková dobře hezky zasunutá logická chyba v programu projevující se naprosto náhodně a kde nevíte odkud hledat - to je teprve to pravé peklo programátora.

[zde]

Nám se stalo přesně to samé. Za fůru $$$ se koupilo železo a aplikace, která se spravuje přes nějakého daemona, napsaného v Javě. Vždy se mu předhodí pathname, který on otevře, schroustá a updatuje podle toho in-memory databázi. No a daemon samozřejmě leakoval file descriptory, a do dvou dnů ryla ta "bezpečná" Java držkou v prachu. Fakt je že podle tracebacků (zvrhle logovaných v XML, samozřejmě) to asi za necelé 3 týdny opravili.

[foo]

xterm a plain vi mi nekynou, takze jsem v pohode... ;)

[Miloš]

Rád bych upozornil na jednu nepřesnost překladu, jinak se jedná o pěkný článek

Ostrich algorithm. Ve wikipeii tam píšou něco o strkání hlavy do písku, proto si myslím že se zde má slovo "ostrich" normálně přeložit na "pštros".

Proto by se měl odkaz jmenovat spíš "pštrosí algoritmus"