Ked uz nic ine, tak sa urobit dump a tam je vidno vsetky objekty, ktore su v pamati.

2006/2/10, Petr Matulík - MoroSystems <[EMAIL PROTECTED] >:
Dobry den,

mame stejny problem a po desitkach hodin jeho reseni se nezda byt v
nasich silach jej vyresit. JSTL jsme v nasem pripade z okruhu
podezrelych vyloucili. Kvalitni vstupni branou ke studiu tohoto problemu
je
http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
.

S pozdravem

Petr

--
Bc. Petr Matulík

MoroSystems
+420 605 409 300
[EMAIL PROTECTED]
http://morosystems.cz



ales napsal(a):

> Dobry den,
> na zaklade osobnej skusenosti by som Vam odporucil:
>
> - preverit konfiguraciu Tomcat
> (http://tomcat.apache.org/tomcat-5.0-doc/jasper-howto.html,
> http://jakarta.apache.org/tomcat/faq/memory.html )
> - preverit JDBC ovladac ci neobsahuje memory leak (vid Bugzilla
> prislusneho projektu, pripadne nieco obdobne)
> - zmenit implicitne hodnoty JVM
> ( http://blogs.sun.com/roller/resources/watt/jvm-options-list.html)
> - preverit aplikaciu pomocou profilera ci neobsahuje memory leak (nie
> je to sice profiler, ale dobru skusenost mam aj s GCViewer -
> http://www.tagtraum.com/gcviewer.html)
>
> Ales
>
>
>
> Benda Lukas wrote:
>
>> Zacal jsem pouzivat tomcar, spring (jstl) a hibernate, misto
>> jednoduchych JSP a servletu na strankach. Problem je ale s obsazenim
>> pameti. Pri lazeni musim aplikaci nekolikrat spoustet a reloadovat,
>> bezne se jiz po druhem reloadu (od restartu Tomcatu), zacne vsechno
>> zpomalovat a pritom pamet obsazena Tomcatem narusta. Po sestem az
>> sedmem reloadu dojde k "heapu" a musim restartovat Tomcat.
>>
>> Podle prispevku "Memoryleak v jstl?" to vypada ze za problemu muze
>> jstl. Da se s tim neco delat? Preci kdyby to delalo i v ostrem
>> provozu tak aplikaci neni mozno vubec nasazovat, ne?
>>
>> Vyresi problem prechod napr. na Jetty?
>>
>>
>>
>>
>>
>>
>
>



Odpovedet emailem