You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jmeter.apache.org by pm...@apache.org on 2017/01/16 21:27:21 UTC

svn commit: r1779108 - in /jmeter/trunk: bin/jmeter bin/jmeter.bat xdocs/changes.xml

Author: pmouawad
Date: Mon Jan 16 21:27:21 2017
New Revision: 1779108

URL: http://svn.apache.org/viewvc?rev=1779108&view=rev
Log:
Bug 60593 - Switch to G1 GC algorithm
Bugzilla Id: 60593

Modified:
    jmeter/trunk/bin/jmeter
    jmeter/trunk/bin/jmeter.bat
    jmeter/trunk/xdocs/changes.xml

Modified: jmeter/trunk/bin/jmeter
URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter?rev=1779108&r1=1779107&r2=1779108&view=diff
==============================================================================
--- jmeter/trunk/bin/jmeter (original)
+++ jmeter/trunk/bin/jmeter Mon Jan 16 21:27:21 2017
@@ -67,10 +67,7 @@ done
 
 PRGDIR=`dirname "$PRG"`
 
-# The following should be reasonably good values for most tests running
-# on Sun JVMs. Following is the analysis on which it is based. If it's total
-# gibberish to you, please study my article at
-# http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&detailArticle=true&id=9606
+#
 # Original page has disappeared, it is now only available at: 
 # https://web.archive.org/web/20060614151434/http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&detailArticle=true&id=9606
 #
@@ -90,36 +87,18 @@ PRGDIR=`dirname "$PRG"`
 # system's memory availability:
 HEAP="-Xms512m -Xmx512m"
 
-# There's an awful lot of per-sample objects allocated during test run, so we
-# need a large eden to avoid too frequent scavenges -- you'll need to tune this
-# down proportionally if you modify the HEAP values above, below example is fine for 512m of Heap:
-# NEW="-XX:NewSize=128m -XX:MaxNewSize=128m"
-
-# This ratio and target have been proven OK in tests with a specially high
-# amount of per-sample objects (the HtmlParserHTMLParser tests):
-# SURVIVOR="-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50"
-
-# Think about it: trying to keep per-run objects in tenuring definitely
-# represents a cost, but where's the benefit? They won't disappear before
-# the test is over, and at that point we will no longer care about performance.
-#
-# So we will have JMeter do an explicit Full GC before starting a test run,
-# but then we won't make any effort (or spend any CPU) to keep objects
-# in tenuring longer than the life of per-sample objects -- which is hopefully
-# shorter than the period between two scavenges):
-#
-TENURING="-XX:MaxTenuringThreshold=2"
-
-CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
+#VERBOSE_GC="-verbose:gc -Xloggc:gc_jmeter_%p.log -XX:+PrintGCDetails -XX:+PrintGCCause -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps"
 
 # Finally, some tracing to help in case things go astray:
-#DEBUG="-verbose:gc -XX:+PrintTenuringDistribution"
+GC_ALGO="-XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:G1ReservePercent=20"
+
+CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
 
 # Always dump on OOM (does not cost anything unless triggered)
 DUMP="-XX:+HeapDumpOnOutOfMemoryError"
 
 SERVER="-server"
 
-ARGS="$SERVER $DUMP $HEAP $NEW $SURVIVOR $TENURING $PERM $CLASS_UNLOAD"
+ARGS="$SERVER $DUMP $HEAP $CLASS_UNLOAD $VERBOSE_GC $GC_ALGO"
 
 java $ARGS $JVM_ARGS $JMETER_OPTS -jar "$PRGDIR/ApacheJMeter.jar" "$@"

Modified: jmeter/trunk/bin/jmeter.bat
URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.bat?rev=1779108&r1=1779107&r2=1779108&view=diff
==============================================================================
--- jmeter/trunk/bin/jmeter.bat (original)
+++ jmeter/trunk/bin/jmeter.bat Mon Jan 16 21:27:21 2017
@@ -71,31 +71,24 @@ rem On NT/2K grab all arguments at once
 set JMETER_CMD_LINE_ARGS=%*
 
 rem The following link describes the -XX options:
-rem http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
-rem http://java.sun.com/developer/TechTips/2000/tt1222.html has some more descriptions
-rem Unfortunately TechTips no longer seem to be available, except via:
-rem https://web.archive.org/web/20090614101951/http://java.sun.com/developer/TechTips/2000/tt1222.html
+rem http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
 
 rem See the unix startup file for the rationale of the following parameters,
 rem including some tuning recommendations
 set HEAP=-Xms512m -Xmx512m
-set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
-set SURVIVOR=-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50%
-set TENURING=-XX:MaxTenuringThreshold=2
-rem Java 8 remove Permanent generation, don't settings the PermSize
-if %current_minor% LEQ "8" (
-    rem Increase MaxPermSize if you use a lot of Javascript in your Test Plan :
-    set PERM=-XX:PermSize=64m -XX:MaxPermSize=128m
-)
+
+#Uncomment this to generate GC verbose file
+rem set VERBOSE_GC=-verbose:gc -Xloggc:gc_jmeter_%p.log -XX:+PrintGCDetails -XX:+PrintGCCause -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps
+
+set GC_ALGO=-XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:G1ReservePercent=20
 
 set CLASS_UNLOAD=-XX:+CMSClassUnloadingEnabled
-rem set DEBUG=-verbose:gc -XX:+PrintTenuringDistribution
 
 rem Always dump on OOM (does not cost anything unless triggered)
 set DUMP=-XX:+HeapDumpOnOutOfMemoryError
 
 rem Additional settings that might help improve GUI performance on some platforms
-rem See: http://java.sun.com/products/java-media/2D/perf_graphics.html
+rem See: http://www.oracle.com/technetwork/java/perf-graphics-135933.html
 
 set DDRAW=
 rem  Setting this flag to true turns off DirectDraw usage, which sometimes helps to get rid of a lot of rendering problems on Win32.
@@ -109,7 +102,7 @@ rem set DDRAW=%DDRAW% -Dsun.java2d.ddsca
 
 rem Server mode
 rem Collect the settings defined above
-set ARGS=%DUMP% %HEAP% %NEW% %SURVIVOR% %TENURING% %PERM% %CLASS_UNLOAD% %DDRAW%
+set ARGS=%DUMP% %HEAP% %CLASS_UNLOAD% %VERBOSE_GC% %GC_ALGO% %DDRAW%
 
 %JM_START% %JM_LAUNCH% %ARGS% %JVM_ARGS% -jar "%JMETER_BIN%ApacheJMeter.jar" %JMETER_CMD_LINE_ARGS%
 

Modified: jmeter/trunk/xdocs/changes.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?rev=1779108&r1=1779107&r2=1779108&view=diff
==============================================================================
--- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
+++ jmeter/trunk/xdocs/changes.xml [utf-8] Mon Jan 16 21:27:21 2017
@@ -153,6 +153,7 @@ JMeter now requires Java 8. Ensure you u
     <li><bug>54525</bug>Search Feature : Enhance it with ability to replace</li>
     <li><bug>60530</bug>Add API to create JMeter threads while test is running. Based on a contribution by Logan Mauzaize (logan.mauzaize at gmail.com) and Maxime Chassagneux (maxime.chassagneux at gmail.com).</li>
     <li><bug>60514</bug>Ability to apply a naming convention on Children of a Transaction Controller. Contributed by Ubik Load Pack (support at ubikloadpack.com)</li>
