Thomas Singer wrote:
Right, I did not run JMeter for hours to find our some growing
instance count. Until now I used the heapdump I've got from an OOME on
our production system. Although this does not show the *increasing*
instance count, but I can take a look at the instance count and object
size at the time of the OOME. Shouldn't that help to find out the
problematic instance(s)?
That does not give that much information you really need to look at a
linechart or something, especially something that shows when gc are run
and then you can start to figure out what could be the problem.. Real
memory leaks cant really happen i java(AFAIK), but what can are that
some static things keeps a lock on some resources after they should be
freed. Then they cant be collected by gc, and dada a memory leak. Since
the application will continue to produce more resources which cannot be
cleaned. Now they may be very small, and things can be triggered from
everywhere in the application so theres A LOT to watch out for.. This is
where a profiler and jmeter can help a little, but in the end it still
feels a lot like looking at tea leaf's.. But if you dissect it, with
jmeter and a profiler you will find the problem in the end.
BTW, as I remember it jprobe[1] has a freeversion, which is adequate..
[1]=http://javaboutique.internet.com/reviews/jprobe_5/figure_2.jpg
regards nino
Tom
Nino Saturnino Martinez Vazquez Wael wrote:
Thomas Singer wrote:
You can try to see if its any page in particular that causes this.
Or of its something general... Also you need to watch out for
objects that just keep growing in number..
None of our classes has an unexpected high instance count.
Im not sure if youve already done this. So thats why you need to poke
around with jmeter, hit the different pages(in different tests) maybe
thousands of times(if its a very small leak). Then the difference
should be more clear. I once had an error that originated in a
hashmap that locked session context, it was very hard to find and was
not our error but a 3rd party I used 4 very long days for finding the
problem...
It's a little abstract to use a profiler as it will not give you a
clear idea as everything originates in class[] int[] etc...
Of course.
Tom
Nino Saturnino Martinez Vazquez Wael wrote:
You can try to see if its any page in particular that causes this.
Or of its something general... Also you need to watch out for
objects that just keep growing in number..
It's a little abstract to use a profiler as it will not give you a
clear idea as everything originates in class[] int[] etc...
regards Nino
Thomas Singer wrote:
Be sure to checkout the wiki for gotchas and tips:
http://cwiki.apache.org/WICKET/wicket-and-jmeter.html
http://cwiki.apache.org/WICKET/wicket-and-jmeter-with-regular-expressions.html
Already done, but what we can get? An OOME in our application with
the heapdump. Well, we already have one and the most used objects
appear to come from Wicket (char[], byte[], String, <class>[],
HashMap$Entry, XMLTag, ValueMap, ComponentTag, RawMarkup,
HashMap$EntrySet, int[], short[] just to name the largest).
--
Best regards,
Thomas Singer
_____________
SyntEvo GmbH
www.syntevo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
