jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: BeanShell and JVM Garbage Collection
Date Thu, 21 Jun 2012 15:54:35 GMT
On 21 June 2012 16:16, Shmuel Krakower <shmulikk@gmail.com> wrote:
> Yep you got me right, thanks.
>
> So Roderick Parks problem might come from his own code and not from the
> beanshell sampler itself.

Or it could be a combination of the two - i.e. the way he uses
BeanShell might cause the leak; alternate code might avoid it.

> In order to be sure  Roderick should create a heap dump of jmeter when the
> original memory problem occurs and than analyze to see if the leak came

Yes, but given that reset() provides a solution, there's no pressing
need to establish the actual cause.

> from his code / objects or from jmeter's.

We know it does not come from JMeter because resetting the beanshell
server fixes the issue.

> Make sense?
>
> On Thu, Jun 21, 2012 at 6:08 PM, sebb <sebbaz@gmail.com> wrote:
>
>> On 21 June 2012 16:01, Shmuel Krakower <shmulikk@gmail.com> wrote:
>> > Sebb,
>> > Aside of compatibility, does it make sense that the "Reset
>> bsh.Interpreter
>> > before each call" will solve this kind of a problem?
>>
>> Not quite sure what you mean here.
>> The reset() function actually creates a new interpreter, thus allowing
>> GC to tidy up the old interpreter.
>>
>> > And if so, it might be caused by some kind of leak in the beanshell code
>> of
>> > the user and not necessarily due to bug in JMeter, right?
>>
>> Yes, the leak might be in user code or BeanShell itself.
>>
>> And if the leak is in BeanShell itself, maybe it will be fixed one day...
>>
>> > Shmuel.
>> >
>> >
>> > On Thu, Jun 21, 2012 at 5:47 PM, sebb <sebbaz@gmail.com> wrote:
>> >
>> >> On 20 June 2012 18:54, Roderick Parks <roderick.parks@triometric.net>
>> >> wrote:
>> >> > I hit an interesting problem today where my test slowed to a crawl
>> after
>> >> > about just 6000 iterations (out of a total of about 500000 required)
>> >> > irrespective of the number of threads, delay timer or size of Java
>> heap
>> >> > space. The system was operating well within its CPU and memory limits.
>> >> >
>> >> >
>> >> >
>> >> > My test is trivial: replaying XML API requests from a CSV file after
>> >> > advancing the dates in the otherwise perishable samples. I use bean
>> >> > shell to modify the dates.
>> >> >
>> >> >
>> >> >
>> >> > I allowed the script to continue labouring and finally the JVM died:
>> "GC
>> >> > overhead limit exceeded".  The solution was simply to check the "Reset
>> >> > bsh.Interpreter before each call" box on my bean shell sampler and
all
>> >> > was well.
>> >> >
>> >> >
>> >> >
>> >> > The conclusion I have drawn from this is that garbage collection
>> becomes
>> >> > a very difficult task for the JVM if the bean shell interpreter is
not
>> >> > reset, and ultimately, that is what caused the test to stall and the
>> JVM
>> >> > to die. In my experience, heap space exhaustion is the most common
>> cause
>> >> > of failures in JMeter, so having optimal garbage collection is very
>> >> > important.
>> >> >
>> >> >
>> >> >
>> >> > Therefore, I would suggest that the default "false" setting for
>> >> > resetting the bean shell interpreter in all the bean shell components
>> is
>> >> > actually not the sensible choice.  Has this default been challenged
or
>> >> > discussed previously?
>> >>
>> >> The default setting is necessary for compatibility, and cannot be
>> >> changed without potentially breaking some scripts.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> >> For additional commands, e-mail: user-help@jmeter.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org


Mime
View raw message