Re: about Grinder MultiThreads

Looking at the original report, my guess would be that the test script
is memory hungry.

        at java.lang.Thread.start0(Native Method) [na:1.6.0_37]
        at java.lang.Thread.start(Thread.java:640) [na:1.6.0_37]
       *at
javatest.WriteMulitpleLittleFile.write(WriteMulitpleLittleFile.java:66)
~[JavaOsTesting/:na]*
        at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
~[na:na]
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
~[na:1.6.0_37]
        at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_37]
        at
org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186)
~[jython-standalone-2.5.3.jar:na]


It appears to be starting a thread. Quite why that needs to allocate
512M, I don't know. But I'd start by reviewing the script.

- Phil


On 18/11/13 09:58, Gary Mulder wrote:
> So its not process limits. Grinder seems to run out of memory
> surprisingly quickly. Have you tried running other Java programs with
> JRocket on the same server?
>
> I would next try to look at JRocket's Garbage Collection behaviour and
> see if you see anything unusual:
>
> http://docs.oracle.com/cd/E15289_01/doc.40/e15061/verbose.htm
>
> Regards,
> Gary
>

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk

_______________________________________________
grinder-use mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/grinder-use