我有一个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个节点中的一个因各种预期原因而死亡之后发生限制 . 群集立即进入黄色状态,其中许多分片将开始在其余节点上初始化 .
知道为什么集群在明确配置后不继续加油?在节点发生故障后,有什么其他建议让集群更快地返回绿色状态?
4 回答
实际上对应于日志文件中
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个分片的应用程序中,我们使用以下设置:此外,您可以采取一项重要措施来改善具有高索引速率的应用程序的节点/节点重新启动恢复时间,这一点利用了 index recovery prioritization (ES> = 1.7) . 调整此设置,以便首先恢复接收最多索引活动的索引 . 您可能知道,"normal"分片初始化过程只是在节点之间复制已经索引的段文件 . 但是,如果在初始化之前或初始化期间针对分片发生索引活动,则具有新文档的translog可能会变得非常大 . 在恢复期间合并进入屋顶的情况下,这是对着碎片的重写,几乎总是罪魁祸首 . 因此,使用索引恢复优先级来恢复那些分片 first 并延迟具有较少索引活动的分片,可以最小化translog的最终大小,这将显着缩短恢复时间 .
我们使用1.7并注意到类似的问题:即使IO未饱和,索引也会受到限制(在我们的例子中是Fusion IO) .
在 increasing "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
希望这可以帮助!
您是否考虑过增加分片分配延迟,以便在主服务器开始提升副本之前为节点提供恢复时间?
https://www.elastic.co/guide/en/elasticsearch/reference/current/delayed-allocation.html
尝试将index.merge.scheduler.max_thread_count设置为1
https://www.elastic.co/blog/performance-considerations-elasticsearch-indexing