[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=67&rev2=68

Comment:
Some small edits to the SSD section.

  
  === SSD ===
  
- Solid State Disks are amazing.  They have high transfer rates and pretty much eliminate the latency problems associated with randomly accessing data.  If you put your index on solid state disks, performance will increase.  Sometimes the performance increase will be enormous, but if you are looking at SSD because your Solr server is having severe performance problems, there's a very good chance that switching to SSD will not help as much as you expect.
+ Solid State Disks are amazing.  They have high transfer rates and pretty much eliminate the latency problems associated with randomly accessing data.  If you put your index on a solid state disk, performance will be better than it would be on similar hardware with a standard spinning magnetic disk.  Sometimes the performance increase will be enormous, but if you are looking at SSD because your Solr server is having severe performance problems, there's a very good chance that switching to SSD will not help as much as you expect.
  
  Often SSD will be touted as a replacement for RAM used as disk cache.  This is both true and untrue.  Despite the incredible speed of SSD, RAM (the OS disk cache) is still significantly faster, and RAM still plays a big role in the performance of SSD-based systems.  You probably don't need as much RAM with SSD as you do with spinning disks, but you can't eliminate the requirement.  With spinning disks you need between 50 and 100 percent of your index size as cache.  With SSD, that might be 25 to 50 percent, less if your index is very small.
  
- Note that SSDs are still a young technology and that the amount of independent Solr-oriented performance tests is very limited. One such test indicates that a disk cache of only 10% index size might be enough for high search performance with SSDs. See [[https://sbdevel.wordpress.com/2013/06/06/memory-is-overrated/|Memory is overrated]].  Note that if your index has very few stored fields, 10% may not be enough.  If you have a lot of (or very large) stored fields, it might be.
+ Note that SSDs are still a young technology and that the amount of independent Solr-oriented performance tests is very limited. One such test indicates that a disk cache of only 10% index size might be enough for high search performance with SSDs. See [[https://sbdevel.wordpress.com/2013/06/06/memory-is-overrated/|Memory is overrated]].  Note that if your index has very few stored fields, 10% may not be enough.  If you have a lot of (or very large) stored fields, it might be.  Usually the only way to find out if your hardware is sized appropriately is to actually set up a system and try it.
  
  One potential problem with SSD is that operating system TRIM support is required for good long-term performance.  For single disks, TRIM is usually well supported, but if you want to add any kind of hardware RAID (and most software RAID as well), TRIM support disappears.   At the time of this writing, it seems that only Intel supports a solution and that is [[http://www.anandtech.com/show/6161/intel-brings-trim-to-raid0-ssd-arrays-on-7series-motherboards-we-test-it|limited to Windows 7 or later and RAID 0]].  One way to make this less of a problem with Solr is to put your OS and Solr itself on a RAID of regular disks, and put your index data on a lone SSD.  If the SSD fails, your redundant server(s) will still be there to handle requests.