[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=55&rev2=56

Comment:
Added note from the mailing list about minimal query latency.  Thanks to Jack Krupansky.

  For index updates, Solr relies on fast bulk reads and writes. For search, fast random reads are essential. The best way to satisfy these requirements is to ensure that a large [[http://en.wikipedia.org/wiki/Page_cache|disk cache]] is available.  Visit [[http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html|Uwe's blog entry]] for some good Lucene/Solr specific information.  You can also utilize Solid State Drives to speed up Solr, but be aware that this is not a complete replacement for OS disk cache.  See the SSD section later in this document for more details.
  
  In a nutshell, you want to have enough memory available in the OS disk cache so that the important (frequently accessed) parts of your index will fit into the cache.  Let's say that you have a Solr index size of 8GB.  If your OS, Solr's Java heap, and all other running programs require 4GB of memory, then an '''ideal''' memory size for that server is at least 12GB.  You ''might'' be able to make it work with 8GB total memory (leaving 4GB for disk cache), but that also might NOT be enough.  The really important thing is to ensure that there is a high cache hit ratio on the OS disk cache ... not to achieve perfection.
+ 
+ If you need the your overall query latency to be as low as possible, your best bet is to have sufficient system memory to fully cache the entire index. If you don't need minimal latency, caching the entire index may not be necessary.
  
  The exact minimum requirements are highly variable and depend on things like your schema, your index contents, and your queries.  If your index has a lot of stored fields, those requirements would be on the smaller end of the scale.  If you have very little stored data, you would want to be on the higher end of the scale.  The size of stored data doesn't affect search speed very much, though it might affect how long it takes to retrieve the search results once the required documents have been determined.