[[335222]]

作者：empeliu，騰訊 TEG 后臺開發(fā)工程師

ElasticSearch 是一個分布式的開源搜索和分析引擎，因其功能強(qiáng)大、簡單易用而被應(yīng)用到很多業(yè)務(wù)場景。在生產(chǎn)環(huán)境使用 ES 時，如果未進(jìn)行優(yōu)化則服務(wù)的穩(wěn)定性可能得不到保障，目前我們使用 ES 作為賬單平臺的基礎(chǔ)組件為微信支付提供服務(wù)時就遇到這種問題。本文即從當(dāng)前的業(yè)務(wù)場景出發(fā)，分析 ES 穩(wěn)定性未到達(dá)要求的原因并提供相應(yīng)的解決思路。

一、背景

微信支付的賬單系統(tǒng)是方便用戶獲取交易記錄，針對不同的用戶群，賬單也分為三類：

• 個人賬單：針對普通用戶群，這類用戶特點(diǎn)是基數(shù)大，單個用戶數(shù)據(jù)量小，使用賬單系統(tǒng)主要是獲取列表以及基礎(chǔ)統(tǒng)計;
• 商戶賬單：針對商戶用戶群，這類用戶特點(diǎn)是基數(shù)小，單個用戶數(shù)據(jù)量非常大，使用賬單系統(tǒng)主要是獲取列表，并且在獲取列表時需要支持豐富查詢條件;
• 業(yè)務(wù)賬單：針對用戶群介于普通用戶和商戶之間，比如微商或面對面小商戶，使用賬單系統(tǒng)主要是獲取列表以及豐富統(tǒng)計功能;

目前賬單平臺為微信支付的這三類賬單提供寫入、存儲和查詢服務(wù)，基本架構(gòu)如下：

 

賬單平臺主要包括兩部分：

• 邏輯側(cè)：業(yè)務(wù)側(cè)直接對接模塊，主要是降低業(yè)務(wù)接入成本，提高接入效率;
• 存儲側(cè)：包含 ES 以及接入層 ESProxy，接入層對上屏蔽索引劃分機(jī)制，方便上層使用;

當(dāng)前微信支付對整體質(zhì)量要求非常高，體現(xiàn)在可用性方面是需要達(dá)到 99.99%，同樣賬單平臺也需要達(dá)到甚至超過該要求。但是在 ES 及系統(tǒng)環(huán)境未做優(yōu)化的情況下，讀寫成功率是沒有達(dá)到要求，在個人賬單 ES 索引場景下，寫成功率為 99.85%，讀成功率為 99.95%，所以這里亟需優(yōu)化。

二、內(nèi)存回收慢優(yōu)化

問題分析

針對讀寫成功率低問題，我們首先查看存儲側(cè)接入層 ESProxy 超時失敗的情況，對應(yīng)如下圖：

 

可以看出接入層訪問 ES 節(jié)點(diǎn)出現(xiàn)了大量超時，在排除接入層自身的問題后，基本上把問題源鎖定到 ES 節(jié)點(diǎn)。

通過進(jìn)一步確認(rèn) ES 節(jié)點(diǎn)負(fù)載情況(如下圖)，機(jī)器會出現(xiàn) CPU 抖動，而抖動時上層會出現(xiàn)超時，這就表明讀寫成功率低是 CPU 抖動導(dǎo)致的，于是我們重心就是解決 CPU 抖動問題。

 

那么是什么原因?qū)е?ES 節(jié)點(diǎn)的 CPU 抖動呢?首先我們先確定 CPU 抖動時系統(tǒng)具體在做什么，根據(jù)已有經(jīng)驗(yàn)，很有可能是 ES 熱點(diǎn)線程或 GC 導(dǎo)致的，但是在分析 CPU 抖動時 user 和 system 進(jìn)程占比情況，其中 user 進(jìn)程 CPU 占比基本沒有變化，而 system 進(jìn)程 CPU 卻增長很多，由于 ES 熱點(diǎn)線程或 GC 是 user 進(jìn)程，所以排除了這里的影響。通過系統(tǒng)相關(guān)統(tǒng)計以及 perf 得到下面現(xiàn)象：

• 抖動時系統(tǒng)在大量掃描可回收內(nèi)存

 

• 系統(tǒng)在不斷進(jìn)行內(nèi)存回收

 

