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