Interesting. It seems to spend more time in GC, but the major GCs aren't any faster. They are more consistent.
I notice that SPM shows average collection time. This is not a particularly useful number. It should use median and percentiles. For a one-sided distribution, never use mean (average), always use median and percentiles. This is one of my basic tests for monitoring products. If they show averages for response time (or other durations), they are doing it wrong and need to learn more about statistics. wunder On Jun 24, 2013, at 8:59 AM, Otis Gospodnetic wrote: > And here is our most recent experience with G1, although not with > Solr, but with HBase: > > http://blog.sematext.com/2013/06/24/g1-cms-java-garbage-collector/ > > Otis > -- > Solr & ElasticSearch Support -- http://sematext.com/ > Performance Monitoring -- http://sematext.com/spm > > > > On Fri, Jun 21, 2013 at 11:33 AM, Walter Underwood > <wun...@wunderwood.org> wrote: >> On 6/20/2013 10:22 PM, William Bell wrote: >>> It would be good to see some CMS configs too... Can you send your java >>> params? >> >> Here is what we use in production. We run multiple collections with small >> documents. One is 3M docs, one is 9M, one is 2M, and the other three are >> small. We use Amazon m1.xlarge instances (4CPU, 15GB). >> >> These options were developed with our load test. That is based on a full day >> of queries. We use JMeter to send queries at a constant rate that takes the >> CPU to between 50% and 75% busy. We measure 95th and 99th percentiles for >> response time. >> >> We enable ExplicitGCInvokesConcurrent because some monitoring software was >> calling System.gc() to get accurate memory numbers. That was causing notable >> pauses in service and messing up our 99th percentile. Alternatively, you >> could disable those entirely with the flag DisableExplicitGC. >> >> The new size is large so that all the allocations needed to handle a single >> request can fit in new space. We really do not want per-request data being >> allocated in tenured space. New needs to be big enough to handle multiple >> simultaneous requests. >> >> export CATALINA_OPTS="$CATALINA_OPTS -d64" >> export CATALINA_OPTS="$CATALINA_OPTS -server" >> export CATALINA_OPTS="$CATALINA_OPTS -Xms8g" >> export CATALINA_OPTS="$CATALINA_OPTS -Xmx8g" >> export CATALINA_OPTS="$CATALINA_OPTS -XX:NewSize=2048m" >> export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxPermSize=256m" >> export CATALINA_OPTS="$CATALINA_OPTS -XX:+UseConcMarkSweepGC" >> export CATALINA_OPTS="$CATALINA_OPTS -XX:+UseParNewGC" >> export CATALINA_OPTS="$CATALINA_OPTS -XX:+ExplicitGCInvokesConcurrent" >> export CATALINA_OPTS="$CATALINA_OPTS -verbose:gc" >> export CATALINA_OPTS="$CATALINA_OPTS -XX:+PrintGCDetails" >> export CATALINA_OPTS="$CATALINA_OPTS -XX:+PrintGCTimeStamps" >> export CATALINA_OPTS="$CATALINA_OPTS -XX:-TraceClassUnloading" >> export CATALINA_OPTS="$CATALINA_OPTS -Xloggc:$CATALINA_HOME/logs/gc.log" >> export CATALINA_OPTS="$CATALINA_OPTS -XX:+HeapDumpOnOutOfMemoryError" >> export CATALINA_OPTS="$CATALINA_OPTS -XX:HeapDumpPath=$CATALINA_HOME/logs/" >> >> We used to include these options, but they default to enabled in Java 1.7 >> Update 17. >> >> -XX:+DoEscapeAnalysis >> -XX:+CMSParallelRemarkEnabled >> -XX:+UseCompressedOops >> >> wunder >> >> -- Walter Underwood wun...@wunderwood.org
