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

一、背景

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

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

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

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

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

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

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

問題分析

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

可以看出接入層訪問 ES 節(jié)點出現(xiàn)了大量超時，在排除接入層自身的問題后，基本上把問題源鎖定到 ES 節(jié)點。通過進一步確認 ES 節(jié)點負載情況（如下圖），機器會出現(xiàn) CPU 抖動，而抖動時上層會出現(xiàn)超時，這就表明讀寫成功率低是 CPU 抖動導致的，于是我們重心就是解決 CPU 抖動問題。

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

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

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

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

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

優(yōu)化方案

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

進一步分析如下：

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

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

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

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

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

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

優(yōu)化效果

采用 MMap+Nio 的方式后，通過測試驗證：

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

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

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

問題分析

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

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

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

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

優(yōu)化方案

明確了當前的問題后，那么接下來重點就是考慮將碎片化的內(nèi)存變成連續(xù)內(nèi)存。前文我們明確了當前 ES 節(jié)點的內(nèi)存主要有兩部分組成，分別是 JVM 內(nèi)存和 PageCache 內(nèi)存，并且在我們現(xiàn)網(wǎng)環(huán)境中，這兩部分內(nèi)存基本上是獨立的（當前現(xiàn)網(wǎng)機器內(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)存的不斷申請和回收，導致內(nèi)存碎片化再次變得嚴重，具體處理措施是限制 PageCache 的大小（這里依賴 tlinux 的實現(xiàn)），具體的命令是 echo36 > /proc/sys/vm/pagecache_limit_ratio

優(yōu)化效果

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

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

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

• 寫成功率由 99.85%提升到 99.999%
• 讀成功率由 99.95%提升到 99.999%

四、結(jié)論

針對賬單平臺的 ES 系統(tǒng)的讀寫成功率未滿足要求，進行了如下優(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)的讀寫成功率達到 99.999%，超出當前的可用性要求，保障 ES 在生產(chǎn)環(huán)境穩(wěn)定性。