performance - 如何防止 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——在开始合并到新层之前大小大致相等的段数。在具有高索引率和大约 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"
  }
}

此外，您可以采取的一项重要措施是利用 index recovery prioritization 来缩短索引率高的应用程序的节点丢失/节点重启恢复时间。 (在 ES >= 1.7 中)。调整此设置，以便首先恢复接收到最多索引事件的索引。您可能知道，“正常”的分片初始化过程只是在节点之间复制已经索引的段文件。但是，如果在初始化之前或期间针对分片进行索引事件，则带有新文档的 translog 可能会变得非常大。在恢复期间合并通过屋顶的场景中，几乎总是罪魁祸首是针对碎片的此 translog 的重放。因此，使用索引恢复优先级来首先恢复那些分片并延迟索引事件较少的分片，您可以最大限度地减少 translog 的最终大小，这将显着缩短恢复时间。