• 系統(tǒng)分配內(nèi)存時出現(xiàn)了失敗

 

通過這三個現(xiàn)象，我們也得出了一個結(jié)論，CPU 抖動是因?yàn)閮?nèi)存不足導(dǎo)致。

優(yōu)化方案

明確了抖動問題原因后，那么我們接下來的優(yōu)化方向就是保證有足夠的空閑內(nèi)存，避免內(nèi)存不斷回收而出現(xiàn) CPU 抖動。針對內(nèi)存不足問題，我們首先確認(rèn)系統(tǒng)當(dāng)前的內(nèi)存分布情況，具體數(shù)據(jù)如下：

 

進(jìn)一步分析如下：

• ES 節(jié)點(diǎn)內(nèi)存主要是被 JVM 以及 PageCache 內(nèi)存占用
• Jvm 內(nèi)存是被 java 獨(dú)占，該部分內(nèi)存是不會被回收
• PageCache 內(nèi)存由操作系統(tǒng)維護(hù)，該部分內(nèi)存是可以被回收的

正常情況下，如果系統(tǒng)內(nèi)存不足，則內(nèi)核通過回收 PageCache 的內(nèi)存即可提供足夠的空閑內(nèi)存，即不會內(nèi)存不足的情況;反過來說，當(dāng)前出現(xiàn)內(nèi)存不足，則說明 PageCache 未被正常回收，于是針對內(nèi)存優(yōu)化則聚焦到 PageCache 回收問題上。

針對 PageCache 回收問題，首先我們先明確什么因素導(dǎo)致 PageCache 不能及時回收，其中 MMap 就可能導(dǎo)致 PageCache 不能正常回收，原因是 MMap 后應(yīng)用程序會引用到這部分內(nèi)存，則內(nèi)核在回收內(nèi)存時會忽略這部分內(nèi)存。而 ES 節(jié)點(diǎn)讀取文件的方式默認(rèn)就是 MMap，整體的內(nèi)存關(guān)聯(lián)關(guān)系如下圖：

 

既然 MMap 方式會導(dǎo)致 PageCache 不能及時回收，那么自然考慮是采用其他方式替換 MMap 去訪問文件，在 Java 中即可采用 NIO 方式讀取文件，對應(yīng)內(nèi)存關(guān)聯(lián)關(guān)系如下：

 

采用 NIO 方式訪問文件，PageCache 內(nèi)存只被操作系統(tǒng)維護(hù)，則內(nèi)核可以及時回收 PageCache 以保證足夠的內(nèi)存使用，這樣就解決了內(nèi)存不足問題，進(jìn)而解決 CPU 抖動問題，從而提高讀寫成功率;

但是采用 NIO 訪問文件也存在問題，即數(shù)據(jù)會多一次內(nèi)存復(fù)制，會導(dǎo)致延遲方面比 MMap 方式的高，經(jīng)過測試發(fā)現(xiàn)延遲會高 30%左右，這樣的結(jié)果也不是我們想要的，于是我們考慮將兩者結(jié)合起來，目的是加快內(nèi)存回收的同時降低延遲，采取的策略是根據(jù)訪問頻率來確定文件的讀寫方式(即高頻采用 MMap 方式，這樣可以保證延遲低，低頻采用 Nio 方式，這樣可以加快內(nèi)核回收 PageCache)，具體不同文件類型讀取方式如下表：

 

優(yōu)化效果

采用 MMap+Nio 的方式后，通過測試驗(yàn)證：

• 延遲方面和 MMap 基本一致
• 內(nèi)存回收方面也比 MMap 好

采用 MMap+Nio 組合方式上線后，對應(yīng)現(xiàn)網(wǎng)寫成功率由 99.85%提升到 99.99%。

三、高階內(nèi)存優(yōu)化

問題分析

在系統(tǒng)運(yùn)行一段時間后，現(xiàn)網(wǎng)的成功率逐漸降低，由 99.99%降低到 99.97%，對應(yīng)接入層的超時失敗也相應(yīng)增多，有了之前的經(jīng)驗(yàn)，我們相應(yīng)查看了 ES 節(jié)點(diǎn)的負(fù)載情況，發(fā)現(xiàn)仍然有 CPU 抖動的現(xiàn)象(如下圖)。考慮到之前已經(jīng)優(yōu)化了內(nèi)存回收慢的問題，此時應(yīng)是新的問題導(dǎo)致的 CPU 抖動，于是接下來優(yōu)化點(diǎn)依舊是解決抖動。

 

