We are currently operating at reduced load which is why the ParNew collections are not a problem. I don't know how long they were taking before though. Thanks for the warning about index formats.
Our JVM is: Java(TM) SE Runtime Environment (build 1.7.0_09-b05) Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode) We are currently running more tests but it takes a while before the issues become apparent. Andy Kershaw On 29 November 2012 18:31, Walter Underwood <wun...@wunderwood.org> wrote: > 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 > wun...@wunderwood.org > > > > -- Andy Kershaw Technical Developer ServiceTick Ltd T: +44(0)1603 618326 M: +44 (0)7876 556833 Seebohm House, 2-4 Queen Street, Norwich, England, NR2 4SQ www.ServiceTick.com <http://www.servicetick.com/> www.SessionCam.com <http://www.sessioncam.com/> *This message is confidential and is intended to be read solely by the addressee. If you have received this message by mistake, please delete it and do not copy it to anyone else. Internet communications are not secure and may be intercepted or changed after they are sent. ServiceTick Ltd does not accept liability for any such changes.*