+    <li><bug>60593</bug>Switch to G1 GC algorithm</li>
 </ul>
 
 <ch_section>Non-functional changes</ch_section>



Re: svn commit: r1779108 - in /jmeter/trunk: bin/jmeter bin/jmeter.bat xdocs/changes.xml

Posted by Felix Schumacher <fe...@internetallee.de>.

Am 17. Januar 2017 22:43:32 MEZ schrieb Antonio Gomes Rodrigues <ra...@gmail.com>:
>Hi,
>
>For your information I have ask to Kirk Pepperdine if he have already
>use
>JMeter with G1 GC to help us with the parameters.
>
>I am still waiting his answer

I think that tuning GC in the JVM is so specific to your usecase, that every advice is moot if it is not: it depends ;)

Regards,
Felix

>
>Antonio
>
>2017-01-17 20:34 GMT+01:00 Philippe Mouawad
><ph...@gmail.com>:
>
>> Hello Rainer,
>> Nice to see you back among us and Happy new year !
>>
>> Good catch , thanks
>> Regards
>>
>> On Tue, Jan 17, 2017 at 7:08 PM, Rainer Jung
><ra...@kippdata.de>
>> wrote:
>>
>> > Hi there,
>> >
>> >
>> > Am 16.01.2017 um 22:27 schrieb pmouawad@apache.org:
>> >
>> >> Author: pmouawad
>> >> Date: Mon Jan 16 21:27:21 2017
>> >> New Revision: 1779108
>> >>
>> >> URL: http://svn.apache.org/viewvc?rev=1779108&view=rev
>> >> Log:
>> >> Bug 60593 - Switch to G1 GC algorithm
>> >> Bugzilla Id: 60593
>> >>
>> >> Modified:
>> >>     jmeter/trunk/bin/jmeter
>> >>     jmeter/trunk/bin/jmeter.bat
>> >>     jmeter/trunk/xdocs/changes.xml
>> >>
>> >> Modified: jmeter/trunk/bin/jmeter
>> >> URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter?rev=177
>> >> 9108&r1=1779107&r2=1779108&view=diff
>> >> ============================================================
>> >> ==================
>> >> --- jmeter/trunk/bin/jmeter (original)
>> >> +++ jmeter/trunk/bin/jmeter Mon Jan 16 21:27:21 2017
>> >> @@ -67,10 +67,7 @@ done
>> >>
>> >>  PRGDIR=`dirname "$PRG"`
>> >>
>> >> -# The following should be reasonably good values for most tests
>running
>> >> -# on Sun JVMs. Following is the analysis on which it is based. If
>it's
>> >> total
>> >> -# gibberish to you, please study my article at
>> >> -# http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_
>> >> gear_id=1100010&detailArticle=true&id=9606
>> >> +#
>> >>  # Original page has disappeared, it is now only available at:
>> >>  # https://web.archive.org/web/20060614151434/http://www.atg.co
>> >> m/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&
>> >> detailArticle=true&id=9606
>> >>  #
>> >> @@ -90,36 +87,18 @@ PRGDIR=`dirname "$PRG"`
>> >>  # system's memory availability:
>> >>  HEAP="-Xms512m -Xmx512m"
>> >>
>> >> -# There's an awful lot of per-sample objects allocated during
>test run,
>> >> so we
>> >> -# need a large eden to avoid too frequent scavenges -- you'll
>need to
>> >> tune this
>> >> -# down proportionally if you modify the HEAP values above, below
>> example
>> >> is fine for 512m of Heap:
>> >> -# NEW="-XX:NewSize=128m -XX:MaxNewSize=128m"
>> >> -
>> >> -# This ratio and target have been proven OK in tests with a
>specially
>> >> high
>> >> -# amount of per-sample objects (the HtmlParserHTMLParser tests):
>> >> -# SURVIVOR="-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50"
>> >> -
>> >> -# Think about it: trying to keep per-run objects in tenuring
>definitely
>> >> -# represents a cost, but where's the benefit? They won't
>disappear
>> before
>> >> -# the test is over, and at that point we will no longer care
>about
>> >> performance.
>> >> -#
>> >> -# So we will have JMeter do an explicit Full GC before starting a
>test
>> >> run,
>> >> -# but then we won't make any effort (or spend any CPU) to keep
>objects
>> >> -# in tenuring longer than the life of per-sample objects -- which
>is
>> >> hopefully
>> >> -# shorter than the period between two scavenges):
>> >> -#
>> >> -TENURING="-XX:MaxTenuringThreshold=2"
>> >> -
>> >> -CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
>> >> +#VERBOSE_GC="-verbose:gc -Xloggc:gc_jmeter_%p.log
>-XX:+PrintGCDetails
>> >> -XX:+PrintGCCause -XX:+PrintTenuringDistribution
>-XX:+PrintHeapAtGC
>> >> -XX:+PrintGCApplicationConcurrentTime -XX:+
>> PrintGCApplicationStoppedTime
>> >> -XX:+PrintGCDateStamps"
>> >>
>> >>  # Finally, some tracing to help in case things go astray:
>> >> -#DEBUG="-verbose:gc -XX:+PrintTenuringDistribution"
>> >> +GC_ALGO="-XX:+UseG1GC -XX:MaxGCPauseMillis=250
>-XX:G1ReservePercent=20"
>> >> +
>> >> +CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
>> >>
>> >
>> > I think CMS class unloading doesn't make sense in combination with
>G1.
>> CMS
>> > (concurrent Mark Sweep) is an alternative collector which can be
>used
>> > instead of G1. IMHO we should drop this variable ...
>> >
>> >  # Always dump on OOM (does not cost anything unless triggered)
>> >>  DUMP="-XX:+HeapDumpOnOutOfMemoryError"
>> >>
>> >>  SERVER="-server"
>> >>
>> >> -ARGS="$SERVER $DUMP $HEAP $NEW $SURVIVOR $TENURING $PERM
>$CLASS_UNLOAD"
>> >> +ARGS="$SERVER $DUMP $HEAP $CLASS_UNLOAD $VERBOSE_GC $GC_ALGO"
>> >>
>> >
>> > ... and remove it from ARGS
>> >
>> >
>> >  java $ARGS $JVM_ARGS $JMETER_OPTS -jar "$PRGDIR/ApacheJMeter.jar"
>"$@"
>> >>
>> >> Modified: jmeter/trunk/bin/jmeter.bat
>> >> URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.bat?rev
>> >> =1779108&r1=1779107&r2=1779108&view=diff
>> >> ============================================================
>> >> ==================
>> >> --- jmeter/trunk/bin/jmeter.bat (original)
>> >> +++ jmeter/trunk/bin/jmeter.bat Mon Jan 16 21:27:21 2017
>> >> @@ -71,31 +71,24 @@ rem On NT/2K grab all arguments at once
>> >>  set JMETER_CMD_LINE_ARGS=%*
>> >>
>> >>  rem The following link describes the -XX options:
>> >> -rem http://www.oracle.com/technetwork/java/javase/tech/vmoptions
>> >> -jsp-140102.html
>> >> -rem http://java.sun.com/developer/TechTips/2000/tt1222.html has
>some
>> >> more descriptions
>> >> -rem Unfortunately TechTips no longer seem to be available, except
>via:
>> >> -rem https://web.archive.org/web/20090614101951/http://java.sun.
>> >> com/developer/TechTips/2000/tt1222.html
>> >> +rem http://docs.oracle.com/javase/8/docs/technotes/tools/unix/
>> java.html
>> >>
>> >>  rem See the unix startup file for the rationale of the following
>> >> parameters,
>> >>  rem including some tuning recommendations
>> >>  set HEAP=-Xms512m -Xmx512m
>> >> -set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
>> >> -set SURVIVOR=-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50%
>> >> -set TENURING=-XX:MaxTenuringThreshold=2
>> >> -rem Java 8 remove Permanent generation, don't settings the
>PermSize
>> >> -if %current_minor% LEQ "8" (
>> >> -    rem Increase MaxPermSize if you use a lot of Javascript in
>your
>> Test
>> >> Plan :
>> >> -    set PERM=-XX:PermSize=64m -XX:MaxPermSize=128m
>> >> -)
>> >> +
>> >> +#Uncomment this to generate GC verbose file
>> >> +rem set VERBOSE_GC=-verbose:gc -Xloggc:gc_jmeter_%p.log
>> >> -XX:+PrintGCDetails -XX:+PrintGCCause
>-XX:+PrintTenuringDistribution
>> >> -XX:+PrintHeapAtGC -XX:+PrintGCApplicationConcurrentTime
>> >> -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps
>> >> +
>> >> +set GC_ALGO=-XX:+UseG1GC -XX:MaxGCPauseMillis=250
>> -XX:G1ReservePercent=20
>> >>
>> >>  set CLASS_UNLOAD=-XX:+CMSClassUnloadingEnabled
>> >>
>> >
>> > Same here ...
>> >
>> > -rem set DEBUG=-verbose:gc -XX:+PrintTenuringDistribution
>> >>
>> >>  rem Always dump on OOM (does not cost anything unless triggered)
>> >>  set DUMP=-XX:+HeapDumpOnOutOfMemoryError
>> >>
>> >>  rem Additional settings that might help improve GUI performance
>on some
>> >> platforms
>> >> -rem See:
>http://java.sun.com/products/java-media/2D/perf_graphics.html
>> >> +rem See:
>http://www.oracle.com/technetwork/java/perf-graphics-135933.
>> >> html
>> >>
>> >>  set DDRAW=
>> >>  rem  Setting this flag to true turns off DirectDraw usage, which
>> >> sometimes helps to get rid of a lot of rendering problems on
>Win32.
>> >> @@ -109,7 +102,7 @@ rem set DDRAW=%DDRAW% -Dsun.java2d.ddsca
>> >>
>> >>  rem Server mode
>> >>  rem Collect the settings defined above
>> >> -set ARGS=%DUMP% %HEAP% %NEW% %SURVIVOR% %TENURING% %PERM%
>> %CLASS_UNLOAD%
>> >> %DDRAW%
>> >> +set ARGS=%DUMP% %HEAP% %CLASS_UNLOAD% %VERBOSE_GC% %GC_ALGO%
>%DDRAW%
>> >>
>> >
>> > ... and here
>> >
>> >  %JM_START% %JM_LAUNCH% %ARGS% %JVM_ARGS% -jar
>> >> "%JMETER_BIN%ApacheJMeter.jar" %JMETER_CMD_LINE_ARGS%
>> >>
>> >>
>> >> Modified: jmeter/trunk/xdocs/changes.xml
>> >> URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?
>> >> rev=1779108&r1=1779107&r2=1779108&view=diff
>> >> ============================================================
>> >> ==================
>> >> --- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
>> >> +++ jmeter/trunk/xdocs/changes.xml [utf-8] Mon Jan 16 21:27:21
>2017
>> >> @@ -153,6 +153,7 @@ JMeter now requires Java 8. Ensure you u
>> >>      <li><bug>54525</bug>Search Feature : Enhance it with ability
>to
>> >> replace</li>
>> >>      <li><bug>60530</bug>Add API to create JMeter threads while
>test is
>> >> running. Based on a contribution by Logan Mauzaize (logan.mauzaize
>at
>> >> gmail.com) and Maxime Chassagneux (maxime.chassagneux at gmail.com
>> ).</li>
>> >>      <li><bug>60514</bug>Ability to apply a naming convention on
>> Children
>> >> of a Transaction Controller. Contributed by Ubik Load Pack
>(support at
>> >> ubikloadpack.com)</li>
>> >> +    <li><bug>60593</bug>Switch to G1 GC algorithm</li>
>> >>  </ul>
>> >>
>> >>  <ch_section>Non-functional changes</ch_section>
>> >>
>> >
>> > Regards,
>> >
>> > Rainer
>> >
>> >
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>

