本篇文章記錄最近一次生產(chǎn)服務(wù)器硬件升級(jí)之后引起集群不穩(wěn)定的現(xiàn)象，希望可以幫到有其它人避免采坑。

一、問(wèn)題描述

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

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

二、升級(jí)過(guò)程升配前

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)出異常，寫(xiě)入ES的耗時(shí)變高了好十幾倍，從40ms上升到600ms；升配導(dǎo)致集群變慢還是頭一次遇到。通過(guò)對(duì)集群監(jiān)控分析集群整體負(fù)載正常比升配之前有所下降，但是indexing的寫(xiě)入耗時(shí)監(jiān)控確實(shí)比升配之前增長(zhǎng)了很多。在ES的輸出日志中出現(xiàn)了異常日志"stop throttling indexing: numMergesInFlight=8, maxNumMerges=9";

1.限流處理

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

由于配置文件沒(méi)有配置最大線程數(shù)和最大的合并線程數(shù)，所以這兩個(gè)值是用的是默認(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)在只能通過(guò)調(diào)整max_thread_count，max_merge_count，默認(rèn)max_thread_count最小是1最大是4，如果是機(jī)械盤(pán)推薦設(shè)1如果是ssd盤(pán)可以設(shè)成4或者更高，max_merge_count默認(rèn)等于max_thread_count+5，也可以單獨(dú)設(shè)置

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

GET _settings/?include_defaults

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

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

2.mlock

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

處理辦法：

將硬件配置降回到32C64G問(wèn)題解決，增加一副本來(lái)提升查詢性能

3、總結(jié)

經(jīng)過(guò)3天問(wèn)題排查，網(wǎng)上也沒(méi)有找到類似的案例，網(wǎng)上更多的還是限流相關(guān)的案例，總結(jié)下來(lái)應(yīng)該還是當(dāng)前版本對(duì)于大內(nèi)存的處理相關(guān)的bug，在7.x版本沒(méi)有出現(xiàn)類似的內(nèi)存問(wèn)題

到此這篇關(guān)于Elasticsearch6.2服務(wù)器升配后的bug的文章就介紹到這了,更多相關(guān)Elasticsearch6.2服務(wù)器內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論