SolrCloud在15-20分钟后消失

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

该集群由3个分片和2个复制因子组成，处理一个核心，每个分片平均处理4500万个文档，约100GB。有3个Zookeeper实例管理集群，它们位于6台服务器中的3台（第一个DC中的服务器）上

核心驻留在所有碎片上的6Gb/s SSD驱动器上。 DC内ping时间为0.3ms，DC间ping时间为3ms

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

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

除此之外，我们还有一个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分钟的手动缓存预热，我们注意到，在一段时间后（在集群崩溃之前），除了

queryResultCache=0.67

和

documentCache=0.9

之外，所有缓存的命中率都为1，而没有发生逐出。内存消耗约为88%

---

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

大约88%的内存消耗可以迅速增加到100，并杀死核心

这发生在我们身上。。。在各个cores日志中查找core转储文件

SolrCloud也容易受到高cpu峰值的影响，这会使ZooKeeper认为节点已死亡。。。复苏是缓慢的，有时根本不会发生

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

你可以看到这个错误的问题，例如

从您的评论中，我看到您可能应该将超时时间增加到2分钟左右

这当然是有代价的——试着读一点，理解它的意思

---

您是否检查了solr/zookeeper日志？你可以在那里找到有用的信息。嗨，我检查了solr和zookeeper的日志，它抱怨插座超时。我还用不同的配置和配置运行了许多实验，似乎GC启动并暂停了整个集群。我从广泛的应用程序配置开始，我认为目前的问题是，有一些特定的查询（类似于我提供的查询）会导致次优的深度分页，这最终会导致GC暂停，可能会持续1分钟。我编辑了答案，尝试回答您的新评论