Re: svn commit: r1779108 - in /jmeter/trunk: bin/jmeter bin/jmeter.bat xdocs/changes.xml

Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
Hi,

For your information I have ask to Kirk Pepperdine if he have already use
JMeter with G1 GC to help us with the parameters.

I am still waiting his answer

Antonio

2017-01-17 20:34 GMT+01:00 Philippe Mouawad <ph...@gmail.com>:

> Hello Rainer,
> Nice to see you back among us and Happy new year !
>
> Good catch , thanks
> Regards
>
> On Tue, Jan 17, 2017 at 7:08 PM, Rainer Jung <ra...@kippdata.de>
> wrote:
>
> > Hi there,
> >
> >
> > Am 16.01.2017 um 22:27 schrieb pmouawad@apache.org:
> >
> >> Author: pmouawad
> >> Date: Mon Jan 16 21:27:21 2017
> >> New Revision: 1779108
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1779108&view=rev
> >> Log:
> >> Bug 60593 - Switch to G1 GC algorithm
> >> Bugzilla Id: 60593
> >>
> >> Modified:
> >>     jmeter/trunk/bin/jmeter
> >>     jmeter/trunk/bin/jmeter.bat
> >>     jmeter/trunk/xdocs/changes.xml
> >>
> >> Modified: jmeter/trunk/bin/jmeter
> >> URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter?rev=177
> >> 9108&r1=1779107&r2=1779108&view=diff
> >> ============================================================
> >> ==================
> >> --- jmeter/trunk/bin/jmeter (original)
> >> +++ jmeter/trunk/bin/jmeter Mon Jan 16 21:27:21 2017
> >> @@ -67,10 +67,7 @@ done
> >>
> >>  PRGDIR=`dirname "$PRG"`
> >>
> >> -# The following should be reasonably good values for most tests running
> >> -# on Sun JVMs. Following is the analysis on which it is based. If it's
> >> total
> >> -# gibberish to you, please study my article at
> >> -# http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_
> >> gear_id=1100010&detailArticle=true&id=9606
> >> +#
> >>  # Original page has disappeared, it is now only available at:
> >>  # https://web.archive.org/web/20060614151434/http://www.atg.co
> >> m/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&
> >> detailArticle=true&id=9606
> >>  #
> >> @@ -90,36 +87,18 @@ PRGDIR=`dirname "$PRG"`
> >>  # system's memory availability:
> >>  HEAP="-Xms512m -Xmx512m"
> >>
> >> -# There's an awful lot of per-sample objects allocated during test run,
> >> so we
> >> -# need a large eden to avoid too frequent scavenges -- you'll need to
> >> tune this
> >> -# down proportionally if you modify the HEAP values above, below
> example
> >> is fine for 512m of Heap:
> >> -# NEW="-XX:NewSize=128m -XX:MaxNewSize=128m"
> >> -
> >> -# This ratio and target have been proven OK in tests with a specially
> >> high
> >> -# amount of per-sample objects (the HtmlParserHTMLParser tests):
> >> -# SURVIVOR="-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50"
> >> -
> >> -# Think about it: trying to keep per-run objects in tenuring definitely
> >> -# represents a cost, but where's the benefit? They won't disappear
> before
> >> -# the test is over, and at that point we will no longer care about
> >> performance.
> >> -#
> >> -# So we will have JMeter do an explicit Full GC before starting a test
> >> run,
> >> -# but then we won't make any effort (or spend any CPU) to keep objects
> >> -# in tenuring longer than the life of per-sample objects -- which is
> >> hopefully
> >> -# shorter than the period between two scavenges):
> >> -#
> >> -TENURING="-XX:MaxTenuringThreshold=2"
> >> -
> >> -CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
> >> +#VERBOSE_GC="-verbose:gc -Xloggc:gc_jmeter_%p.log -XX:+PrintGCDetails
> >> -XX:+PrintGCCause -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC
> >> -XX:+PrintGCApplicationConcurrentTime -XX:+
> PrintGCApplicationStoppedTime
> >> -XX:+PrintGCDateStamps"
> >>
> >>  # Finally, some tracing to help in case things go astray:
> >> -#DEBUG="-verbose:gc -XX:+PrintTenuringDistribution"
> >> +GC_ALGO="-XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:G1ReservePercent=20"
> >> +
> >> +CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
> >>
> >
> > I think CMS class unloading doesn't make sense in combination with G1.
> CMS
> > (concurrent Mark Sweep) is an alternative collector which can be used
> > instead of G1. IMHO we should drop this variable ...
> >
> >  # Always dump on OOM (does not cost anything unless triggered)
> >>  DUMP="-XX:+HeapDumpOnOutOfMemoryError"
> >>
> >>  SERVER="-server"
> >>
> >> -ARGS="$SERVER $DUMP $HEAP $NEW $SURVIVOR $TENURING $PERM $CLASS_UNLOAD"
> >> +ARGS="$SERVER $DUMP $HEAP $CLASS_UNLOAD $VERBOSE_GC $GC_ALGO"
> >>
> >
> > ... and remove it from ARGS
> >
> >
> >  java $ARGS $JVM_ARGS $JMETER_OPTS -jar "$PRGDIR/ApacheJMeter.jar" "$@"
> >>
> >> Modified: jmeter/trunk/bin/jmeter.bat
> >> URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.bat?rev
> >> =1779108&r1=1779107&r2=1779108&view=diff
> >> ============================================================
> >> ==================
> >> --- jmeter/trunk/bin/jmeter.bat (original)
> >> +++ jmeter/trunk/bin/jmeter.bat Mon Jan 16 21:27:21 2017
> >> @@ -71,31 +71,24 @@ rem On NT/2K grab all arguments at once
> >>  set JMETER_CMD_LINE_ARGS=%*
> >>
> >>  rem The following link describes the -XX options:
> >> -rem http://www.oracle.com/technetwork/java/javase/tech/vmoptions
> >> -jsp-140102.html
> >> -rem http://java.sun.com/developer/TechTips/2000/tt1222.html has some
> >> more descriptions
> >> -rem Unfortunately TechTips no longer seem to be available, except via:
> >> -rem https://web.archive.org/web/20090614101951/http://java.sun.
> >> com/developer/TechTips/2000/tt1222.html
> >> +rem http://docs.oracle.com/javase/8/docs/technotes/tools/unix/
> java.html
> >>
> >>  rem See the unix startup file for the rationale of the following
> >> parameters,
> >>  rem including some tuning recommendations
> >>  set HEAP=-Xms512m -Xmx512m
> >> -set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
> >> -set SURVIVOR=-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50%
> >> -set TENURING=-XX:MaxTenuringThreshold=2
> >> -rem Java 8 remove Permanent generation, don't settings the PermSize
> >> -if %current_minor% LEQ "8" (
> >> -    rem Increase MaxPermSize if you use a lot of Javascript in your
> Test
> >> Plan :
> >> -    set PERM=-XX:PermSize=64m -XX:MaxPermSize=128m
> >> -)
> >> +
> >> +#Uncomment this to generate GC verbose file
> >> +rem set VERBOSE_GC=-verbose:gc -Xloggc:gc_jmeter_%p.log
> >> -XX:+PrintGCDetails -XX:+PrintGCCause -XX:+PrintTenuringDistribution
> >> -XX:+PrintHeapAtGC -XX:+PrintGCApplicationConcurrentTime
> >> -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps
> >> +
> >> +set GC_ALGO=-XX:+UseG1GC -XX:MaxGCPauseMillis=250
> -XX:G1ReservePercent=20
> >>
> >>  set CLASS_UNLOAD=-XX:+CMSClassUnloadingEnabled
> >>
> >
> > Same here ...
> >
> > -rem set DEBUG=-verbose:gc -XX:+PrintTenuringDistribution
> >>
> >>  rem Always dump on OOM (does not cost anything unless triggered)
> >>  set DUMP=-XX:+HeapDumpOnOutOfMemoryError
> >>
> >>  rem Additional settings that might help improve GUI performance on some
> >> platforms
> >> -rem See: http://java.sun.com/products/java-media/2D/perf_graphics.html
> >> +rem See: http://www.oracle.com/technetwork/java/perf-graphics-135933.
> >> html
> >>
> >>  set DDRAW=
> >>  rem  Setting this flag to true turns off DirectDraw usage, which
> >> sometimes helps to get rid of a lot of rendering problems on Win32.
> >> @@ -109,7 +102,7 @@ rem set DDRAW=%DDRAW% -Dsun.java2d.ddsca
> >>
> >>  rem Server mode
> >>  rem Collect the settings defined above
> >> -set ARGS=%DUMP% %HEAP% %NEW% %SURVIVOR% %TENURING% %PERM%
> %CLASS_UNLOAD%
> >> %DDRAW%
> >> +set ARGS=%DUMP% %HEAP% %CLASS_UNLOAD% %VERBOSE_GC% %GC_ALGO% %DDRAW%
> >>
> >
> > ... and here
> >
> >  %JM_START% %JM_LAUNCH% %ARGS% %JVM_ARGS% -jar
> >> "%JMETER_BIN%ApacheJMeter.jar" %JMETER_CMD_LINE_ARGS%
> >>
> >>
> >> Modified: jmeter/trunk/xdocs/changes.xml
> >> URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?
> >> rev=1779108&r1=1779107&r2=1779108&view=diff
> >> ============================================================
> >> ==================
> >> --- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
> >> +++ jmeter/trunk/xdocs/changes.xml [utf-8] Mon Jan 16 21:27:21 2017
> >> @@ -153,6 +153,7 @@ JMeter now requires Java 8. Ensure you u
> >>      <li><bug>54525</bug>Search Feature : Enhance it with ability to
> >> replace</li>
> >>      <li><bug>60530</bug>Add API to create JMeter threads while test is
> >> running. Based on a contribution by Logan Mauzaize (logan.mauzaize at
> >> gmail.com) and Maxime Chassagneux (maxime.chassagneux at gmail.com
> ).</li>
> >>      <li><bug>60514</bug>Ability to apply a naming convention on
> Children
> >> of a Transaction Controller. Contributed by Ubik Load Pack (support at
> >> ubikloadpack.com)</li>
> >> +    <li><bug>60593</bug>Switch to G1 GC algorithm</li>
> >>  </ul>
> >>
> >>  <ch_section>Non-functional changes</ch_section>
> >>
> >
> > Regards,
> >
> > Rainer
> >
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

