如何防止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(where max_thread_count<= max_merge_count) 一起增加将增加单个索引分片内的段允许的同时合并的数量。

如果您的索引速率非常高，导致单个索引中包含许多 GB，您可能还想提出一些其他假设，即 Elasticsearch 默认设置对段大小所做的一些假设。尝试提高floor_segment- 考虑合并段之前的最小大小，max_merged_segment- 单个段的最大大小，以及segments_per_tier- 在它们开始合并到新层之前大致相等大小的段数。在具有高索引率和大约 120GB 的完成索引大小以及每个索引 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 的重播。因此，使用索引恢复优先级来恢复这些分片第一 并以较少的索引活动延迟分片，您可以最小化 translog 的最终大小，这将大大缩短恢复时间。

Answer 2

您是否考虑过增加分片分配延迟，以便在主节点开始提升副本之前为节点提供恢复时间？

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