Several suggestions. 1. Adjust the traffic load for about 75% CPU. When you hit 100%, you are already in an overload state and the variance of the response times goes way up. You'll have very noisy benchmark data.
2. Do not force manual GCs during a benchmark. 3. Do not force merge (optimise). That is a very expensive operation and will cause slowdowns. 4. Make eden big enough to hold all data allocated during a request for all simultaneous requests. All that stuff is garbage after the end of the request. If eden fills up, it will be allocated from the tenured space and cause that to grow unnecessarily. We use an 8GB heap and 2GB eden. I like setting the size better than setting ratios. 5. What version of the JVM are you using? wunder On Nov 29, 2012, at 10:15 AM, Shawn Heisey wrote: > On 11/29/2012 10:44 AM, Andy Kershaw wrote: >> Annette is away until Monday so I am looking into this in the meantime. >> Looking at the times of the Full GC entries at the end of the log, I think >> they are collections we started manually through jconsole to try and reduce >> the size of the old generation. This only seemed to have an effect when we >> reloaded the core first though. >> >> It is my understanding that the eden size is deliberately smaller to keep >> the ParNew collection time down. If it takes too long then the node is >> flagged as down. > > Your ParNew collections are taking less than 1 second (some WAY less than one > second) to complete and the CMS collections are taking far longer -- 6 > seconds seems to be a common number in the GC log. GC is unavoidable with > Java, so if there has to be a collection, you definitely want it to be on the > young generation (ParNew). > > Controversial idea coming up, nothing concrete to back it up. This means > that you might want to wait for a committer to weigh in: I have seen a lot > of recent development work relating to SolrCloud and shard stability. You > may want to check out branch_4x from SVN and build that, rather than use 4.0. > I don't have any idea what the timeline for 4.1 is, but based on what I saw > for 3.x releases, it should be released relatively soon. > > The above advice is a bad idea if you have to be able to upgrade from one 4.1 > snapshot to a later one without reindexing. There is a possibility that the > 4.1 index format will change before release and require a reindex, it has > happened at least twice already. > > Thanks, > Shawn > -- Walter Underwood [email protected]