Re: svn commit: r1779108 - in /jmeter/trunk: bin/jmeter bin/jmeter.bat xdocs/changes.xml

Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Rainer,
Nice to see you back among us and Happy new year !

Good catch , thanks
Regards

On Tue, Jan 17, 2017 at 7:08 PM, Rainer Jung <ra...@kippdata.de>
wrote:

> Hi there,
>
>
> Am 16.01.2017 um 22:27 schrieb pmouawad@apache.org:
>
>> Author: pmouawad
>> Date: Mon Jan 16 21:27:21 2017
>> New Revision: 1779108
>>
>> URL: http://svn.apache.org/viewvc?rev=1779108&view=rev
>> Log:
>> Bug 60593 - Switch to G1 GC algorithm
>> Bugzilla Id: 60593
>>
>> Modified:
>>     jmeter/trunk/bin/jmeter
>>     jmeter/trunk/bin/jmeter.bat
>>     jmeter/trunk/xdocs/changes.xml
>>
>> Modified: jmeter/trunk/bin/jmeter
>> URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter?rev=177
>> 9108&r1=1779107&r2=1779108&view=diff
>> ============================================================
>> ==================
>> --- jmeter/trunk/bin/jmeter (original)
>> +++ jmeter/trunk/bin/jmeter Mon Jan 16 21:27:21 2017
>> @@ -67,10 +67,7 @@ done
>>
>>  PRGDIR=`dirname "$PRG"`
>>
>> -# The following should be reasonably good values for most tests running
>> -# on Sun JVMs. Following is the analysis on which it is based. If it's
>> total
>> -# gibberish to you, please study my article at
>> -# http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_
>> gear_id=1100010&detailArticle=true&id=9606
>> +#
>>  # Original page has disappeared, it is now only available at:
>>  # https://web.archive.org/web/20060614151434/http://www.atg.co
>> m/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&
>> detailArticle=true&id=9606
>>  #
>> @@ -90,36 +87,18 @@ PRGDIR=`dirname "$PRG"`
>>  # system's memory availability:
>>  HEAP="-Xms512m -Xmx512m"
>>
>> -# There's an awful lot of per-sample objects allocated during test run,
>> so we
>> -# need a large eden to avoid too frequent scavenges -- you'll need to
>> tune this
>> -# down proportionally if you modify the HEAP values above, below example
>> is fine for 512m of Heap:
>> -# NEW="-XX:NewSize=128m -XX:MaxNewSize=128m"
>> -
>> -# This ratio and target have been proven OK in tests with a specially
>> high
>> -# amount of per-sample objects (the HtmlParserHTMLParser tests):
>> -# SURVIVOR="-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50"
>> -
>> -# Think about it: trying to keep per-run objects in tenuring definitely
>> -# represents a cost, but where's the benefit? They won't disappear before
>> -# the test is over, and at that point we will no longer care about
>> performance.
>> -#
>> -# So we will have JMeter do an explicit Full GC before starting a test
>> run,
>> -# but then we won't make any effort (or spend any CPU) to keep objects
>> -# in tenuring longer than the life of per-sample objects -- which is
>> hopefully
>> -# shorter than the period between two scavenges):
>> -#
>> -TENURING="-XX:MaxTenuringThreshold=2"
>> -
>> -CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
>> +#VERBOSE_GC="-verbose:gc -Xloggc:gc_jmeter_%p.log -XX:+PrintGCDetails
>> -XX:+PrintGCCause -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC
>> -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime
>> -XX:+PrintGCDateStamps"
>>
>>  # Finally, some tracing to help in case things go astray:
>> -#DEBUG="-verbose:gc -XX:+PrintTenuringDistribution"
>> +GC_ALGO="-XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:G1ReservePercent=20"
>> +
>> +CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
>>
>
> I think CMS class unloading doesn't make sense in combination with G1. CMS
> (concurrent Mark Sweep) is an alternative collector which can be used
> instead of G1. IMHO we should drop this variable ...
>
>  # Always dump on OOM (does not cost anything unless triggered)
>>  DUMP="-XX:+HeapDumpOnOutOfMemoryError"
>>
>>  SERVER="-server"
>>
>> -ARGS="$SERVER $DUMP $HEAP $NEW $SURVIVOR $TENURING $PERM $CLASS_UNLOAD"
>> +ARGS="$SERVER $DUMP $HEAP $CLASS_UNLOAD $VERBOSE_GC $GC_ALGO"
>>
>
> ... and remove it from ARGS
>
>
>  java $ARGS $JVM_ARGS $JMETER_OPTS -jar "$PRGDIR/ApacheJMeter.jar" "$@"
>>
>> Modified: jmeter/trunk/bin/jmeter.bat
>> URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.bat?rev
>> =1779108&r1=1779107&r2=1779108&view=diff
>> ============================================================
>> ==================
>> --- jmeter/trunk/bin/jmeter.bat (original)
>> +++ jmeter/trunk/bin/jmeter.bat Mon Jan 16 21:27:21 2017
>> @@ -71,31 +71,24 @@ rem On NT/2K grab all arguments at once
>>  set JMETER_CMD_LINE_ARGS=%*
>>
>>  rem The following link describes the -XX options:
>> -rem http://www.oracle.com/technetwork/java/javase/tech/vmoptions
>> -jsp-140102.html
>> -rem http://java.sun.com/developer/TechTips/2000/tt1222.html has some
>> more descriptions
>> -rem Unfortunately TechTips no longer seem to be available, except via:
>> -rem https://web.archive.org/web/20090614101951/http://java.sun.
>> com/developer/TechTips/2000/tt1222.html
>> +rem http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>>
>>  rem See the unix startup file for the rationale of the following
>> parameters,
>>  rem including some tuning recommendations
>>  set HEAP=-Xms512m -Xmx512m
>> -set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
>> -set SURVIVOR=-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50%
>> -set TENURING=-XX:MaxTenuringThreshold=2
>> -rem Java 8 remove Permanent generation, don't settings the PermSize
>> -if %current_minor% LEQ "8" (
>> -    rem Increase MaxPermSize if you use a lot of Javascript in your Test
>> Plan :
>> -    set PERM=-XX:PermSize=64m -XX:MaxPermSize=128m
>> -)
>> +
>> +#Uncomment this to generate GC verbose file
>> +rem set VERBOSE_GC=-verbose:gc -Xloggc:gc_jmeter_%p.log
>> -XX:+PrintGCDetails -XX:+PrintGCCause -XX:+PrintTenuringDistribution
>> -XX:+PrintHeapAtGC -XX:+PrintGCApplicationConcurrentTime
>> -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps
>> +
>> +set GC_ALGO=-XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:G1ReservePercent=20
>>
>>  set CLASS_UNLOAD=-XX:+CMSClassUnloadingEnabled
>>
>
> Same here ...
>
> -rem set DEBUG=-verbose:gc -XX:+PrintTenuringDistribution
>>
>>  rem Always dump on OOM (does not cost anything unless triggered)
>>  set DUMP=-XX:+HeapDumpOnOutOfMemoryError
>>
>>  rem Additional settings that might help improve GUI performance on some
>> platforms
>> -rem See: http://java.sun.com/products/java-media/2D/perf_graphics.html
>> +rem See: http://www.oracle.com/technetwork/java/perf-graphics-135933.
>> html
>>
>>  set DDRAW=
>>  rem  Setting this flag to true turns off DirectDraw usage, which
>> sometimes helps to get rid of a lot of rendering problems on Win32.
>> @@ -109,7 +102,7 @@ rem set DDRAW=%DDRAW% -Dsun.java2d.ddsca
>>
>>  rem Server mode
>>  rem Collect the settings defined above
>> -set ARGS=%DUMP% %HEAP% %NEW% %SURVIVOR% %TENURING% %PERM% %CLASS_UNLOAD%
>> %DDRAW%
>> +set ARGS=%DUMP% %HEAP% %CLASS_UNLOAD% %VERBOSE_GC% %GC_ALGO% %DDRAW%
>>
>
> ... and here
>
>  %JM_START% %JM_LAUNCH% %ARGS% %JVM_ARGS% -jar
>> "%JMETER_BIN%ApacheJMeter.jar" %JMETER_CMD_LINE_ARGS%
>>
>>
>> Modified: jmeter/trunk/xdocs/changes.xml
>> URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?
>> rev=1779108&r1=1779107&r2=1779108&view=diff
>> ============================================================
>> ==================
>> --- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
>> +++ jmeter/trunk/xdocs/changes.xml [utf-8] Mon Jan 16 21:27:21 2017
>> @@ -153,6 +153,7 @@ JMeter now requires Java 8. Ensure you u
>>      <li><bug>54525</bug>Search Feature : Enhance it with ability to
>> replace</li>
>>      <li><bug>60530</bug>Add API to create JMeter threads while test is
>> running. Based on a contribution by Logan Mauzaize (logan.mauzaize at
>> gmail.com) and Maxime Chassagneux (maxime.chassagneux at gmail.com).</li>
>>      <li><bug>60514</bug>Ability to apply a naming convention on Children
>> of a Transaction Controller. Contributed by Ubik Load Pack (support at
>> ubikloadpack.com)</li>
>> +    <li><bug>60593</bug>Switch to G1 GC algorithm</li>
>>  </ul>
>>
>>  <ch_section>Non-functional changes</ch_section>
>>
>
> Regards,
>
> Rainer
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: svn commit: r1779108 - in /jmeter/trunk: bin/jmeter bin/jmeter.bat xdocs/changes.xml

Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
Hi,

