CDH5Solr性能调优

Solr性能调优是个复杂的过程&＃xff0c;本文旨在描述Solr在使用过程中对性能优化的注意事项。

有些配置最好在安装之后立马修改&＃xff0c;这样可以避免修改配置之后需要重复索引。

配置一个必须的Lucene版本

配置一个我们安装的最新版本的Lucene版本&＃xff0c;最新的版本将拥有最新的特性以及对一些已知bug的修复&＃xff0c;推荐使用solr最新版的lucene版本&＃xff0c;该配置在solrconfig.xml文件中修改。

1. 4.4  

CDH5.3.2中Solr使用的Lucene版本是4.4&＃xff0c;推荐不要修改此内容。

Schema设计

当我们创建一个schema的时候&＃xff0c;我们需要使用正确的数据类型来描述相应的数据字段&＃xff0c;譬如&＃xff1a;

• 使用tdate数据类型来描述日期类型&＃xff0c;而不是使用string类型的日期。

• 推荐使用text类型替代string类型来适应系统语言环境。因为text类型可以返回一个输入条目的子集结果&＃xff0c;譬如&＃xff1a;当我们查询&＃39;John&＃39;的时候我们可能会找到&＃39;John Smith&＃39;的数据结果&＃xff0c;如果是string类型的话&＃xff0c;则仅仅只会返回匹配的结果。

• 对于IDs字段&＃xff0c;使用string类型。

1.对于Faceting查询来说启动facet.thread来指定多线程并发查询&＃xff0c;譬如&＃xff1a;

1. http://localhost:8983/solr/collection1/select?q&＃61;*:*&facet&＃61;true&fl&＃61;id&facet.field&＃61;f0_ws&facet.threads&＃61;100  

上面就是配置100个线程来并发查询&＃xff0c;关于Faceting的具体用法可以参看&＃xff1a;https://cwiki.apache.org/confluence/display/solr/Faceting

2.通过solr.hdfs.blockcache.slab.count参数配置HDFS的块缓存数量&＃xff0c;默认 情况下一个HDFS块缓存是128M&＃xff0c;推荐使用物理内存的10%~20%来配置count数&＃xff0c;譬如一个50G内存的机器&＃xff0c;推荐使用5G~10G的内存&＃xff0c;那 么count的配置数量范围为&＃xff1a;5*1024/128~10*1024/128这个范围内即可。该参数在solrconfig.xml文件中引用&＃xff0c;具体如 下&＃xff1a;

1.   

2.     ${solr.hdfs.blockcache.enabled:true}  

3.     ${solr.hdfs.blockcache.slab.count:1}  

4.     ${solr.hdfs.blockcache.direct.memory.allocation:true}  

5.     ${solr.hdfs.blockcache.blocksperbank:16384}  

6.     ${solr.hdfs.blockcache.read.enabled:true}  

7.     ${solr.hdfs.blockcache.write.enabled:true}  

8.     ${solr.hdfs.nrtcachingdirectory.enable:true}  

9.     ${solr.hdfs.nrtcachingdirectory.maxmergesizemb:16}  

10.     ${solr.hdfs.nrtcachingdirectory.maxcachedmb:192}  

11.   

其中solr.hdfs.blockcache.slab.count会读取系统配置的solr.hdfs.blockcache.slab.count参数&＃xff0c;如果没有配置该参数则默认为1。该参数在Cloudera Manager中通过Solr->配置->Solr Server Default Group->资源管理下进行修改调整。

3.增加了hdfs的块缓存之后我们必须要增大JVM的内存大小来避免OOM异常。如果是手动安装&＃xff0c;我们需要在/etc/default /solr(如果是parcel模式下安装的话目录在/opt/cloudera/parcel/CDH-*/etc/default/solr)下增加 如下配置&＃xff1a;

1. CATALINA_OPTS&＃61;"-Xmx10g -XX:MaxDirectMemorySize&＃61;15g -XX:&＃43;UseLargePages -Dsolr.hdfs.blockcache.slab.count&＃61;60"  

如果是通过Cloudera Manager可以通过Solr->配置->Solr Server Default Group->资源管理下Solr Server

 的Java堆栈大小(字节)和Solr 服务其的Java直接内存大小(字节)参数找到&＃xff0c;以上是以50G的物理内存作为标准&＃xff0c;其中Xmx推荐配置为物理内存的20%左右&＃xff0c;MaxDirectMeorySize推荐配置为物理内存的30%左右。

4.为了更好的提升性能&＃xff0c;cloudera建议修改linxu的swap空间数&＃xff0c;配置如下&＃xff1a;

1. # minimize swappiness  

2. sudo sysctl vm.swappiness&＃61;10  

3. sudo bash -c &＃39;echo "vm.swappiness&＃61;10">> /etc/sysctl.conf&＃39;  

4. # disable swap space until next reboot:  

5. sudo /sbin/swapoff -a  

5.在不同的环境下选择不同的GC机制能够更好的提升Solr的性能&＃xff0c;有如下2向GC机制可供选择&＃xff1a;

