My guess is system time is high either due to lock contention (too many parallel threads) or page faults.
Heap size was less than 6gb when this long pause occurred, and and young generation was less than 2gb. Though lowering heap size would help I don't think that is the root cause here On Dec 9, 2016 3:02 AM, "Ere Maijala" <ere.maij...@helsinki.fi> wrote: > Then again, if the load characteristics on the Solr instance differ e.g. > by time of day, G1GC, in my experience, may have trouble adapting. For > instance if your query load reduces drastically during the night, it may > take a while for G1GC to catch up in the morning. What I've found useful > from experience, and your mileage will probably vary, is to limit the young > generation size with a large heap. With Xmx31G something like these could > work: > > -XX:+UnlockExperimentalVMOptions \ > -XX:G1MaxNewSizePercent=5 \ > > The aim here is to only limit the maximum and still allow some adaptation. > > --Ere > > 8.12.2016, 16.07, Pushkar Raste kirjoitti: > >> Disable all the G1GC tuning your are doing except for >> ParallelRefProcEnabled >> >> G1GC is an adaptive algorithm and would keep tuning to reach the default >> pause goal of 250ms which should be good for most of the applications. >> >> Can you also tell us how much RAM you have on your machine and if you have >> swap enabled and being used? >> >> On Dec 8, 2016 8:53 AM, "forest_soup" <tanglin0...@gmail.com> wrote: >> >> Besides, will those JVM options make it better? >>> -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=10 >>> >>> >>> >>> -- >>> View this message in context: http://lucene.472066.n3. >>> nabble.com/Very-long-young-generation-stop-the-world-GC- >>> pause-tp4308911p4308937.html >>> Sent from the Solr - User mailing list archive at Nabble.com. >>> >>> >>
