To help out more, id really need to see some memory line charts, and
test plan.. And code...
regards Nino
Nino Saturnino Martinez Vazquez Wael wrote:
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]
