CDH5 Solr性能调优

最新推荐文章于 2023-04-04 19:38:01 发布

上海1943

最新推荐文章于 2023-04-04 19:38:01 发布

阅读量1k

点赞数

分类专栏： solr 文章标签： solr 性能优化

solr 专栏收录该内容

0 篇文章 0 订阅

订阅专栏

Solr性能调优

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

在安装完成之后的调优

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

配置一个必须的Lucene版本

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

<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来指定多线程并发查询，譬如：

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文件中引用，具体如下：

<directoryFactory name="DirectoryFactory">  
    <bool name="solr.hdfs.blockcache.enabled">${solr.hdfs.blockcache.enabled:true}</bool>  
    <int name="solr.hdfs.blockcache.slab.count">${solr.hdfs.blockcache.slab.count:1}</int>  
    <bool name="solr.hdfs.blockcache.direct.memory.allocation">${solr.hdfs.blockcache.direct.memory.allocation:true}</bool>  
    <int name="solr.hdfs.blockcache.blocksperbank">${solr.hdfs.blockcache.blocksperbank:16384}</int>  
    <bool name="solr.hdfs.blockcache.read.enabled">${solr.hdfs.blockcache.read.enabled:true}</bool>  
    <bool name="solr.hdfs.blockcache.write.enabled">${solr.hdfs.blockcache.write.enabled:true}</bool>  
    <bool name="solr.hdfs.nrtcachingdirectory.enable">${solr.hdfs.nrtcachingdirectory.enable:true}</bool>  
    <int name="solr.hdfs.nrtcachingdirectory.maxmergesizemb">${solr.hdfs.nrtcachingdirectory.maxmergesizemb:16}</int>  
    <int name="solr.hdfs.nrtcachingdirectory.maxcachedmb">${solr.hdfs.nrtcachingdirectory.maxcachedmb:192}</int>  
</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)下增加如下配置：

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空间数，配置如下：

# minimize swappiness  
sudo sysctl vm.swappiness=10  
sudo bash -c 'echo "vm.swappiness=10">> /etc/sysctl.conf'  
# disable swap space until next reboot:  
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启用通过

<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