如何防止Elasticsearch受到索引限制？

Question

我有一个40节点的Elasticsearch集群，它受到高索引请求率的冲击。这些节点中的每一个都使用SSD以获得最佳性能。正如来自多个来源的建议一样，我尝试使用以下配置来防止索引节流：

indices.store.throttle.type: none

不幸的是，我仍然看到性能问题，因为集群仍然周期性地限制索引。以下日志证实了这一点：

[2015-03-13 00:03:12,803][INFO ][index.engine.internal    ] [CO3SCH010160941] [siphonaudit_20150313][19] now throttling indexing: numMergesInFlight=6, maxNumMerges=5
[2015-03-13 00:03:12,829][INFO ][index.engine.internal    ] [CO3SCH010160941] [siphonaudit_20150313][19] stop throttling indexing: numMergesInFlight=4, maxNumMerges=5
[2015-03-13 00:03:13,804][INFO ][index.engine.internal    ] [CO3SCH010160941] [siphonaudit_20150313][19] now throttling indexing: numMergesInFlight=6, maxNumMerges=5
[2015-03-13 00:03:13,818][INFO ][index.engine.internal    ] [CO3SCH010160941] [siphonaudit_20150313][19] stop throttling indexing: numMergesInFlight=4, maxNumMerges=5
[2015-03-13 00:05:00,791][INFO ][index.engine.internal    ] [CO3SCH010160941] [siphon_20150313][6] now throttling indexing: numMergesInFlight=6, maxNumMerges=5
[2015-03-13 00:05:00,808][INFO ][index.engine.internal    ] [CO3SCH010160941] [siphon_20150313][6] stop throttling indexing: numMergesInFlight=4, maxNumMerges=5
[2015-03-13 00:06:00,861][INFO ][index.engine.internal    ] [CO3SCH010160941] [siphon_20150313][6] now throttling indexing: numMergesInFlight=6, maxNumMerges=5
[2015-03-13 00:06:00,879][INFO ][index.engine.internal    ] [CO3SCH010160941] [siphon_20150313][6] stop throttling indexing: numMergesInFlight=4, maxNumMerges=5

节流发生在40个节点中的一个节点由于各种预期原因而死亡后。集群立即进入黄色状态，在此状态下，多个分片将开始在其余节点上进行初始化。

你知道为什么集群在显式配置后继续减速吗？对于让群集在节点故障后更快地返回绿色状态，有什么其他建议吗？

Answer 1

实际对应于日志文件中的maxNumMerges的设置称为index.merge.scheduler.max_merge_count。将其与index.merge.scheduler.max_thread_count (其中max_thread_count <= max_merge_count)一起增加将增加单个索引的分片中允许的段的同时合并的数量。

如果您的索引率非常高，导致单个索引中有许多GB，那么您可能还想提出Elasticsearch默认设置中关于段大小的一些其他假设。尝试增加floor_segment -考虑合并一个段之前的最小大小，max_merged_segment -单个段的最大大小，以及segments_per_tier -在开始合并到新的层之前大小大致相同的段的数量。在索引率较高且完成的索引大小约为120 On，每个索引有10个分片的应用程序上，我们使用以下设置：

curl -XPUT /index_name/_settings -d'
{
  "settings": {
    "index.merge.policy.max_merge_at_once": 10,
    "index.merge.scheduler.max_thread_count": 10,
    "index.merge.scheduler.max_merge_count": 10,
    "index.merge.policy.floor_segment": "100mb",
    "index.merge.policy.segments_per_tier": 25,
    "index.merge.policy.max_merged_segment": "10gb"
  }
}

此外，在索引率较高的应用程序上改善节点丢失/节点重启恢复时间的一件重要事情是利用 (在ES >= 1.7中)。调整此设置，以便首先恢复接收最多索引活动的索引。正如您可能知道的，“正常的”分片初始化过程只是在节点之间复制已索引的段文件。但是，如果在初始化之前或期间针对分片执行索引活动，则包含新文档的translog可能会变得非常大。在恢复期间合并达到顶峰的场景中，针对分片的translog重播几乎总是罪魁祸首。因此，使用索引恢复优先级来恢复那些索引活动较少的first和delay分片，可以最小化translog的最终大小，从而大大缩短恢复时间。

Answer 2

我们正在使用1.7，并注意到一个类似的问题:即使在IO未饱和的情况下，索引也会被抑制(在我们的示例中为Fusion IO )。

在增加 "index.merge.scheduler.max_thread_count“之后，这个问题似乎消失了--到目前为止，我们没有看到任何节流被记录下来。

我会尝试至少将"index.merge.scheduler.max_thread_count“设置为报告的最大numMergesInFlight (在上面的日志中为6)。

https://www.elastic.co/guide/en/elasticsearch/reference/1.7/index-modules-merge.html#scheduling

希望这能有所帮助！

Answer 3

您是否考虑过增加分片分配延迟，以便让节点有时间在主机开始升级副本之前进行恢复？

https://www.elastic.co/guide/en/elasticsearch/reference/current/delayed-allocation.html