和之前分析 CPU 抖動問題一樣，我們先確認(rèn) CPU 抖動系統(tǒng)在做什么。通過 perf 分析，如下圖所示：

 

采樣的結(jié)果可以明確 CPU 抖動時，系統(tǒng)在進(jìn)行內(nèi)存碎片整合(即有 compact_zone()等函數(shù)調(diào)用)，這就意味著此時系統(tǒng)高階內(nèi)存是不足，為了進(jìn)一步驗(yàn)證當(dāng)前的高階內(nèi)存不足，通過 cat/proc/buddyinfo 查看當(dāng)前系統(tǒng)空閑內(nèi)存的分布情況，如下圖所示：

 

分析上面數(shù)據(jù)可以得出，當(dāng)前空閑內(nèi)存有 4G 左右，86%的內(nèi)存是 0 階內(nèi)存，大于等于 2 階的高階內(nèi)存占比只有 4%左右，這里驗(yàn)證當(dāng)前空閑內(nèi)存是基本都是碎片化的，碎片化內(nèi)存示意圖如下所示：

 

優(yōu)化方案

明確了當(dāng)前的問題后，那么接下來重點(diǎn)就是考慮將碎片化的內(nèi)存變成連續(xù)內(nèi)存。前文我們明確了當(dāng)前 ES 節(jié)點(diǎn)的內(nèi)存主要有兩部分組成，分別是 JVM 內(nèi)存和 PageCache 內(nèi)存，并且在我們現(xiàn)網(wǎng)環(huán)境中，這兩部分內(nèi)存基本上是獨(dú)立的(當(dāng)前現(xiàn)網(wǎng)機(jī)器內(nèi)存有兩個 NODE，每個 NODE 占了一半的物理內(nèi)存，其中 JVM 和 PageCache 分布在不同的 NODE 上)，這就意味著我們可以只優(yōu)化 PageCache 間的內(nèi)存碎片，這樣就可以滿足我們需求;對應(yīng)優(yōu)化流程如下：

 

具體分為兩個步驟：

1、釋放內(nèi)存：釋放 PageCache 內(nèi)存，保證新的空閑內(nèi)存盡可能連續(xù)，具體的處理措施是 echo1 > /proc/sys/vm/drop_cache

2、保留一定空閑內(nèi)存：目的是避免內(nèi)存的不斷申請和回收，導(dǎo)致內(nèi)存碎片化再次變的嚴(yán)重，具體處理措施是限制 PageCache 的大小(這里依賴 tlinux 的實(shí)現(xiàn))，具體的命令是 echo36 > /proc/sys/vm/pagecache_limit_ratio

優(yōu)化效果

經(jīng)過上述的優(yōu)化之后，系統(tǒng)的空閑內(nèi)存分布如下：

 

此時的空閑也是在 4G 左右，但是大于等于 2 階的高階內(nèi)存占比達(dá)到 95%左右，即高階內(nèi)存當(dāng)前是非常充足的，并且機(jī)器的 CPU 幾乎沒有抖動(如下圖所示)。

 

在現(xiàn)網(wǎng)進(jìn)行相應(yīng)調(diào)整之后，讀寫成功率提升效果如下：

寫成功率由 99.85%提升到 99.999%

讀成功率由 99.95%提升到 99.999%

四、結(jié)論

針對賬單平臺的 ES 系統(tǒng)的讀寫成功率未滿足要求，進(jìn)行了如下優(yōu)化措施：1、內(nèi)存回收慢優(yōu)化：優(yōu)化 ES 文件讀取方式，加快內(nèi)存回收，降低 CPU 在內(nèi)存回收方面消耗;2、高階內(nèi)存不足優(yōu)化：整理碎片化內(nèi)存，保證有充足高階內(nèi)存，降低 CPU 在內(nèi)存碎片整理消耗;

經(jīng)過上述優(yōu)化措施后，ES 系統(tǒng)的讀寫成功率達(dá)到 99.999%，超出當(dāng)前的可用性要求，保障 ES 在生產(chǎn)環(huán)境穩(wěn)定性。

參考：

1、Node Hot threadsAPI

2、Physical PageAllocation

3、Describing PhysicalMemory