I am agree with you

I will commit it

Antonio

2017-01-17 19:08 GMT+01:00 Rainer Jung <ra...@kippdata.de>:

> Hi there,
>
> Am 16.01.2017 um 22:27 schrieb pmouawad@apache.org:
>
>> Author: pmouawad
>> Date: Mon Jan 16 21:27:21 2017
>> New Revision: 1779108
>>
>> URL: http://svn.apache.org/viewvc?rev=1779108&view=rev
>> Log:
>> Bug 60593 - Switch to G1 GC algorithm
>> Bugzilla Id: 60593
>>
>> Modified:
>>     jmeter/trunk/bin/jmeter
>>     jmeter/trunk/bin/jmeter.bat
>>     jmeter/trunk/xdocs/changes.xml
>>
>> Modified: jmeter/trunk/bin/jmeter
>> URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter?rev=177
>> 9108&r1=1779107&r2=1779108&view=diff
>> ============================================================
>> ==================
>> --- jmeter/trunk/bin/jmeter (original)
>> +++ jmeter/trunk/bin/jmeter Mon Jan 16 21:27:21 2017
>> @@ -67,10 +67,7 @@ done
>>
>>  PRGDIR=`dirname "$PRG"`
>>
>> -# The following should be reasonably good values for most tests running
>> -# on Sun JVMs. Following is the analysis on which it is based. If it's
>> total
>> -# gibberish to you, please study my article at
>> -# http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_
>> gear_id=1100010&detailArticle=true&id=9606
>> +#
>>  # Original page has disappeared, it is now only available at:
>>  # https://web.archive.org/web/20060614151434/http://www.atg.co
>> m/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&
>> detailArticle=true&id=9606
>>  #
>> @@ -90,36 +87,18 @@ PRGDIR=`dirname "$PRG"`
>>  # system's memory availability:
>>  HEAP="-Xms512m -Xmx512m"
>>
>> -# There's an awful lot of per-sample objects allocated during test run,
>> so we
>> -# need a large eden to avoid too frequent scavenges -- you'll need to
>> tune this
>> -# down proportionally if you modify the HEAP values above, below example
>> is fine for 512m of Heap:
>> -# NEW="-XX:NewSize=128m -XX:MaxNewSize=128m"
>> -
>> -# This ratio and target have been proven OK in tests with a specially
>> high
>> -# amount of per-sample objects (the HtmlParserHTMLParser tests):
>> -# SURVIVOR="-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50"
>> -
>> -# Think about it: trying to keep per-run objects in tenuring definitely
>> -# represents a cost, but where's the benefit? They won't disappear before
>> -# the test is over, and at that point we will no longer care about
>> performance.
>> -#
>> -# So we will have JMeter do an explicit Full GC before starting a test
>> run,
>> -# but then we won't make any effort (or spend any CPU) to keep objects
>> -# in tenuring longer than the life of per-sample objects -- which is
>> hopefully
>> -# shorter than the period between two scavenges):
>> -#
>> -TENURING="-XX:MaxTenuringThreshold=2"
>> -
>> -CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
>> +#VERBOSE_GC="-verbose:gc -Xloggc:gc_jmeter_%p.log -XX:+PrintGCDetails
>> -XX:+PrintGCCause -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC
>> -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime
>> -XX:+PrintGCDateStamps"
>>
>>  # Finally, some tracing to help in case things go astray:
>> -#DEBUG="-verbose:gc -XX:+PrintTenuringDistribution"
>> +GC_ALGO="-XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:G1ReservePercent=20"
>> +
>> +CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
>>
>
> I think CMS class unloading doesn't make sense in combination with G1. CMS
> (concurrent Mark Sweep) is an alternative collector which can be used
> instead of G1. IMHO we should drop this variable ...
>
>  # Always dump on OOM (does not cost anything unless triggered)
>>  DUMP="-XX:+HeapDumpOnOutOfMemoryError"
>>
>>  SERVER="-server"
>>
>> -ARGS="$SERVER $DUMP $HEAP $NEW $SURVIVOR $TENURING $PERM $CLASS_UNLOAD"
>> +ARGS="$SERVER $DUMP $HEAP $CLASS_UNLOAD $VERBOSE_GC $GC_ALGO"
>>
>
> ... and remove it from ARGS
>
>  java $ARGS $JVM_ARGS $JMETER_OPTS -jar "$PRGDIR/ApacheJMeter.jar" "$@"
>>
>> Modified: jmeter/trunk/bin/jmeter.bat
>> URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.bat?rev
>> =1779108&r1=1779107&r2=1779108&view=diff
>> ============================================================
>> ==================
>> --- jmeter/trunk/bin/jmeter.bat (original)
>> +++ jmeter/trunk/bin/jmeter.bat Mon Jan 16 21:27:21 2017
>> @@ -71,31 +71,24 @@ rem On NT/2K grab all arguments at once
>>  set JMETER_CMD_LINE_ARGS=%*
>>
>>  rem The following link describes the -XX options:
>> -rem http://www.oracle.com/technetwork/java/javase/tech/vmoptions
>> -jsp-140102.html
>> -rem http://java.sun.com/developer/TechTips/2000/tt1222.html has some
>> more descriptions
>> -rem Unfortunately TechTips no longer seem to be available, except via:
>> -rem https://web.archive.org/web/20090614101951/http://java.sun.
>> com/developer/TechTips/2000/tt1222.html
>> +rem http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>>
>>  rem See the unix startup file for the rationale of the following
>> parameters,
>>  rem including some tuning recommendations
>>  set HEAP=-Xms512m -Xmx512m
>> -set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
>> -set SURVIVOR=-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50%
>> -set TENURING=-XX:MaxTenuringThreshold=2
>> -rem Java 8 remove Permanent generation, don't settings the PermSize
>> -if %current_minor% LEQ "8" (
>> -    rem Increase MaxPermSize if you use a lot of Javascript in your Test
>> Plan :
>> -    set PERM=-XX:PermSize=64m -XX:MaxPermSize=128m
>> -)
>> +
>> +#Uncomment this to generate GC verbose file
>> +rem set VERBOSE_GC=-verbose:gc -Xloggc:gc_jmeter_%p.log
>> -XX:+PrintGCDetails -XX:+PrintGCCause -XX:+PrintTenuringDistribution
>> -XX:+PrintHeapAtGC -XX:+PrintGCApplicationConcurrentTime
>> -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps
>> +
>> +set GC_ALGO=-XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:G1ReservePercent=20
>>
>>  set CLASS_UNLOAD=-XX:+CMSClassUnloadingEnabled
>>
>
> Same here ...
>
> -rem set DEBUG=-verbose:gc -XX:+PrintTenuringDistribution
>>
>>  rem Always dump on OOM (does not cost anything unless triggered)
>>  set DUMP=-XX:+HeapDumpOnOutOfMemoryError
>>
>>  rem Additional settings that might help improve GUI performance on some
>> platforms
>> -rem See: http://java.sun.com/products/java-media/2D/perf_graphics.html
>> +rem See: http://www.oracle.com/technetwork/java/perf-graphics-135933.
>> html
>>
>>  set DDRAW=
>>  rem  Setting this flag to true turns off DirectDraw usage, which
>> sometimes helps to get rid of a lot of rendering problems on Win32.
>> @@ -109,7 +102,7 @@ rem set DDRAW=%DDRAW% -Dsun.java2d.ddsca
>>
>>  rem Server mode
>>  rem Collect the settings defined above
>> -set ARGS=%DUMP% %HEAP% %NEW% %SURVIVOR% %TENURING% %PERM% %CLASS_UNLOAD%
>> %DDRAW%
>> +set ARGS=%DUMP% %HEAP% %CLASS_UNLOAD% %VERBOSE_GC% %GC_ALGO% %DDRAW%
>>
>
> ... and here
>
>  %JM_START% %JM_LAUNCH% %ARGS% %JVM_ARGS% -jar
>> "%JMETER_BIN%ApacheJMeter.jar" %JMETER_CMD_LINE_ARGS%
>>
>>
>> Modified: jmeter/trunk/xdocs/changes.xml
>> URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?
>> rev=1779108&r1=1779107&r2=1779108&view=diff
>> ============================================================
>> ==================
>> --- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
>> +++ jmeter/trunk/xdocs/changes.xml [utf-8] Mon Jan 16 21:27:21 2017
>> @@ -153,6 +153,7 @@ JMeter now requires Java 8. Ensure you u
>>      <li><bug>54525</bug>Search Feature : Enhance it with ability to
>> replace</li>
>>      <li><bug>60530</bug>Add API to create JMeter threads while test is
>> running. Based on a contribution by Logan Mauzaize (logan.mauzaize at
>> gmail.com) and Maxime Chassagneux (maxime.chassagneux at gmail.com).</li>
>>      <li><bug>60514</bug>Ability to apply a naming convention on Children
>> of a Transaction Controller. Contributed by Ubik Load Pack (support at
>> ubikloadpack.com)</li>
>> +    <li><bug>60593</bug>Switch to G1 GC algorithm</li>
>>  </ul>
>>
>>  <ch_section>Non-functional changes</ch_section>
>>
>
> Regards,
>
> Rainer
>
>

