Solr Cache最佳实践帮你轻松调优

Posted Pivotal研发中心

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Solr Cache最佳实践帮你轻松调优相关的知识,希望对你有一定的参考价值。


背景

Apache Solr是被广泛使用的开源搜索引擎,Greenplum DB的全文检索组件Greenplum Text(https://gptext.docs.pivotal.io/330/welcome.html)就是基于其构建的 :Greenplum Text简写为GPText,它将Greenplum数据库与Apache SolrCloud企业搜索和MADlib分析库进行紧密集成,从而为客户提供了大规模分析处理和业务决策支持,主要功能包括免费的文本搜索以及对文本分析的支持。

广义来说,solr中的cache可以分为2大部分:solr系统的内部cache和留给操作系统的文件cache。对于前者来说,如果设置不当,不但不会提升性能,还将浪费大量内存。

根据长期为客户调优的经验,本文作者将对solr cache进行简要介绍并陈述solr cache最佳实践。

分类

solr内部cache分为4类:

  • QueryResult Cache:缓存query对应的docid拉链,数据结构:query => docid list

  • Filter Cache:缓存filter对应的bitmap索引,数据结构:filter => bitmap (total doc number bit)

  • Doc Cache:缓存doc id对应的stored的doc文档内容,数据结构:doc id => doc content

  • Custom Cache,自定义cache,默认关闭,本文档中不再介绍


大家需要留意的是这里给出的数据结构只是朴素实现,而solr实际的内部实现比朴素实现更精良(如节省内存),特别是对于filter cache,详见solr社区讨论(https://lucene.472066.n3.nabble.com/A-question-about-solr-filter-cache-td4455337.html)。

配置

在每个索引的solrconfig.xml中配置,配置每类索引的最大个数(size),举例:
<filterCache class="solr.FastLRUCache" size="512" initialSize="512" autowarmCount="0" /><queryResultCache class="solr.LRUCache" size="512" initialSize="512" autowarmCount="0" /><documentCache class="solr.LRUCache" size="512" initialSize="512" autowarmCount="0" />
(左划查看代码)

关于配置,大家需要留意2点内容:

  1. 前2者还可以设置maxRamMB参数(版本要求:solr 6.6中不能配置,7.3.1可以):该类cache的使用内存上限,单位是MB。如果配置了它的话,size和initialSize参数将被忽略
  2. 另外cache的生效时间受到auto/autosoft commit参数的影响,目前最新gptext代码中配置如下:

autocommit不会导致cache失效(因为设置了opensearcher为false)

<autoCommit><maxDocs>10000</maxDocs><maxTime>60000</maxTime><openSearcher>false</openSearcher></autoCommit>


autosoftcommit导致cache失效:每Docs/Time个周期到了会导致cache失效


<autoSoftCommit><maxDocs>100000</maxDocs><maxTime>600000</maxTime></autoSoftCommit>



内存开销

这里我们通过一个例子来进行说明,假设某用户的一个使用场景如下:

  • 每个query/filter 10 Byte

  • 平均结果数目:25万条(每条结果id使用一个8byte整数代表)

  • 总文档数目:10亿(使用一个bitmap,每个文档占1bit)

  • 平均stored文档大小:32 Byte(4个8byte字段)

  • cache和autocommit参数都是默认值


可以得出每类cache的最大大小:

  • queryresult cache:(10+250000*8) * 512 = 1GB (最差情况下)

  • filter cache:(1000000000/8) * 512 = 60GB (最差情况下)

  • doc cache:32 * 512 = 16KB


明显可见filter cache过大,不过以上只是定性分析,便于找出可能的内存瓶颈,实际的内存开销会更小。

监控

如果可以访问SOLR UI,可以查看每个core上的cache metrics统计:


http://localhost:18983/solr/#/demo.public.test_wiki_shard1_replica_n2/plugins?type=cache


如果无法访问SOLR UI,直接通过如下url查看:


  • http://localhost:18983/solr/admin/metrics?group=core&prefix=CACHE.searcher.queryResultCache 

  • http://localhost:18983/solr/admin/metrics?group=core&prefix=CACHE.searcher.filterCache

  • http://localhost:18983/solr/admin/metrics?group=core&prefix=CACHE.searcher.documentCache


例如,通过SOLR UI查看metrics项目



重点关注需要XXX.cumulative_hitratio:它是solr节点启动后积累的命中率,不会受到cache清空导致的影响。


配置实践

本文将要给出每类cache size的通用设置方法:


首先,持续运行系统一段时间(如一天/一周等),然后搜集如下系统参数:


1. 是否发生了OOM (out of memory) 
2. 搜集每个索引的cumulative_hitratio(通常只需要关注最大的索引) 


如果未发生OOM,请按照如下流程图来处理:



如果发生了OOM,我们就应该关闭或限制某类cache的大小:

1.filter cache


  • 如前文中实例,一般它是对空间需求最高的cache类型,OOM很可能是由它导致

  • 检查cumulative_hitratio

    a.  如果高(表明cache非常有效),为它设置一个能接受的maxRamMB值
    b.  如果低,直接关闭(设置size为0)


2. query result cache

  • 通常不应该关闭它(往往能发挥作用,如重复搜索一个query)值

  • 检查cumulative_hitratio

    a.  如果高,为它设置一个能接受的maxRamMB

    b. 如果低,设置一个较小的maxRamMB值


3. document cache

  • 通常情况下不是内存瓶颈,因此请首先处理好前2类cache



参考

https://teaspoon-consulting.com/articles/solr-cache-tuning.html
https://lucidworks.com/post/scaling-lucene-and-solr/
https://blog.cloudera.com/apache-solr-memory-tuning-for-production/ 
https://blog.cloudera.com/solr-memory-tuning-for-production-part-2/ 
https://lucene.apache.org/solr/guide/7_0/performance-statistics-reference.html#statistics-for-caches 
https://blog.csdn.net/john_hongming/article/details/43195849 



关于作者


马洪旭,Pivotal资深研发工程师 & Apache HAWQ committer,专注于数据库领域并热爱开源技术,目前在Pivotal从事GPText研发工作。




以上是关于Solr Cache最佳实践帮你轻松调优的主要内容,如果未能解决你的问题,请参考以下文章

solr最佳实践

Java 在 Linux 中性能调优最佳实践

确保 Solr/Lucene 索引在长时间重建后“最新”的最佳实践

laravel 5 优化

MySQL参数调优最佳实践

万字长文解密数据异构最佳实践(含完整代码实现)!!