Limity 32bitové architektury

5.6.2007 23:34 | Přečteno: 2135× | pro temnou strunu

Čili o tom, jak může i běžný smrtelník za běžných okolností pocítit, že dvaatřicet bitíků je zoufale málo. Předem upozorňuji, že celý text doslova přetéká výrazy z javovského světa, takže byste jej vlastně vůbec neměli číst.

Mějme aplikaci v Javě, která má nastavenou maximální velikost heapu na nějakých 1,6 GB (-Xmx1600M). To máte na běžném 32bitovém stroji ještě celkem v pohodě. A nechť ta aplikace občas spadne na OutOfMemoryError. To není v pohodě ani na miliónbitovém stroji, ale stanou se i horší věci (napadá mne v tuhle chvíli třeba to, že omylem kliknete na okiasův blog). Úkol je jasný: zdetekovat, vyladit, opravit, problém odstranit!

A protože jsme pokročilí drsňáci, první co provedeme před tím, než se pustíme do simulací, je nastavení automatického dumpování heapu do souboru při OOM (-XX:+HeapDumpOnOutOfMemoryError). Ve skutečnosti problém najdete tak při druhém, třetím testu, ale to už není moc zajímavé, takže zkusme dál předpokládat, že se po chvíli nějakého toho heap dumpu dočkáme. Má sice asi 1,8 GB, ale po zabalení gzipem už se to po síti přenést dá.

Už tušíte, kde je zrada?

Tak dál: v Javě verze 6 jsme se dočkali pěkného nástroje pro analýzu heapu (jhat). Předhodíte mu heap dump, on ho pár minut chroustá –

A skončí na OutOfMemoryError. Jak milé! Fakt je, že paměťové nároky takového nástroje jsou zvrhle vysoké, ostatně je zvrhle vysoce užitečný. Odhaduju, že pro zpracování našeho dumpu by potřeboval tak 6 GB – a můžete mít klidně 10 GB místa na swapu, virtuální adresní prostor procesu nezvětšíte. Na 32bitové architektuře zkrátka přes 4 GB nejede vlak, a to si gigabajt nebo dva uzurpuje jádro.

(Ehm. Mám za to, že nějaké způsoby existují, ale nic o nich nevím. Poučí mne někdo v diskusi?)

Štěstí v neštěstí? Jhat si poradí i s prvním půlgigabajtem dumpu, ale jak moc vypovídající údaje poskytne, to je otázka.

Poučení? I 64 bitů bude jednou málo. Jsem ostatně toho názoru, že nejmenší adresovatelná část paměti, říkejme třeba bajt, by měla být nejméně 64 bitů velká, ideálně 128. Výhoda by byla, že by se do jednoho bajtu vešla celá IPv6 adresa Nemluvě o Unicodu. A výrobci disků by určitě zajásali. Samá pozitiva, sociální jistoty a sexuální stimulanty.

A jaké máte vy důvody pro 64bitovou architekturu (nebo aspoň proč po ní toužíte)?

       

Anketa

Komentáře

[qiRzT]

Běžný smrtelník by se hlavně divil proč máš na hromadě 1,6 Velké Británie. Že by nějaké nové kolonie? Třetí světová?

Velikost nejmenší adresovatelné položky? To není jen o paměti, ale šířce sběrnice, typu instrukcí... Já bych zahodil celou x86 architekturu....

[Ladicek]

Běžný smrtelník by se hlavně divil proč máš na hromadě 1,6 Velké Británie. Že by nějaké nové kolonie? Třetí světová?

V podstatě jo. One ring to rule them all!

[happy barney]

uvedomelý smrtelník by hlavne zahodil celú javu

[Michal Kubeček]

Ona se zkratka GB pro Velkou Británii zase tak moc nepoužívá…

[qiRzT]

O to mi nešlo. Chtěl jsem si jen naznačit, že normální smrtelník je rád, že ví jak ten počítač zapnout....

[Josef Kufner]

Tady normální smrtelníci naštěstí moc nepobíhají, takže se nemusíme bát.

[Bluebear]

Souhlas, zahození celé x86 architektury by dost pomohlo. Bohužel to ale nehrozí.

[Ondrej 'SanTiago' Zajicek]

V cem?

[Lukáš Rýdlo]

