On 21 June 2012 16:01, Shmuel Krakower <[email protected]> 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 <[email protected]> wrote: > >> On 20 June 2012 18:54, Roderick Parks <[email protected]> >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