Re: svn commit: r1779108 - in /jmeter/trunk: bin/jmeter bin/jmeter.bat xdocs/changes.xml

Posted by Rainer Jung <ra...@kippdata.de>.
Hi there,

Am 16.01.2017 um 22:27 schrieb pmouawad@apache.org:
> Author: pmouawad
> Date: Mon Jan 16 21:27:21 2017
> New Revision: 1779108
>
> URL: http://svn.apache.org/viewvc?rev=1779108&view=rev
> Log:
> Bug 60593 - Switch to G1 GC algorithm
> Bugzilla Id: 60593
>
> Modified:
>     jmeter/trunk/bin/jmeter
>     jmeter/trunk/bin/jmeter.bat
>     jmeter/trunk/xdocs/changes.xml
>
> Modified: jmeter/trunk/bin/jmeter
> URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter?rev=1779108&r1=1779107&r2=1779108&view=diff
> ==============================================================================
> --- jmeter/trunk/bin/jmeter (original)
> +++ jmeter/trunk/bin/jmeter Mon Jan 16 21:27:21 2017
> @@ -67,10 +67,7 @@ done
>
>  PRGDIR=`dirname "$PRG"`
>
> -# The following should be reasonably good values for most tests running
> -# on Sun JVMs. Following is the analysis on which it is based. If it's total
> -# gibberish to you, please study my article at
> -# http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&detailArticle=true&id=9606
> +#
>  # Original page has disappeared, it is now only available at:
>  # https://web.archive.org/web/20060614151434/http://www.atg.com/portal/myatg/developer?paf_dm=full&paf_gear_id=1100010&detailArticle=true&id=9606
>  #
> @@ -90,36 +87,18 @@ PRGDIR=`dirname "$PRG"`
>  # system's memory availability:
>  HEAP="-Xms512m -Xmx512m"
>
> -# There's an awful lot of per-sample objects allocated during test run, so we
> -# need a large eden to avoid too frequent scavenges -- you'll need to tune this
> -# down proportionally if you modify the HEAP values above, below example is fine for 512m of Heap:
> -# NEW="-XX:NewSize=128m -XX:MaxNewSize=128m"
> -
> -# This ratio and target have been proven OK in tests with a specially high
> -# amount of per-sample objects (the HtmlParserHTMLParser tests):
> -# SURVIVOR="-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50"
> -
> -# Think about it: trying to keep per-run objects in tenuring definitely
> -# represents a cost, but where's the benefit? They won't disappear before
> -# the test is over, and at that point we will no longer care about performance.
> -#
> -# So we will have JMeter do an explicit Full GC before starting a test run,
> -# but then we won't make any effort (or spend any CPU) to keep objects
> -# in tenuring longer than the life of per-sample objects -- which is hopefully
> -# shorter than the period between two scavenges):
> -#
> -TENURING="-XX:MaxTenuringThreshold=2"
> -
> -CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"
> +#VERBOSE_GC="-verbose:gc -Xloggc:gc_jmeter_%p.log -XX:+PrintGCDetails -XX:+PrintGCCause -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps"
>
>  # Finally, some tracing to help in case things go astray:
> -#DEBUG="-verbose:gc -XX:+PrintTenuringDistribution"
> +GC_ALGO="-XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:G1ReservePercent=20"
> +
> +CLASS_UNLOAD="-XX:+CMSClassUnloadingEnabled"

