On 26.07.2013 22:06, pmoua...@apache.org wrote: > Author: pmouawad > Date: Fri Jul 26 20:06:10 2013 > New Revision: 1507418 > > URL: http://svn.apache.org/r1507418 > Log: > Add a GC option for perm cleanup > Add explanation on NEW zone > > Modified: > jmeter/trunk/bin/jmeter > > Modified: jmeter/trunk/bin/jmeter > URL: > http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter?rev=1507418&r1=1507417&r2=1507418&view=diff > ============================================================================== > --- jmeter/trunk/bin/jmeter (original) > +++ jmeter/trunk/bin/jmeter Fri Jul 26 20:06:10 2013 > @@ -45,7 +45,7 @@ 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 reduce the HEAP values above: > +# down proportionally if you modify the HEAP values above: > NEW="-XX:NewSize=128m -XX:MaxNewSize=128m" > > # This ratio and target have been proven OK in tests with a specially high > @@ -75,7 +75,7 @@ TENURING="-XX:MaxTenuringThreshold=2" > RMIGC="-Dsun.rmi.dgc.client.gcInterval=600000 > -Dsun.rmi.dgc.server.gcInterval=600000" > > # Increase MaxPermSize if you use a lot of Javascript in your Test Plan : > -PERM="-XX:PermSize=64m -XX:MaxPermSize=128m" > +PERM="-XX:PermSize=64m -XX:MaxPermSize=128m -XX:+CMSClassUnloadingEnabled"
Note that the switch wouldn't do anything by default, because it only is effective is the user switches to CMS garbage collection (-XX:+UseConcMarkSweepGC). If CMS is not used, class unloading is default (boolean switch ClassUnloading). Fortunately the CMSClassUnloadingEnabled switch is simply ignored if CMS is not used. OTOH it also has a side effect: it will let the CMS check how much memory in the perm gen is free to decide whether it should run. By default it will run when perm is 92% filled. This can be changed with the CMSInitiatingPermOccupancyFraction switch. It can not only run when the perm gen is full, like he traditional compactifying GC, because it is expected to run concurrently with the application, so there must be some free space left to let the app run successfully until the CMS has freed up garbage. So as long as JMeter stays typically below 92% that's fine, but if it frequently goes to 92%, e.g. because it always needs 91% and quickly adds temporary classes which make up the last percent, that would result in frequent CMS runs. This is something to keep in mind. Should we provide a commented block of switch prepared for the CMS use? Regards, Rainer
