Elasticsearch6.2服务器升级后的bug(避坑指南)(elasticsearch7.6)

本文记录了生产服务器最新硬件升级导致集群不稳定的现象，希望能帮助其他人避免挖坑。

一、问题描述。升级后的例外情况如下:

出现限流日志:停止抛出索引:nummergesinflight = 8，maxnummerges = 9。应用程序写入集群的rt时间变长，集群监控的索引时间也变长。mlocked内存调用一直在增加。

二、升级esversion: 6.2.4之前的升级流程

配置:32C64G

环境:阿里云ecs自建

gc:cms

jvm:30GB

晋升后

ES版本:6.2.4

配置:64C128G

环境:阿里云ecs自建

gc:cms

jvm:30GB

3.第一个应用在处理步骤升级后第二天就出现异常，写ES的时间增加了几倍，从40ms增加到600ms；第一次遇到升级导致的集群变慢。通过集群监控分析，集群整体负载正常情况下比升级前低，但是索引的写耗时监控确实比升级前高很多。异常日志”出现在ES stop throttling索引的输出日志中:numMergesInFlight=8，maxNumMerges = 9 & quot；

1.当时怀疑应该是这个限流引起的。ES电流限制的主要目的是保护集群，避免过多的段影响性能。说白了就是段合并跟不上写速度，先解决这个限流问题吧。

因为配置文件没有配置最大线程数和最大合并线程数，所以这两个值是默认值。

旋转介质在并发I/O方面有困难，因此我们需要减少每个索引可以并发访问磁盘的线程数量。此设置将允许max_thread_count + 2个线程同时在磁盘上运行，因此设置1将允许三个线程。

index . merge . scheduler . max _ thread _ count单个碎片上可以同时合并的最大线程数。默认为Math.max(1，Math.min(4，Runtime.getRuntime()。availableProcessors() / 2))，这对于一个好的solid-state-disk (SSD)来说非常有效。如果您的索引位于旋转盘片驱动器上，则将该值减小到1。

注意:6.x版以后已经取消了”。indexes . store . throttle . max _ bytes _ per _ sec & quot；，所以现在只能调整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 }

2.修改了2.mlock中的线程数后，解决了限流的问题，但是应用写rt的耗时问题没有解决。是“hot _ threads & quot分析显示主要的时间消耗还是在merge和index两个块上，通过os级的监控发现mlock占用的内存一直在增加，启动参数配置文件设置在memory locking & ldquobootstrap . memory _ lock:true & rdquo；不知道为什么还有mlock的成长。

处理方法:

将硬件配置降低到32C64G解决问题，增加一个副本提高查询性能

3.总结经过3天的排查，网上没有发现类似案例，网上发现更多与限流相关的案例。综上所述，应该还是当前版本处理大内存相关的bug，7.x版本没有出现类似的内存问题。

关于Elasticsearch6.2服务器升级后的bug的这篇文章到此为止。关于Elasticsearch6.2服务器的更多信息，请搜索主机频道zhujipindao之前的文章。或者继续浏览下面的相关文章。希望大家支持主机频道zhujipindao。以后多来com！