I think CMS class unloading doesn't make sense in combination with G1. 
CMS (concurrent Mark Sweep) is an alternative collector which can be 
used instead of G1. IMHO we should drop this variable ...

>  # Always dump on OOM (does not cost anything unless triggered)
>  DUMP="-XX:+HeapDumpOnOutOfMemoryError"
>
>  SERVER="-server"
>
> -ARGS="$SERVER $DUMP $HEAP $NEW $SURVIVOR $TENURING $PERM $CLASS_UNLOAD"
> +ARGS="$SERVER $DUMP $HEAP $CLASS_UNLOAD $VERBOSE_GC $GC_ALGO"

... and remove it from ARGS

>  java $ARGS $JVM_ARGS $JMETER_OPTS -jar "$PRGDIR/ApacheJMeter.jar" "$@"
>
> Modified: jmeter/trunk/bin/jmeter.bat
> URL: http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.bat?rev=1779108&r1=1779107&r2=1779108&view=diff
> ==============================================================================
> --- jmeter/trunk/bin/jmeter.bat (original)
> +++ jmeter/trunk/bin/jmeter.bat Mon Jan 16 21:27:21 2017
> @@ -71,31 +71,24 @@ rem On NT/2K grab all arguments at once
>  set JMETER_CMD_LINE_ARGS=%*
>
>  rem The following link describes the -XX options:
> -rem http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
> -rem http://java.sun.com/developer/TechTips/2000/tt1222.html has some more descriptions
> -rem Unfortunately TechTips no longer seem to be available, except via:
> -rem https://web.archive.org/web/20090614101951/http://java.sun.com/developer/TechTips/2000/tt1222.html
> +rem http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>
>  rem See the unix startup file for the rationale of the following parameters,
>  rem including some tuning recommendations
>  set HEAP=-Xms512m -Xmx512m
> -set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
> -set SURVIVOR=-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50%
> -set TENURING=-XX:MaxTenuringThreshold=2
> -rem Java 8 remove Permanent generation, don't settings the PermSize
> -if %current_minor% LEQ "8" (
> -    rem Increase MaxPermSize if you use a lot of Javascript in your Test Plan :
> -    set PERM=-XX:PermSize=64m -XX:MaxPermSize=128m
> -)
> +
> +#Uncomment this to generate GC verbose file
> +rem set VERBOSE_GC=-verbose:gc -Xloggc:gc_jmeter_%p.log -XX:+PrintGCDetails -XX:+PrintGCCause -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps
> +
> +set GC_ALGO=-XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:G1ReservePercent=20
>
>  set CLASS_UNLOAD=-XX:+CMSClassUnloadingEnabled

