Nakonec jsem pouzil JVisualVM a HeadpDump a vypada to ze je tam nejaky
strinbugffer s logem, ktery neustale roste. Jeste zjistit, jestli to je od
NetBeans STDOut Console nebo od Logbacku, ale to uz asi nebude takovy problem.
Diky vsem za rady
Tom
________________________________
From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On
Behalf Of Jan Houska
Sent: Wednesday, May 05, 2010 12:19 PM
To: Java
Subject: Re: Memory leaky
Ja pouzivam rovnez MAT. U bezici aplikace provest heap dump idealne
pres jmap (pripadne nastavit jvm tak, aby vytvorila heapdump pokazde kdyz dojde
pamet (-XX:+
HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=adresar) a potom analyzovat
dump v MATu.
Muze se stat, ze heap se neda v MATu otevrit (server ma vice pameti nez
vyvojarske PC), pak se da MAT pustit z konzole pres prikazovou radku a umi
vygenerovat report do html.
Honza
2010/5/5 Ondra Medek <xmed...@gmail.com>
Ja mam tez dobre zkusenosti s Eclipse MAT (free): zjisti,
objekty
ktere tridy zabiraji nejvice, pak lze funkci "find root to gc"
rychle
najit zdroj leaku.
2010/5/5 Michal Bocek <michal.bo...@gmail.com>:
> Skuste jprofiler alebo yourkit a porovnat snapshoty. Pripadne
nakonfigurovat
> jvm tak aby robil heapdump a ten nasledne analyzovat.
>
> Snad som pomohol,
> Michal.
>
> 2010/5/5 Lukáš Záruba <lukas.zar...@media-solutions.cz>
>>
>> Zkus jvisualvm aplikačku z JDK (je ve složce bin), tam jde
udělat heap
>> dump a pak se v něm kouknout kolik instancí čeho a v jakém
stavu byly.
>> Nejsem si jistý, jak se tohle liší od normálního profilingu
z hlediska
>> komunikace s JVM, nicméně už jsem pomocí toho odhalil dost
problémů...
>> Použití je poměrně jednoduché, taže myslím, že nepotřebuje
další
>> vysvětlení :)
>>
>> L.
>>
>> ______________________
>> Lukáš Záruba (Lukas Zaruba)
>> Chief Technical Officer
>> MEDIA SOLUTIONS EUROPE
>> Lisabonská 4
>> Praha 9 190 00
>> Czech Republic
>> phone: +420 721 879 363
>>
>>
>>
>> Tomas Hubalek wrote:
>>>
>>> Zdar,
>>> mam velice rozsahlou aplikaci v Jave a nekde se mi
neuvolnuje pamet.
>>> Statickz analyza kodu by snad ani nebyla mozna v rozumnem
case. Nasel jsem
>>> moc pekny tutorial
http://www.javapassion.com/handsonlabs/nbprofilermemory/
>>> bohuzel mi vdycky JVM krachne na
>>> WARNING: [AWT-EventQueue-1] Cant promote a shared lock
held by 2
>>> threads!
>>> #
>>> # An unexpected error has been detected by Java Runtime
Environment:
>>> #
>>> # Internal Error (sharedRuntime.cpp:886), pid=4752,
tid=5992
>>> # Error: guarantee((retry_count++ < 100),"Could not
resolve to latest
>>> version of redefined method")
>>> #
>>> # Java VM: Java HotSpot(TM) Client VM (11.0-b16 mixed mode,
sharing
>>> windows-x86)
>>> # An error report file with more information is saved as:
>>> #
>>>
D:\CurrentProjects\CADET2009\netbeans-modules-suite.2.1\application\target\cadet\hs_err_pid4752.log
>>> #
>>> # If you would like to submit a bug report, please visit:
>>> # http://java.sun.com/webapps/bugreport/crash.jsp
>>> #
>>> Zkousel jsem to jak na Linuxu, tak na Windowsech, bohuzel
porad stejne.
>>> Netusite nekdo, jak to zjistit to same bez profileru?
Command line mi
>>> nedela problem.
>>> Tom
>
>
--
Ondra Medek
