Question

设置
我们设置了一个SolrCloud（Solr版本4.10.4）集群，该集群由分布在2个数据中心的6台服务器组成（每个DC上有3台）。

群集设置为3个分片，复制因子为2，处理一个核心，45M文档平均每个分片大约100GB。调节集群的3个Zookeeper实例驻留在6个服务器中的3个服务器上（第一个DC中的服务器）。

核心位于所有分片上的6Gb / s SSD驱动器上。 DC内ping时间为0.3ms，而DC间的时间为3ms。

群集在Tomcat 7.0.61和Java 7上设置，分配的内存为26GB，而每个服务器有32GB可用，而每个节点都配置为每30秒与zookeeper联系。

每个solr节点的缓存配置如下

<filterCache class="solr.FastLRUCache"
             size="40000"
             initialSize="40000"
             autowarmCount="0"/>
<queryResultCache class="solr.LRUCache"
                 size="50000"
                 initialSize="20000"
                 autowarmCount="0"/>
<documentCache class="solr.LRUCache"
               size="2000000"
               initialSize="2000000"
              />
<fieldValueCache class="solr.FastLRUCache"
               size="8"
               autowarmCount="8"
               showItems="8" />

最重要的是，我们有一个API应用程序，可以执行大多数时间的某些搜索操作：

q=Fragmento+de+retablo+NOT+DATA_PROVIDER%3A%22CER.ES%3A+Red+Digital+de+Colecciones+de+museos+de+Espa%C3%B1a%22&
rows=12&start=0&
sort=score+desc&
timeAllowed=30000&fl=*%2Cscore&facet.mincount=1

我们使用一个或最多来对参数进行排序（第二个是我们架构的唯一ID，但在本例中没有）。

问题
我们的API在群集上每秒发送大约5-10个查询。即使是一段时间后最小数量的请求压倒了群集，节点开始消失，同时观察到大量磁盘I / O.在我们将核心提供给API之前，我们做了一些手动缓存加热大约10分钟，我们注意到一段时间后（在群集崩溃之前）缓存的命中率为1，除了{{1 }和queryResultCache=0.67，但也没有发生驱逐。内存消耗约为88％。

任何可能出错的想法或我们应该关注的地方都将受到高度赞赏。

Answer 1

大约88％的内存消耗可以快速跳到100并杀死内核。

发生在我们身上......在各个核心日志中查找核心转储文件

SolrCloud也容易受到高cpu峰值的影响，这可能会让ZooKeeper认为节点已经死了......恢复很慢，有时根本不会发生。

您可以更改ZooKeeper的默认超时以防止这种情况发生。

您可以在此问题上看到此错误...

https://issues.apache.org/jira/browse/SOLR-5565

从你的评论我看到你可能应该超时到大约2分钟。

当然这是有代价的 - 尝试阅读并理解其含义

https://zookeeper.apache.org/doc/r3.1.2/zookeeperStarted.html

SolrCloud在15-20分钟后消失

1 个答案: