共计 2022 个字符,预计需要花费 6 分钟才能阅读完成。
导读 | 这篇文章主要介绍了 Elasticsearch6.2 服务器升配后的 bug 问题及解决方法,可以帮助有其他人避坑,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下 |
本篇文章记录最近一次生产服务器硬件升级之后引起集群不稳定的现象,希望可以帮到有其它人避免采坑。
升级后出现的异常如下:
出现限流日志:stop throttling indexing: numMergesInFlight=8, maxNumMerges= 9 应用写入集群的 rt 耗时变高,同时集群监控的 indexing 的时长也变高 mlocked 的内存调用一直在增长
ES version:6.2.4
配置:32C64G
环境:阿里云 ecs 自建
gc:cms
jvm:30GB
升配后
ES version:6.2.4
配置:64C128G
环境:阿里云 ecs 自建
gc:cms
jvm:30GB
升配之后第二天首先应用表现出异常,写入 ES 的耗时变高了好十几倍,从 40ms 上升到 600ms;升配导致集群变慢还是头一次遇到。通过对集群监控分析集群整体负载正常比升配之前有所下降,但是 indexing 的写入耗时监控确实比升配之前增长了很多。在 ES 的输出日志中出现了异常日志 ”stop throttling indexing: numMergesInFlight=8, maxNumMerges=9″;
当时怀疑应该是这个限流导致,ES 的限流的主要目的是出于对集群的保护避免产生过多的段影响性能,说白了就是段的合并跟不上写入的速度,所以先来解决这个限流的问题,
由于配置文件没有配置最大线程数和最大的合并线程数,所以这两个值是用的是默认值
Spinning media has a harder time with concurrent I/O, so we need to decrease the number of threads that can concurrently access the disk per index. This setting will allow max_thread_count + 2 threads to operate on the disk at one time, so a setting of 1 will allow three threads.
index.merge.scheduler.max_thread_count
The maximum number of threads on a single shard that may be merging at once. Defaults to Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2)) which works well for a good solid-state-disk (SSD). If your index is on spinning platter drives instead, decrease this to 1.
注意:在 6.x 版本之后已经取消了 ”indices.store.throttle.max_bytes_per_sec”,所以现在只能通过调整 max_thread_count,max_merge_count,默认 max_thread_count 最小是 1 最大是 4,如果是机械盘推荐设 1 如果是 ssd 盘可以设成 4 或者更高,max_merge_count 默认等于 max_thread_count+5,也可以单独设置
可以通过命令查看默认的集群参数配置:
GET _settings/?include_defaults
可以配置到配置文件当中,也可以通过以下命令针对索引进行动态设置:
PUT index_name/_settings
{
"index.merge.scheduler.max_thread_count": 4,
"index.merge.scheduler.max_merge_count": 20
}
通过修改线程数之后,限流的问题解决了,但是应用的写入 rt 耗时问题还是没有得到解决。通过对 ”hot_threads” 进行分析发现主要的耗时还是在 merge 和 index 两大块,并且通过 os 层面的监控发现 mlock 的占用内存一直在增长,启动参数配置文件设置在内存锁定“bootstrap.memory_lock: true”不明白为什么还会出现 mlock 的增长。
处理办法:
将硬件配置降回到 32C64G 问题解决,增加一副本来提升查询性能
经过 3 天问题排查,网上也没有找到类似的案例,网上更多的还是限流相关的案例,总结下来应该还是当前版本对于大内存的处理相关的 bug,在 7.x 版本没有出现类似的内存问题
到此这篇关于 Elasticsearch6.2 服务器升配后的 bug 的文章就介绍到这了
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)