jsalvata 2003/11/27 11:56:02 Modified: bin jmeter Log: Use more sensible JVM heap sizing & GC control parameters. Revision Changes Path 1.22 +61 -1 jakarta-jmeter/bin/jmeter Index: jmeter =================================================================== RCS file: /home/cvs/jakarta-jmeter/bin/jmeter,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- jmeter 1 May 2003 15:49:05 -0000 1.21 +++ jmeter 27 Nov 2003 19:56:02 -0000 1.22 @@ -1,3 +1,63 @@ #! /bin/sh -java -Xincgc -Xmx256m -jar `dirname $0`/ApacheJMeter.jar "$@" +# 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 +# +# JMeter objects can generally be grouped into three life-length groups: +# +# - Per-sample objects (results, DOMs,...). An awful lot of those. +# Life length of milliseconds to a few seconds. +# +# - Per-run objects (threads, listener data structures,...). Not that many +# of those unless we use the table or tree listeners on heavy runs. +# Life length of minutes to several hours, from creation to start of next run. +# +# - Per-work-session objects (test plans, GUIs,...). +# Life length: for the life of the JVM. + +# This is the base heap size -- you may increase or decrease it to fit your +# system's memory availablity: +HEAP="-Xms256m -Xmx256m" + +# 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: +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=80%" + +# 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" + +# This evacuation ratio is OK (see the comments for SURVIVOR) during test +# runs -- no so sure about operations that bring a lot of long-lived information into +# memory in a short period of time, such as loading tests or listener data files. +# Increase it if you experience OutOfMemory problems during those operations +# without having gone through a lot of Full GC-ing just before the OOM: +EVACUATION="-XX:MaxLiveObjectEvacuationRatio=20%" + +# Avoid the RMI-induced Full GCs to run too frequently -- once every ten minutes +# should be more than enough: +RMIGC="-Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000" + +# PermSize is a scam. Leave it like this: +PERM="-XX:PermSize=64m -XX:MaxPermSize=64m" + +# Finally, some tracing to help in case things go astray: +DEBUG="-verbose:gc -XX:+PrintTenuringDistribution" + +ARGS="$HEAP $NEW $SURVIVOR $TENURING $EVACUATION $RMIGC $PERM $DEBUG" + +java $ARGS -jar `dirname $0`/ApacheJMeter.jar "$@"
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
