Re: Memory And Threads

Gary Mulder <[email protected]> Sun, 31 Aug 2014 21:56:48 +0100
Newsgroups gmane.comp.java.grinder.user
Message-ID <CAKy9zTDt_-Si0RhrjeuOZQz_shveA1oO4SwwNmP-UOb96Zfc2A@mail.gmail.com>
On 31 August 2014 21:37, Adil qureshi <[email protected]> wrote:

> Hi,
> Thanks for replying.
> I have done this no improvement.
>
Turning on the logging without examining what the log is indicating
probably will provide no improvement. CMS is actually in aggregate slower
than the default GC configuration (Parallel GC), but it does provide
smoother overall operation of the JVM.

What size (minor) GC and Full GC pauses are you seeing? The minor GC pauses
typically occur every 1-10 seconds. The "real=N.NN" indicates when the JVM
is collecting garbage and not executing Grinder threads. If say your GC is
taking 200ms (real=0.2 secs) and minor GC is occurring every 1 second then
20% of your execution time is GC.

If it isn't GC, then you're going to have to collect some OS metrics to
understand why Grinder isn't able to scale threads. I can't help you much
with Windows other than to say the Java threading and process model is
designed around a UNIX-like kernel and not a process-heavy Windows model.

If you're on LInux run:

man vmstat

Lots of docs in the vmstat manual page to understand how the JVM is
interacting with your OS. Specifically you want less threads runnable than
you have cores and generally no threads blocked. Also you want low system,
I/O wait and interrupt CPU utilisation and no less than 20% CPU idle.
Compare "vmstat 3" output between your 25 and 30 threads and try and
determine what bottleneck you are hitting.

Regards,
Gary

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/

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