CDH5 Solr性能调优

Solr性能调优

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

在安装完成以后的调优

有些配置最好在安装以后立马修改，这样能够避免修改配置以后须要重复索引。

配置一个必须的Lucene版本

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

 

1. <luceneMatchVersion>4.4</luceneMatchVersion>  

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

 

Schema设计

当咱们建立一个schema的时候，咱们须要使用正确的数据类型来描述相应的数据字段，譬如：

• 使用tdate数据类型来描述日期类型，而不是使用string类型的日期。

• 推荐使用text类型替代string类型来适应系统语言环境。由于text类型能够返回一个输入条目的子集结果，譬如：当咱们查询'John'的时候咱们可能会找到'John Smith'的数据结果，若是是string类型的话，则仅仅只会返回匹配的结果。

• 对于IDs字段，使用string类型。

通常性调优

1.对于Faceting查询来讲启动facet.thread来指定多线程并发查询，譬如：

 

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

上面就是配置100个线程来并发查询，关于Faceting的具体用法能够参看：https://cwiki.apache.org/confluence/display/solr/Faceting

 

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

 

1. <directoryFactory name="DirectoryFactory">  

2.     <bool name="solr.hdfs.blockcache.enabled">${solr.hdfs.blockcache.enabled:true}</bool>  

3.     <int name="solr.hdfs.blockcache.slab.count">${solr.hdfs.blockcache.slab.count:1}</int>  

4.     <bool name="solr.hdfs.blockcache.direct.memory.allocation">${solr.hdfs.blockcache.direct.memory.allocation:true}</bool>  

5.     <int name="solr.hdfs.blockcache.blocksperbank">${solr.hdfs.blockcache.blocksperbank:16384}</int>  

6.     <bool name="solr.hdfs.blockcache.read.enabled">${solr.hdfs.blockcache.read.enabled:true}</bool>  

7.     <bool name="solr.hdfs.blockcache.write.enabled">${solr.hdfs.blockcache.write.enabled:true}</bool>  

8.     <bool name="solr.hdfs.nrtcachingdirectory.enable">${solr.hdfs.nrtcachingdirectory.enable:true}</bool>  

9.     <int name="solr.hdfs.nrtcachingdirectory.maxmergesizemb">${solr.hdfs.nrtcachingdirectory.maxmergesizemb:16}</int>  

10.     <int name="solr.hdfs.nrtcachingdirectory.maxcachedmb">${solr.hdfs.nrtcachingdirectory.maxcachedmb:192}</int>  

11. </directoryFactory>  

 

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

3.增长了hdfs的块缓存以后咱们必需要增大JVM的内存大小来避免OOM异常。若是是手动安装，咱们须要在/etc/default /solr(若是是parcel模式下安装的话目录在/opt/cloudera/parcel/CDH-*/etc/default/solr)下增长 以下配置：

 

1. CATALINA_OPTS="-Xmx10g -XX:MaxDirectMemorySize=15g -XX:+UseLargePages -Dsolr.hdfs.blockcache.slab.count=60"  

若是是经过Cloudera Manager能够经过Solr->配置->Solr Server Default Group->资源管理下Solr Server

 

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

4.为了更好的提高性能，cloudera建议修改linxu的swap空间数，配置以下：

 

1. # minimize swappiness  

2. sudo sysctl vm.swappiness=10  

3. sudo bash -c 'echo "vm.swappiness=10">> /etc/sysctl.conf'  

4. # disable swap space until next reboot:  

5. sudo /sbin/swapoff -a  

5.在不一样的环境下选择不一样的GC机制可以更好的提高Solr的性能，有以下2向GC机制可供选择：

 

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

• Throughput collector:追求最大吞吐量而设计的垃圾收集机制，主要采用并行收集算法对年轻代的收集。若是solr对吞吐量要求高于用户体验，那么能够采用此机制，可是它一般会链接超时而影响用户体验，启用该机制：-XX:+UseParallelGC

CDH5默认使用的CMS机制，修改能够在Solr->配置->Solr Server Default Group>高级->Solr Server的Java配置选项中修改其参数。

6.若是咱们拥有多余的硬件资源，咱们能够经过replica来提高查询的吞吐量，固然，添加replica会对第一个replica的写入性能有稍微的影响，可是这应该是最小的负面影响了。

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

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

9.solrconfig.xml文件中的filterCache参数，表示用来缓存filter queries(也就是查询参数fq)获得的数据集。查询参数有2种，一种是q，另一种是fq。若是fq存在，会先查询fq中的数据，再查询q中的数 据，最后取并集，当咱们作多参数查询的时候，若是咱们采用q参数查询，这样查询命中率会很低，并且占用较多的内存空间，咱们能够对查询进行优化，用fq的 形式来求2个数据的交集会很好的提示性能。filterCache启用经过

 

1. <filterCache class="solr.LRUCache" size="512" initialSize="512" autowarmCount="0"/>  

 

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

10.solrconfig.xml文件中的useCompoundFile参数,表示将一个段的多个文件合并 为惟一的文件，开启此特性须要额外消耗大概7%~33%的索引时间，在3.6版本前默认为true，以后默认为false。固然设置为false后要注意 配置linux进程容许打开的文件数目是否有限制，若是有限制能够经过在ulimit参数修改。

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

11.咱们须要注意的是SolrCloud已经作了读写分离，而且当咱们的写入请求连接是replica的时候，replica会自动把该请求转发给leader，再由leader分发给其它replica。

12.对于本地solr性能优化能够参看：http://wiki.apache.org/lucene-java/ImproveIndexingSpeed