Same here ...

> -rem set DEBUG=-verbose:gc -XX:+PrintTenuringDistribution
>
>  rem Always dump on OOM (does not cost anything unless triggered)
>  set DUMP=-XX:+HeapDumpOnOutOfMemoryError
>
>  rem Additional settings that might help improve GUI performance on some platforms
> -rem See: http://java.sun.com/products/java-media/2D/perf_graphics.html
> +rem See: http://www.oracle.com/technetwork/java/perf-graphics-135933.html
>
>  set DDRAW=
>  rem  Setting this flag to true turns off DirectDraw usage, which sometimes helps to get rid of a lot of rendering problems on Win32.
> @@ -109,7 +102,7 @@ rem set DDRAW=%DDRAW% -Dsun.java2d.ddsca
>
>  rem Server mode
>  rem Collect the settings defined above
> -set ARGS=%DUMP% %HEAP% %NEW% %SURVIVOR% %TENURING% %PERM% %CLASS_UNLOAD% %DDRAW%
> +set ARGS=%DUMP% %HEAP% %CLASS_UNLOAD% %VERBOSE_GC% %GC_ALGO% %DDRAW%

... and here

>  %JM_START% %JM_LAUNCH% %ARGS% %JVM_ARGS% -jar "%JMETER_BIN%ApacheJMeter.jar" %JMETER_CMD_LINE_ARGS%
>
>
> Modified: jmeter/trunk/xdocs/changes.xml
> URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?rev=1779108&r1=1779107&r2=1779108&view=diff
> ==============================================================================
> --- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
> +++ jmeter/trunk/xdocs/changes.xml [utf-8] Mon Jan 16 21:27:21 2017
> @@ -153,6 +153,7 @@ JMeter now requires Java 8. Ensure you u
>      <li><bug>54525</bug>Search Feature : Enhance it with ability to replace</li>
>      <li><bug>60530</bug>Add API to create JMeter threads while test is running. Based on a contribution by Logan Mauzaize (logan.mauzaize at gmail.com) and Maxime Chassagneux (maxime.chassagneux at gmail.com).</li>
>      <li><bug>60514</bug>Ability to apply a naming convention on Children of a Transaction Controller. Contributed by Ubik Load Pack (support at ubikloadpack.com)</li>
> +    <li><bug>60593</bug>Switch to G1 GC algorithm</li>
>  </ul>
>
>  <ch_section>Non-functional changes</ch_section>

Regards,

Rainer