To bych taky rád věděl. Vsadím se, že dřív nebo později začně zase někdo řvát, že jeho programu 16 EB (exabytů) adresovatelné paměti nestačí a ať přejdeme na 128 bitovou architekturu . To vám fakt nestačí 640 kB?

(A od té doby, co dělám v netbeansech mi nestačí už ni 128 MB .)

[Michal Kubeček]

Zase tak černě bych to neviděl. Zatímco už v době, kdy se z 16-bitových architektur přecházelo na 32-bitové, by bylo reálné zaplnit 4 GB paměti v nepříliš dlouhém čase (kdybychom je měli), u 64-bitové adresace je situace dost odlišná. Budu-li předpokládat frekvenci 4 GHz a přenos 128 bitů na jeden takt, dostanu rychlost 64 GB/s a na zaplnění těch 16 EB budu potřebovat asi osm a půl roku. I kdyby se ta (nadsazená) rychlost zvedla stokrát (a všimněte si, že frekvence procesorů už dnes rostou podstatně pomaleji než dřív), pořád zaplnění 16 EB paměti maximální rychlostí bude trvat měsíc. A to nemluvím o tom, že už dnes jsou reálné přenosové rychlosti pamětí podstatně nižší, než co by byl schopen obsloužit procesor, a s jejich zvyšováním to moc růžově nevypadá.

[Ondrej 'SanTiago' Zajicek]

Adresni prostor neni ale jen kvuli fyzicke pameti - predstav si treba operacni system, kde by vsechny nainstalovane knihovny meli pevne misto v adresnim prostoru. Ten by kladl velke pozadavky na adresni prostor bez ohledu na mnozstvi fyzicke pameti.

[Luk]

predstav si treba operacni system, kde by vsechny nainstalovane knihovny meli pevne misto v adresnim prostoru

Přesně tohle dělá prelink - upravuje umístění binárních spustitelných souborů a knihoven tak, aby měly pevné místo v adresním prostoru. Znatelně to zrychluje start programů, i když to má také své mouchy.

[qiRzT]

Nejde zdaleka jen o adresní prostor. Nutnost zpětné kompatibily v mnohém omezuje vývoj procesorů - např RISC vs. CISC. Uznávám, že uvnitř současných x86 je pipeline, používá se spekulativní provádění instrukcí a co já vím, co všechno. Zvenku se to ale pořád tváří jako CISC kompatibilní s 386, což znamená spoustu elektroniky navíc, neumožňuje pořádně využít výhod RISCu (spolupráce s překladačem)... A pravděpodobně mnoho dalších věcí, ale já se v tom zas tak nevyznám (možná se pletu úplně) - mám za sebou jen pár předmětů o tom, jak procesor funguje..

[michich]

Zvenku se to ale pořád tváří jako CISC kompatibilní s 386, což znamená spoustu elektroniky navíc

Ne, neznamená. Téch tranzistorů na překlad z x86 instrukcí do mikrokódu nebude nejspíš ani 1% z celého CPU. Nemůžu teď najít citaci, ale někde jsem to četl.

[qiRzT]

OK, ale každý transistor navíc znamená víc tepla, delší minimální periodu hodin. Nejde tolik o počet, ale způsob zapojení. Krom toho hlavní nevýhoda, to že vlastní RISC je odstíněn od samotného programu (překladače), zůstává.

[michich]

CISC má svoje výhody. Populární instrukce bývají většinou kratší, takže kód je vlastně zkomprimován a vejde se ho víc do cache.

[qiRzT]

Určitě. Nechci tvrdit (i když to tak možná vyznělo), že RISC je všelék zaručeně lepší než CISC. Chci spíš říct, že vývoj v téhle oblasti je bržděněj neustálou snahou o zpětnou kompatibilitu.

[Luk]

Mám za to, že nějaké způsoby existují, ale nic o nich nevím. Poučí mne někdo v diskusi?

No, způsoby jak využívat velkou paměť (> 4 GB) na 32bitovém stroji existují. Ale nevím o způsobu, jak s 32 bity přešvihnout 4 GB adresního prostoru na proces.

[Ladicek]

Jo, to bude ono. Já jsem o tom kdysi jenom matně zaslechl a víc jsem se po tom nepídil.

[zde]

Ale nevím o způsobu, jak s 32 bity přešvihnout 4 GB adresního prostoru na proces.

