solr性能调优

Schema Design Considerations

   indexed fields

    indexed fields 的数量将会影响如下的一些性能：

•         索引时的时候的内存使用量
•         索引段的合并时间
•         优化时间
•         索引的大小

     咱们能够经过 将 omitNorms=“true” 来减小indexed fields数量增长所带来的影响。

 

   stored fields

      Retrieving the stored fields  确实是一种开销。这个开销，受每一个文档所存储的字节影响很大。每一个文档的所占用的空间越大，文档就显的更稀疏，这样从硬盘中读取数据，就须要更多的i/o操做（一般，咱们在存储比较大的域的时候，就会考虑这样的事情，好比存储一篇文章的文档。）

       能够考虑将比较大的域放到solr外面来存储。若是你以为这样作会有些别扭的话，能够考虑使用压缩的域，可是这样会加剧cpu在存储和读取域的时候的负担。不过这样倒是能够较少i/0的负担。

       若是，你并非老是使用 stored fields 的话，可使用stored field的延迟加载，这样能够节省不少的性能，尤为是使用compressed field 的时候。

 

 Configuration Considerations

      mergeFactor

         这个是合并因子，这个参数大概决定了segment(索引段)的数量。

         合并因子这个值告诉lucene，在何时，要将几个segment合并成为一个segment, 合并因子就像是一个数字系统的基数同样。

 

         好比说，若是你将合并因子设成10，那么每往索引中添加1000个文档的时候，就会建立一个新的索引段。当第10个大小为1000的索引段添加进来的时候，这十个索引段就会被合并成一个大小为10，000的索引段。当十个大小为10，000的索引段生成的时候，它们就会被合并成一个大小为100，000的索引段。如此类推下去。

 

         这个值能够在 solrconfig.xml 中的 *mainIndex*中设置。（不用管indexDefaults中设置）

       mergeFactor Tradeoffs

         较高的合并因子

•         会提升索引速度
•         较低频率的合并，会致使 更多的索引文件，这会下降索引的搜索效率

          较低的合并因子

•         较少数量的索引文件，能加快索引的搜索速度。
•         较高频率的合并，会下降索引的速度。

Cache autoWarm Count Considerations

      当一个新的 searcher 打开的时候，它缓存能够被预热，或者说使用从旧的searcher的缓存的数据来“自动加热”。autowarmCount是这样的一个参数，它表示从旧缓存中拷贝到新缓存中的对象数量。autowarmCount这个参数将会影响“自动预热”的时间。有些时候，咱们须要一些折中的考虑，seacher启动的时间和缓存加热的程度。固然啦，缓存加热的程度越好，使用的时间就会越长，但每每，咱们并不但愿过长的seacher启动时间。这个autowarm 参数能够在solrconfig.xml文件中被设置。

       详细的配置能够参考solr的wiki。

Cache hit rate（缓存命中率）

       咱们能够经过solr的admin界面来查看缓存的状态信息。提升solr缓存的大小每每是提升性能的捷径。当你使用面搜索的时候，你或许能够注意一下filterCache,这个是由solr实现的缓存。

       详细的内容能够参考 solrCaching这篇wiki。

Explicit Warming of Sort Fields 

       若是你有许多域是基于排序的，那么你能够在"newSearcher"和"firstSearcher"event listeners中添加一些明显须要预热的查询，这样FieldCache 就会缓存这部份内容。

 Optimization Considerations

        优化索引，是咱们常常会作的事情，好比，当咱们创建好索引，而后这个索引不会再变动的状况，咱们就会作一次优化了。

        但，若是你的索引常常会改变，那么你就须要好好的考虑下面的因素的。

•        当愈来愈多的索引段被加进索引，查询的性能就会下降， lucene对索引段的数量有一个上限的限制，当超过这个限制的时候，索引段能够自动合并成为一个。
• 在一样没有缓存的状况下，一个没有通过优化的索引的性能会比通过优化的索引的性能少10%……
• 自动加热的时间将会变长，由于它依赖于搜索。
•  优化将会对索引的分发产生影响。
•  在优化期间，文件的大小将会是索引的两倍，不过最终将会回到它原来的大小，或者会更小一点。

      优化，会将全部的索引段合并成为一个索引段，因此，优化这个操做其实能够帮助避免“too many files”这个问题，这个错误是由文件系统抛出的。

