这篇文章主要讲解了“CDH5 Solr性能调优方法是什么”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“CDH5 Solr性能调优方法是什么”吧！
为赣榆等地区用户提供了全套网页设计制作服务，及赣榆网站建设行业解决方案。主营业务为成都网站制作、网站建设、外贸网站建设、赣榆网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
Solr性能调优是个复杂的过程，本文旨在描述Solr在使用过程中对性能优化的注意事项。
有些配置最好在安装之后立马修改，这样可以避免修改配置之后需要重复索引。
配置一个我们安装的最新版本的Lucene版本，最新的版本将拥有最新的特性以及对一些已知bug的修复，推荐使用solr最新版的lucene版本，该配置在solrconfig.xml文件中修改。
CDH5.3.2中Solr使用的Lucene版本是4.4，推荐不要修改此内容。
当我们创建一个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文件中引用，具体如 下：
其中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启用通过
参数来配置，其中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。
感谢各位的阅读，以上就是“CDH5 Solr性能调优方法是什么”的内容了，经过本文的学习后，相信大家对CDH5 Solr性能调优方法是什么这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！
