Jak vám kyne linux? (diskuse)

[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"