Updates and Commit Frequency Tradeoffs

         若是从机太常常从主机更新的话，从机的性能是会受到影响的。为了不，因为这个问题而引发的性能降低，咱们还必须了解从机是怎样执行更新的，这样咱们才能更准确去调节一些相关的参数（commit的频率，spappullers,autowarming/autocount）,这样，从机的更新才不会太频繁。

1.      执行commit操做会让solr新生成一个snapshot。若是将postCommit参数设成true的话，optimization也会执行snapShot.
2.      slave上的Snappuller程序通常是在crontab上面执行的，它会去master询问，有没有新版的snapshot。一旦发现新的版本，slave就会把它下载下来，而后snapinstall.
3.      每次当一个新的searcher被open的时候，会有一个缓存预热的过程，预热以后，新的索引才会交付使用。

      这里讨论三个有关的参数：

•      number/frequency of snapshots  ----snapshot的频率。
•      snappullers 是  在crontab中的，它固然能够每秒一次、天天一次、或者其余的时间间隔一次运行。它运行的时候，只会下载slave上没有的，而且最新的版本。
•      Cache autowarming 能够在solrconfig.xml文件中配置。

           若是，你想要的效果是频繁的更新slave上的索引，以便这样看起来比较像“实时索引”。那么，你就须要让snapshot尽量频繁的运行，而后也让snappuller频繁的运行。这样，咱们或许能够每5分钟更新一次，而且还能取得不错的性能，固然啦，cach的命中率是很重要的，恩，缓存的加热时间也将会影响到更新的频繁度。

       cache对性能是很重要的。一方面，新的缓存必须拥有足够的缓存量，这样接下来的的查询才可以从缓存中受益。另外一方面，缓存的预热将可能占用很长一段时间，尤为是，它实际上是只使用一个线程，和一个cpu在工做。snapinstaller太频繁的话，solr slave将会处于一个不太理想的状态，可能它还在预热一个新的缓存，然而一个更新的searcher被opern了。

         怎么解决这样的一个问题呢，咱们可能会取消第一个seacher，而后去处理一个更新seacher，也便是第二个。然而有可能第二个seacher 尚未被使用上的时候，第三个又过来了。看吧，一个恶性的循环，不是。固然也有可能，咱们刚刚预热好的时候就开始新一轮的缓存预热，其实，这样缓存的做用压根就没有能体现出来。出现这种状况的时候，下降snapshot的频率才是硬道理。

    Query Response Compression

        在有些状况下，咱们能够考虑将solr xml response 压缩后才输出。若是response很是大，就会触及NIc i/o限制。

        固然压缩这个操做将会增长cpu的负担，其实，solr一个典型的依赖于cpu处理速度的服务，增长这个压缩的操做，将无疑会下降查询性能。可是，压缩后的数据将会是压缩前的数据的6分之一 的大小。然而solr的查询性能也会有15%左右的消耗。

       至于怎样配置这个功能，要看你使用的什么服务器而定，能够查阅相关的文档。

     Embedded vs HTTP Post

         使用embeded 来创建索引，将会比使用xml格式来创建索引快50%。

 

     RAM Usage Considerations（内存方面的考虑）

        OutOfMemoryErrors

           若是你的solr实例没有被指定足够多的内存的话，java virtual machine也许会抛outof memoryError，这个并不对索引数据产生影响。可是这个时候，任何的 adds/deletes/commits操做都是不可以成功的。

         Memory allocated to the Java VM

            最简单的解决这个方法就是，固然前提是java virtual machine 尚未使用掉你所有的内存，增长运行solr的java虚拟机的内存。

          

           Factors affecting memory usage（影响内存使用量的因素）

             我想，你或许也会考虑怎样去减小solr的内存使用量。

              其中的一个因素就是input document的大小。

              当咱们使用xml执行add操做的时候，就会有两个限制。

•      document中的field都是会被存进内存的，field有个属性叫maxFieldLength，它或许能帮上忙。
•      每增长一个域，也是会增长内存的使用的。