Docela jednoduše. Zrovna si hraju s qemu-system-x86_64, a na 32-bit hostu jsem úspěšně nainstaloval Arch64. :)

[Luk]

Ano, takhle to jde. Měl jsem na mysli nativní běh. O kolik se to zpomalí, když to poběží v emulaci?

[zde]

Vzhledem k tomu že bez emulace systém vůbec nenaběhne, je emulovaný systém rychlejší než nativní .-) Do konzole to bootuje asi 30s, na PentiuD@1.8GHz.

[Käyttäjä 11133]

Tak třeba zrovna doba startu je celkem nepodstatná, protože u ní je víceméně jedno jestli instrukce běží na nativním procesoru, nebo jestli se emulují.. je to spíše o rychlosti disku, zajímavější by mohla být nějaká kompilace :)

[rADOn]

vytvorit vic procesu a jejich pamet vyuzit nejak spolecne ? treba VESA blahepameti takhle obchazela limit 64kB segmentu v realnem rezimu - sesadilo se nekolik bloku pameti souvisle a segment se holt musel porad prepocitavat. v protectu by to bylo kapku slozitejsi - dejme tomu udelat poradne veliky 'okno' v SHM a pomoci nejakyho komunikaniho protokolu si do nej nechat mapovat kousky dat od 'skladovacich' procesu ?
nebo proste na tmpfs zalozit multigigabytovej soubor a mmapovat si ho po kouskach ? jsou to samozrejme vsechno zhovadilosti na kvadrat ale to je takrikajic soucast zadani
daleko spis to vypada na generalni chybu v navrhu, a to prinejmensim pouziti javy na neco na co proste neni stavena

[alblaho]

S tímhle hnout nejde. Prostě jhat to má dělat tak, že k tomu dumpu bude přistupovat jako k normální diskové databázi. Načítat dump programu, který padl na OOM je celkem jeté. Paměť by se použila jen na cachování.

No, ještě, že si můžu hrát na stroji s 32 GB RAM Naposledy jsem sežral 2.4 giga Pythonem (pypy).

[Ladicek]

Nevím, jestli by šel přímo ten dump použít jako databáze. Ale nějaké předzpracování by asi šlo udělat. Ostatně jhat je typická databázová aplikace: vypisuje seznam tříd seřazený podle počtu alokovaných objektů, umí tě dovést k objektům, které ty objekty drží v paměti a tak dál. Dokonce je tam nějaký dotazovací jazyk (napsaný v JavaScriptu, hehe). Na druhou stranu je otázka, jestli člověk s tím dumpem pracuje tak dlouho, aby se vyplatilo takovou databázi konstruovat. Nevím, momentálně to pro mne nemá moc vysokou prioritu.

[Ladicek]

Jen doplním, myslím samozřejmě předzpracovat na disk(u). Když to na předzpracování v paměti chcípne.

[Lukáš Rýdlo]

Poučení? Nepoužívat Javu (ne to je samozřejmě hloupá provokace, protože každý programátor přece ví, že Java vůbec nežere víc paměti než C/C++ ).

[fakenickname]

ano. cely svet je jen o pameti.

[Aleš Kapica]

Ano, a ta je většinou zoufale krátká..

[Lukáš Rýdlo]

Jojo, obzvláště má paměť je zoufale malá a krátká -- teď o zkouškovém je to poznat...

(Btw. jsem čekal, kdo se na ten můj žertovný flame chytí ...)

[Ladicek]

No upřímně by mne zajímalo, kolik paměti by chtěl aspoň stejně komfortní (a že jhat není žádná perla) program pro analýzu core dumpu programu v C++

Pravda, existují komerční alternativy, které údajně tolik paměti nesežerou. A údajně taky nejsou paměťové struktury jhatu úplně optimálně navrženy. Jenže co já s tím Vlastně už vím, je to přeci open source, tak to nahackuju tak, že bude stačit paměť o polovině velikosti toho dumpu. Jé, já jsem geniální!

[Bluebear]

Nevím, ale připadá mi, že program, který schroustne 4GB paměti na posezení, by k tomu měl mít nějaký opravdu pádný důvod. Když uvážím, že GCC se do tohoto prostoru vejde při kompilaci jádra, Xek i glibc, že v tom běží simulace neuronových sítí, zpracování složitých dokumentů atd. atd., tak co by to muselo být za bestii, aby oprávněně zabrala takové paměti?

