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