[Solr Wiki] Update of "SolrPerformanceProblems" by ShawnHeisey

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "SolrPerformanceProblems" page has been changed by ShawnHeisey:
https://wiki.apache.org/solr/SolrPerformanceProblems?action=diff&rev1=10&rev2=11

Comment:
Updated info about G1 collector

  
  ==== GC pause problems ====
  
- When you have a large heap (about 4GB or larger), garbage collection pauses can be a major problem.  There are two main solutions.  One is to use a commercial low-pause JVM like [[http://www.azulsystems.com/products/zing/whatisit|Zing]], which does come with a price tag.  The other is to tune the JVM you've already got.  GC tuning is a precise art form, and what works for one person may not work for you.  Important note: Anecdotal evidence suggests that the G1 collector available in recent Java 6 and all Java 7 versions is not a good fit for Solr as of Java 7u21.  The CMS collector seems to be the right choice for Solr.  Here are some ideas that hopefully you will find helpful:
+ When you have a large heap (about 4GB or larger), garbage collection pauses can be a major problem.  This is usually caused by occasionally required full garbage collections that must "stop the world" -- pause all program execution to clean up memory.  There are two main solutions: One is to use a commercial low-pause JVM like [[http://www.azulsystems.com/products/zing/whatisit|Zing]], which does come with a price tag.  The other is to tune the free JVM you've already got.  GC tuning is an art form, and what works for one person may not work for you.
+ 
+ <!> The G1 garbage collector is often mentioned as an alternative for better GC performance.  The G1 collector was introduced in later Java 6 releases as an experimental feature and upgraded to a standard feature in Java 7.  Although the G1 collector does offer much faster collections on average, anecdotal evidence suggests that it doesn't really do anything about the occasional very long GC pause.  The [[ShawnHeisey|original author]] of this page saw *longer* stop-the-world pauses with G1 compared to un-tuned CMS.  The average collection time was dramatically improved, but the worst-case collections were longer.  If a good set of G1 tuning parameters can be found, it is likely that G1 will become a real contender.
+ 
+ Using the ConcurrentMarkSweep (CMS) collector with tuning parameters seems to the be right choice for Solr.  Here are some ideas that hopefully you will find helpful:
  
   * [[http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html|Oracle Java 6 GC tuning guide]]
   * [[ShawnHeisey#GC_Tuning|Author's GC tuning parameters]]
  
- Normal Solr operation creates a lot of short-lived objects, so having a young generation (eden) that's larger than the Java default is important.  Making eden too large can be a problem as well - the old (tenured) generation is also important.
+ Normal Solr operation creates a lot of short-lived objects, so having a young generation (eden) that's larger than the Java default is important.  Making eden too large can be a problem as well, because Solr does use longer-lived objects as well.  The old (tenured) generation is also important.
  
  If your max heap is just a little bit too small, you may end up with a slightly different garbage collection problem.  This problem is usually worse than the problems associated with a large heap:  Every time Solr wants to allocate memory for operation, it has to do a full garbage collection in order to free up enough memory to complete the allocation.