Bojím se, že ten program je prostě špatně napsaný a zachází s pamětí notně neefektivně.

[Filip Jirsák]

Výhoda virtuální paměti je právě v tom, že se programátor nemusí o mapování paměti starat, a prostě pracuje s pamětí, a jak si to OS mapuje, a zda to ukládá do swapu nebo kam je programátorovi jedno.

Nějaké ukládání mezivýsledků na disk nebo načítání jen částí by měl programátor řešit až v případě, kdy tím program výrazně urychlí (což jde jen v případě, kdy program dokáže na rozdíl od jádra určit, kdy kterou část dat bude potřebovat). U programu na zpracování dumpu to tenhle případ efektivnosti programu asi nebude, takže problém bych viděl opravdu spíš v tom, že je limit na 4 GB. Samozřejmě, něco jiného je, že u programu na zpracování dumpu asi lze očekávat, že na tenhle limit narazí, a pak holt si programátor musí tu virtuální paměť naprogramovat znovu.

[deda.jabko]

to je hodne nebezpecny pristup.... to ze nam moderni operacni systemy resp. platformy umoznuji snadno pracovat se skoro neomezenym mnozstvim pameti neodebira z programatora odpovednost za to, co vsechno v te pameti bude.... a pokud program chrousta bez problemu 1,6 GiB tak se to chce zamyslet, jestli je vsechno spravne...

[Filip Jirsák]

A to, že moderní OS umožňují programu pracovat s hardwarem, aniž by program přesně znal konkrétní typ zařízení, to je také nebezpečné? A že umožňují pracovat s diskem, aniž by program znal souborový systém? Pokud program potřebuje víceméně náhodný přístup k 1,6 GB dat (třeba bitmapový obrázek ve vysokém rozlišení), nevidím důvod, proč by měl programátor znovu implementovat značnou část správy virtuální paměti, když už je to jednou naprogramované v operačním systému. Pak dochází akorát ke zpomalování a zbytečným akcím, protože program si myslí, že má něco v RAMce, a ono je to zatím na disku ve swapu, nebo si program myslí, že je něco na disku, a ono je to mezitím v RAMce (v cache).

Ostatně, k čemu slouží třeba taková funkce mmap()? Vezmu 3 GB soubor, namapuju ho do paměti, a můžu s ním pracovat pohodlně pomocí ukazatelů s struktur. Jak si to zařídí OS mne jako programátora nemusí moc zajímat (pokud nemám nějaký zvláštní přístup k souboru, takže dokážu mapování mezi souborem a pamětí udělat daleko efektivněji, než to zvládne OS).

[Michal Kubeček]

Ony ty aplikace, které si "dělají vlastní swap", dokážou (mimo jiné) uživateli pěkně znepříjemnit život v okamžiku, kdy autor zapomene na nějakou "drobnost", jako třeba umožnit uživateli rozhodnout, kde ten "swap" bude.

[deda.jabko]

ja ale nemluvim o tom, ze ty funkce jsou spatne. (a presne takovou reakci jsem cekal) spatny je ten pristup mysleni... (dukazem je ten problem se 4GB) kazdy pristup ma sva pozitiva i negativa a diky cachim a bufferum vicemene konverguji ke stejnym rychlostem.... programator by mel hlavne premyslet, nad tim co je v dane situaci nejlepsi....

skutecnost, ze program sezere 1,6 GB RAM a nema k tomu zasadni duvod (treba ten velky obrazek nebo simulaci par se milionu interagujicich entit) melo by to byt signalem, ze je neco spatne. btw. v pripade javy ta relace mezi pameti a diskem neni uplne primocara -- misty spis krivocara a kazi objektovy navrh ;-]

[Filip Jirsák]

Pokud program sežere 1,6 GB RAM a nemá k tomu zásadní důvod, je v něm nejspíš nějaký memory leak. To nemá s návrhem programu nic společného, to je prostě chyba, která se stává i v lepší společnosti.

[Luk]

Ostatně, k čemu slouží třeba taková funkce mmap()? Vezmu 3 GB soubor, namapuju ho do paměti, a můžu s ním pracovat pohodlně pomocí ukazatelů s struktur. Jak si to zařídí OS mne jako programátora nemusí moc zajímat (pokud nemám nějaký zvláštní přístup k souboru, takže dokážu mapování mezi souborem a pamětí udělat daleko efektivněji, než to zvládne OS).

