[[335222]]

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

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

一、背景

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

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

目前賬單平臺為微信支付的這三類賬單提供寫入、存儲和查詢服務(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á)到要求，在個(gè)人賬單 ES 索引場景下，寫成功率為 99.85%，讀成功率為 99.95%，所以這里亟需優(yōu)化。

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

問題分析

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

 

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

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

 

那么是什么原因?qū)е?ES 節(jié)點(diǎn)的 CPU 抖動(dòng)呢?首先我們先確定 CPU 抖動(dòng)時(shí)系統(tǒng)具體在做什么，根據(jù)已有經(jīng)驗(yàn)，很有可能是 ES 熱點(diǎn)線程或 GC 導(dǎo)致的，但是在分析 CPU 抖動(dòng)時(shí) 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)計(jì)以及 perf 得到下面現(xiàn)象：

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

 

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

 

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

 

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

優(yōu)化方案

明確了抖動(dòng)問題原因后，那么我們接下來的優(yōu)化方向就是保證有足夠的空閑內(nèi)存，避免內(nèi)存不斷回收而出現(xiàn) CPU 抖動(dòng)。針對內(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 不能及時(shí)回收，其中 MMap 就可能導(dǎo)致 PageCache 不能正常回收，原因是 MMap 后應(yīng)用程序會引用到這部分內(nèi)存，則內(nèi)核在回收內(nèi)存時(shí)會忽略這部分內(nèi)存。而 ES 節(jié)點(diǎn)讀取文件的方式默認(rèn)就是 MMap，整體的內(nèi)存關(guān)聯(lián)關(guān)系如下圖：

 

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

 

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

但是采用 NIO 訪問文件也存在問題，即數(shù)據(jù)會多一次內(nèi)存復(fù)制，會導(dǎo)致延遲方面比 MMap 方式的高，經(jīng)過測試發(fā)現(xiàn)延遲會高 30%左右，這樣的結(jié)果也不是我們想要的，于是我們考慮將兩者結(jié)合起來，目的是加快內(nèi)存回收的同時(shí)降低延遲，采取的策略是根據(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)行一段時(shí)間后，現(xiàn)網(wǎng)的成功率逐漸降低，由 99.99%降低到 99.97%，對應(yīng)接入層的超時(shí)失敗也相應(yīng)增多，有了之前的經(jīng)驗(yàn)，我們相應(yīng)查看了 ES 節(jié)點(diǎn)的負(fù)載情況，發(fā)現(xiàn)仍然有 CPU 抖動(dòng)的現(xiàn)象(如下圖)。考慮到之前已經(jīng)優(yōu)化了內(nèi)存回收慢的問題，此時(shí)應(yīng)是新的問題導(dǎo)致的 CPU 抖動(dòng)，于是接下來優(yōu)化點(diǎn)依舊是解決抖動(dòng)。

 

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

 

采樣的結(jié)果可以明確 CPU 抖動(dòng)時(shí)，系統(tǒng)在進(jìn)行內(nèi)存碎片整合(即有 compact_zone()等函數(shù)調(diào)用)，這就意味著此時(shí)系統(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)存有兩個(gè) NODE，每個(gè) NODE 占了一半的物理內(nèi)存，其中 JVM 和 PageCache 分布在不同的 NODE 上)，這就意味著我們可以只優(yōu)化 PageCache 間的內(nèi)存碎片，這樣就可以滿足我們需求;對應(yīng)優(yōu)化流程如下：

 

具體分為兩個(gè)步驟：

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)存分布如下：

 

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

 

在現(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