快捷導(dǎo)航

Elasticsearch6.2服務(wù)器升配后的bug(避坑指南)

更新時間：2022年09月22日 11:43:32 作者：pursuer.chen

這篇文章主要介紹了Elasticsearch6.2服務(wù)器升配后的bug問題及解決方法，可以幫助有其他人避坑，本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下

一、問題描述

升級后出現(xiàn)的異常如下：

出現(xiàn)限流日志：stop throttling indexing: numMergesInFlight=8, maxNumMerges=9應(yīng)用寫入集群的rt耗時變高，同時集群監(jiān)控的indexing的時長也變高mlocked的內(nèi)存調(diào)用一直在增長

二、升級過程升配前

ES version：6.2.4

配置：32C64G

環(huán)境：阿里云ecs自建

gc：cms

jvm：30GB

升配后

ES version：6.2.4

配置：64C128G

環(huán)境：阿里云ecs自建

gc：cms

jvm：30GB

三、處理步驟

升配之后第二天首先應(yīng)用表現(xiàn)出異常，寫入ES的耗時變高了好十幾倍，從40ms上升到600ms；升配導(dǎo)致集群變慢還是頭一次遇到。通過對集群監(jiān)控分析集群整體負(fù)載正常比升配之前有所下降，但是indexing的寫入耗時監(jiān)控確實(shí)比升配之前增長了很多。在ES的輸出日志中出現(xiàn)了異常日志"stop throttling indexing: numMergesInFlight=8, maxNumMerges=9";

1.限流處理

當(dāng)時懷疑應(yīng)該是這個限流導(dǎo)致，ES的限流的主要目的是出于對集群的保護(hù)避免產(chǎn)生過多的段影響性能，說白了就是段的合并跟不上寫入的速度，所以先來解決這個限流的問題，

由于配置文件沒有配置最大線程數(shù)和最大的合并線程數(shù)，所以這兩個值是用的是默認(rèn)值

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版本之后已經(jīng)取消了"indices.store.throttle.max_bytes_per_sec"，所以現(xiàn)在只能通過調(diào)整max_thread_count，max_merge_count，默認(rèn)max_thread_count最小是1最大是4，如果是機(jī)械盤推薦設(shè)1如果是ssd盤可以設(shè)成4或者更高，max_merge_count默認(rèn)等于max_thread_count+5，也可以單獨(dú)設(shè)置

可以通過命令查看默認(rèn)的集群參數(shù)配置：

GET _settings/?include_defaults

可以配置到配置文件當(dāng)中，也可以通過以下命令針對索引進(jìn)行動態(tài)設(shè)置：

PUT index_name/_settings 
{
    "index.merge.scheduler.max_thread_count": 4,
    "index.merge.scheduler.max_merge_count": 20
}

2.mlock

通過修改線程數(shù)之后，限流的問題解決了，但是應(yīng)用的寫入rt耗時問題還是沒有得到解決。通過對"hot_threads"進(jìn)行分析發(fā)現(xiàn)主要的耗時還是在merge和index兩大塊，并且通過os層面的監(jiān)控發(fā)現(xiàn)mlock的占用內(nèi)存一直在增長，啟動參數(shù)配置文件設(shè)置在內(nèi)存鎖定“bootstrap.memory_lock: true”不明白為什么還會出現(xiàn)mlock的增長。

處理辦法：

將硬件配置降回到32C64G問題解決，增加一副本來提升查詢性能