Lze to také výhodně kombinovat s madvise(), aby jádro vědělo, jak se bude určitý úsek paměti používat (náhodně, sekvenčně, brzy, hned tak ne apod.).

[happy barney]

hmm, niekto nečítal učebnice Javy.
"Zabudni na prácu s pamäťou, máme predsa moderný garbage collector". Oops, zaseklo sa mi jeho vlákno.

[Filip Jirsák]

To má něco společného s realitou, tedy že už byl někdy historicky zaznamenán problém v nefunkčnosti GC na nějaké produkční verzi nějaké všeobecně známé JVM, nebo je to jenom pohádka?

[happy barney]

to je vtip + chrobák na zamyslenie sa "čo keby?". Môže daná situácia nastať (prezumcia chyby, nechybu treba dokázať)? Aká je množina známych/teoreticky možných dôvodov na nastanie situácie?

To len tak, keď sa človek po večeroch nudí, von z okna na padajúce kvapky dažďa pozerá, aby si závity prečistil, premazal (nie namazal )

[Filip Jirsák]

To doufám, že to byl vtip, protože v Javě se nemá programátor starat o správu paměti, ale o správu objektů.

Brouk do hlavy to opravdu je, stejně jako přemýšlení o tom, co kdyby procesor špatně počítal, kompilátor špatně překládal, nebo přemýšlení o nesmrtelnosti chrousta. Ve všech případech (špatné výpočty procesoru, špatný překlad kompilátoru, nefunkční GC) tomu programu nepomůže ani svěcená voda. Pokud je program uzavřený v nějaké platformě, musí počítat s tím, že ta platforma funguje správně – nic jiného mu nezbývá, nemá šanci, jak případné chyby rozpoznat a opravit.

[Bluebear]

Brouk do hlavy to opravdu je, stejně jako přemýšlení o tom, co kdyby procesor špatně počítal, kompilátor špatně překládal, nebo přemýšlení o nesmrtelnosti chrousta.

Ale i takové problémy je třeba řešit, i když to řešení musí být částečně na hardwaru (notoricky známý příklad jsou změny obsahu paměti dané kosmickými paprsky, které se při návrhu vesmírných sond musí brát v úvahu).

Kód psaný tak, aby obcházel nějakou notoricky známou chybu kompilátoru už jsem taky párkrát viděl.

Kromě toho GC nemusí být vůbec nefunkční, ke katastrofě může dojít i jen tehdy, když se spustí v nevhodnou chvíli.

[Bluebear]

Ještě mě napadlo, že v linuxovém kernelu se to přímo hemží nejrůznějšími testy a speciálními kusy kódu, které mají za úkol poradit si s chybami v procesoru, se špatně navrženým harwarem, který nerespektuje některé příkazy, atd.

[Filip Jirsák]

To jsou ale všechno známé chyby, a jsou to chyby jenom nějaké části platformy. Tzn. z kódu samotného jde té samé akce docílit jinak (např. při chybě výpočtu na FPU si ten výpočet provede program sám na jiné jednotce procesoru). Javovský program ale nemá šanci, jak jinak zrušit objekt, než přes GC. Měl jsem ne mysli (ale nenapsal jsem to) takové chyby platformy, kdy je chybně nějaký celý blok platformy, který za sebe nemá náhradu. Např. na té sondě je předpokládám nějaký modul, který počítá kontrolní součty paměti a zbytek hardwaru vidí paměť normálně, nebo vidí, že je v daném místě neopravitelná chyba. Pokud se porouchá tahle část (a je na sondě pouze jednou), software s tím už nic neudělá. JVM by ostatně taky mohla mít těch GC několik.

Kromě toho GC nemusí být vůbec nefunkční, ke katastrofě může dojít i jen tehdy, když se spustí v nevhodnou chvíli.

K takové "katastrofě" by mohlo dojít snad jen v případě, že by GC zabral systémové prostředky, které by nemohl využít zbytek aplikace. Jenže to by pořád ještě nemělo skončit katastrofou, protože Java není určena pro realtime systémy

[Michal Vyskočil]

Java není určena pro realtime systémy

Minimálně Sun by s takovým výrokem rozhodně nesouhlasil

