不二法门---Solr常用调优方法

ret43543

转自：http://rdc.taobao.com/team/jm/archives/1753
共整理三部分，第一部分Solr常规处理，第二部分针对性性处理，前者比较通用，后者有局限性。务必根据具体应用特性，具体调节参数，对比性能。第三部分
solr查询相关的 　　
　　具体应用需要全面去把控，各个因素一起起作用。
　　第一部分<Solr常规的调优>
E文连接 http://wiki.apache.org/solr/SolrPerformanceFactors
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(索引段)的数量。
合并因子这个&#20540;告诉lucene，在什么时候，要将几个segment合并成为一个segment, 合并因子就像是一个数字系统的基数一样。
比如说，如果你将合并因子设成10，那么每往索引中添加1000个文档的时候，就会创建一个新的索引段。当第10个大小为1000的索引段添加进来的时候，这十个索引段就会被合并成一个大小为10，000的索引段。当十个大小为10，000的索引段生成的时候，它们就会被合并成一个大小为100，000的索引段。如此类推下去。

这个&#20540;可以在solrconfig.xml 中的
*mainIndex*中设置。（不用管indexDefaults中设置）
mergeFactor Tradeoffs
较高的合并因子

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

较低的合并因子

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

HashDocSet Max Size Considerations
hashDocSet是solrconfig.xml中自定义优化选项,
使用在filters(docSets)
中，更小的sets，表明更小的内存消耗、遍历、插入。

hashDocSet参数&#20540;最后基于索引文档总数来定，索引集合越大，hashDocSet&#20540;也越大。
Calulate 0.005 of the total number of documents that you are going to store. Try values on either ‘side’ of that value to arrive at the best query times. &#61623; When query times seem to plateau, and performance doesn’tshow much difference between the higher number and the lower, use the higher.
Note: hashDocSet is no longer part of Solr as of version 1.4.0, seeSOLR-1169.
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）,这样，从机的更新才不会太频繁。

• 
  执行commit操作会让solr新生成一个snapshot。如果将postCommit参数设成true的话，optimization也会执行snapShot.
  
• slave上的Snappuller程序一般是在crontab上面执行的，它会去master询问，有没有新版的snapshot。一旦发现新的版本，slave就会把它下载下来，然后snapinstall.
  
• 每次当一个新的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&#26684;式来建立索引快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，它或许能帮上忙。
  
• 每增加一个域，也是会增加内存的使用的。
  

　　第二部分<Solr特殊调优>
　　1. 多core的时候
　　多core 如果同一时间进行core 切换，会导致内存、cpu压力过大，可以扩展Solr代码，限制最多同时core
切换的执行个数。保证不会出现高load或者高cpu 风险
　　2，应用较高安全
　　最后不低于2个结点工作，并且最好2个结点是跨机器的。
offline与online切换的时候，如果数据量不是很多，可以考虑index与search合一，如果数据量较大，超过5000w的时候，建议index
offline或者search结点之外的其他结点上执行index
　　3.cache参数配置
　　如果更新很频繁，导致commit和reopen频繁，如果可以的话，关闭cache.
如果访问中依赖cache提示性能，那么最好关闭cache warm，no facet 需求
或者开开启cache warm 有facet需要，对fieldvalue cache很依赖的话。
实时更新的话，通常document cache命中率比较低，完全可以不开启这个配置
　　4.reopen 和commit
　　如果可以的话，主磁盘索引，不参入segment合并，新的索引段走不同的目录。并且reopen的时候，主索引的不变动。
　　commit与reopen异步化
　　5.有一部分数据如果不变动，可以考虑使用memory cache 或者locale cache 平衡性能和空间开销，同时避免FGC
　　6.中间变量压缩、单例化
　　所有查询或者建索引过程中，尽量少创建对象，而通过set改变对象&#20540;，以及单例化，提升性能。一些较大中间变量，如果可以的话，采取一些整数压缩
　　7.对象表示重定义
例如日期、地区、url、byte等一些对象，可以考虑差&#20540;、区位码、可别部分、压缩等结构，使得内存开销降低间接使得内存使用率提高，获得更好性能。
　　8.index与store 隔离
就是index发挥它的查询性能，store发挥它的存储、响应性能。
也就是不要将所有的内容都放在index中，尽量使得field的属性stored=false
　　9. 使用solr、lucene最新版本
　　10. 共享分词实例
自定义的分词，务必使用单例。千万不要一个document创建一个分词对象
　　第三部分 Solr查询
　　1. 对按指定域排序
展示的时候，对于数字的建议，展示最近1或者3个月数据。例如价&#26684;，防止作弊
dump或者建索引的时候，对数字加以上下界检测，及早发现数字本身正确，而实际意义不合理的数据
　　2. 排序可变性
默认的排序务必有自己的相关参数，并且平衡各方面需求。
排序要变，但是不至于大的波动。排序的细节不公开，但是排序的结果可以解释的清楚。
　　3.线上线下
有些分&#20540;可以线下完成，有些分&#20540;线上完成。看需求。
　　4.多域查询
如果默认查询多个域，不妨将多个域合成一个域，只差一个域
　　5.高亮
高亮可以在solr里面或者外面执行的，不一定在solr里面执行，可以在solr之外执行
同理，分词可以在线下执行好，dump只执行简单的空&#26684;分词即可
　　6.统计
facet统计可以先上与线下相结合，不一定完全依赖线上即时计数。
　　7.主动搜索
主动搜索查询串务必严&#26684;处理，既要去无效查询串，也要适当扩展查询串。
明确查询路径和hit=0的对应处理。