• Concurrent low pause collector:简称CMS&＃xff0c;主要适用场景是对响应时间的重 要性大于吞吐量的需求&＃xff0c;能够承受垃圾回收线程和应用线程共享处理资源&＃xff0c;并且应用中存在比较多的长生命周期对象的应用。主要是对年老代的回收&＃xff0c;目标是尽量减 少应用的暂停时间&＃xff0c;减少full gc发生的几率&＃xff0c;利用和应用线程并发的垃圾回收线程来标记清楚年老代。启用CMS&＃xff1a;-XX:&＃43;UseConcMarkSweepGC

• Throughput collector:追求最大吞吐量而设计的垃圾收集机制&＃xff0c;主要采用并行收集算法对年轻代的收集。如果solr对吞吐量要求高于用户体验&＃xff0c;那么可以采用此机制&＃xff0c;但是它通常会连接超时而影响用户体验&＃xff0c;启用该机制&＃xff1a;-XX:&＃43;UseParallelGC

CDH5默认使用的CMS机制&＃xff0c;修改可以在Solr->配置->Solr Server Default Group>高级->Solr Server的Java配置选项中修改其参数。

6.如果我们拥有多余的硬件资源&＃xff0c;我们可以通过replica来提升查询的吞吐量&＃xff0c;当然&＃xff0c;添加replica会对第一个replica的写入性能有稍微的影响&＃xff0c;但是这应该是最小的负面影响了。

7.solrconfig.xml文件中ramBufferSizeMB参数&＃xff0c;表示在添加或者删除文档时&＃xff0c;为了 减少频繁的更新索引&＃xff0c;solr会选择缓存在内存中&＃xff0c;当内存中的文件大小大于该值则会更新到索引库中&＃xff0c;较大的值将消耗更多的内存&＃xff0c;我们需要确保该值低于 JVM的内存值&＃xff0c;当然也不是越大越好&＃xff0c;越大就意味着GC的时候越困难。由于CDH中是将索引写入到HDFS中&＃xff0c;我们这里ramBufferSizeMB的值应该和上面solr.hdfs.blockcache.slab.count设置的值保持一致。如果solr.hdfs.blockcache.slab.count配置为4&＃xff0c;那么该数值配置为4*128(HDFS默认块大小)。值得注意的是与该参数相对应的还有一个maxBufferedDocs参数&＃xff0c;该参数表示索引的数目超过配置的数值后就刷新到索引库中&＃xff0c;因为我们不知道每条索引的具体数据大小&＃xff0c;如果配置了此参数可能会导致ramBufferSizeMB参数失效&＃xff0c;所以不推荐开启此参数。

8.solrconfig.xml文件中maxIndexingThreads参数&＃xff0c;表示索引时并发的最大线程数&＃xff0c;当索引数据时线程数超过该配置值&＃xff0c;其它线程将处于等待状态&＃xff0c;该值和CPU处理能力有关&＃xff0c;默认值为8.

9.solrconfig.xml文件中的filterCache参数&＃xff0c;表示用来缓存filter queries(也就是查询参数fq)得到的数据集。查询参数有2种&＃xff0c;一种是q&＃xff0c;另外一种是fq。如果fq存在&＃xff0c;会先查询fq中的数据&＃xff0c;再查询q中的数 据&＃xff0c;最后取并集&＃xff0c;当我们做多参数查询的时候&＃xff0c;如果我们采用q参数查询&＃xff0c;这样查询命中率会很低&＃xff0c;而且占用较多的内存空间&＃xff0c;我们可以对查询进行优化&＃xff0c;用fq的 形式来求2个数据的交集会很好的提示性能。filterCache启用通过

参数来配置&＃xff0c;其中class是基于LRU算法的缓存实现&＃xff0c;如果cache的数据插入多查询少那么使用solr.LRUCache;如果查询多插入少 那么使用solr.FastLRUCache。size表示缓存中保存的最大数据条数&＃xff0c;initialSize表示cache初始化时的大 小&＃xff0c;autowarmCount表示当切换SolrIndexSearcher时&＃xff0c;可以对新SolrIndexSearcher做预热处理。该参数表示从 旧的SolrIndexSearcher中取多少数据在新的SolrIndexSearcher中重新引用。如果是近实时搜索&＃xff0c;不推荐开启。0表示不开 启。

10.solrconfig.xml文件中的useCompoundFile参数,表示将一个段的多个文件合并 为唯一的文件&＃xff0c;开启此特性需要额外消耗大概7%~33%的索引时间&＃xff0c;在3.6版本前默认为true&＃xff0c;之后默认为false。当然设置为false后要注意 配置linux进程允许打开的文件数目是否有限制&＃xff0c;如果有限制可以通过在ulimit参数修改。

10.启动本地shard优先性&＃xff0c;在请求中加入preferLocalShard&＃61;true来启动该特性。启动该特性后会优先使用本地shard中存储的数据&＃xff0c;从而减少网络IO的数据传输。

11.我们需要注意的是SolrCloud已经做了读写分离&＃xff0c;并且当我们的写入请求链接是replica的时候&＃xff0c;replica会自动把该请求转发给leader&＃xff0c;再由leader分发给其它replica。

12.对于本地solr性能优化可以参看&＃xff1a;http://wiki.apache.org/lucene-java/ImproveIndexingSpeed