Pochopitelně takové ohýbání Javy vede na věci, které jsou popsány např. v Jaderných novinách

Real-Time Specification for Java (RTSJ) **vyžaduje**, aby JVM poskytovalo třídy s funkcemi, které umožní přímý přístup k fyzické paměti; veškeré fyzické paměti.

[Filip Jirsák]

Měl jsem ne mysli standardní Sunovské JVM (a trochu jsem to popletl, kdo si to má pamatovat, která licence zakazuje řídit atomovou elektrárnu a která letadlovou loď):

You acknowledge that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun Microsystems, Inc. disclaims any express or implied warranty of fitness for such uses.

Realtimová Java je už trochu něco jiného, mimo jiné má právě další možnosti práce s pamětí, které umožňují obejít GC.

[happy barney]

Javovský program ale nemá šanci, jak jinak zrušit objekt, než přes GC.

TIMTOWDI asi "veľký návrhár javy" nepoznal

K takové "katastrofě" by mohlo dojít snad jen v případě, že by GC zabral systémové prostředky, které by nemohl využít zbytek aplikace. Jenže to by pořád ještě nemělo skončit katastrofou, protože Java není určena pro realtime systémy

Hmm, blbá otázka: ako má JVM (a GC) ošetrený deadlock vo finalize ?

[Filip Jirsák]

finalize může být voláno z libovolného vlákna, vláken pro finalizaci může běžet v systému několik. Takže případný deadlock by neměl ohrozit GC, ten si maximálně vytvoří další vlákno pro finalizaci. Takže z toho nejspíš vznikne "jen" klasický memory leak.

[zde]

Deadlock při finalizaci nemají, zato ale mají 1e6 jiných problémů. :)

The finalization system is lame. Worse than merely being lame, they brag about how lame it is! To paraphrase the docs: ``Your object will only be finalized once, even if it's resurrected in finalization! Isn't that grand?!'' Post-mortem finalization was figured out years ago and works well. Too bad Sun doesn't know that.

http://www.jwz.org/doc/java.html

[Ondrej 'SanTiago' Zajicek]

> Pokud je program uzavřený v nějaké platformě, musí počítat s tím, že ta platforma funguje správně – nic jiného mu nezbývá, nemá šanci, jak případné chyby rozpoznat a opravit.

No v mnoha pripadech ma moznost chybu detekovat a workaroundovat. Je otazka, zda je to spravny postup.

[Bluebear]

Nevím o případu v JVM, ale obecně ve virtuálních strojích se chyba v garbage collectoru občas vyskytne, stejně jako v každém jiném programu.

[deda.jabko]

pokud to byl vtip, omlouvam se... ale na praci s pameti se nesmi zapominat ani v jave! garbage collector se stara jenom o to, aby na ni programatori nemuseli myslet tak casto...

jenom pro poradek "ucebnicovy priklad"

class Foo {
  private static List log = new ArrayList();

  public void bar() {
    log.add(new LogItem(...));
  }
}

[Ladicek]

Což je přesně to, co se dělo v inkriminovaném programu. Tedy, ne zcela přesně, ta kolekce byla potřeba, ale strašná spousta objektů (které nejsou zrovna lightweight) se do ní ukládala nadbytečně. Shit happens.

[zde]

Proboha kterej kokot napsal nástroj na analýzu Javového heap dumpu v Javě?!?

[alblaho]

Žejo. Python nebo Ruby by byla lepší volba. Samozřejmě běhané nad Jythonem/Jruby, aby to bylo přenositelné.

[zde]

Ehh? JVM je psána v Pythonu nebo Ruby?

[happy barney]

opačne, interpret pythonu/ruby bol prepísaný do Javy (<joke>pravdepodobne aby skripty bežali dostatočne dlho</joke>)

[Michal Vyskočil]

Mám takový dojem, že první verze JVM byly napsány v nějakém interpretovaném jazyce, ale nemůžu najít zdroj.

[Jiří Veselský]

Předhodíte mu heap dump, on ho pár minut chroustá – A skončí na OutOfMemoryError. Jak milé!

Třeba je problém v tom jhatu - zkuste vzít jeho heap dump a zanalyzovat ho, dobrý nástroj na todle je jhat.

[Ladicek]

)))) plus tisíc, tohle mne opravdu pobavilo