HBase更優(yōu)實(shí)踐-用好你的操作系統(tǒng)
終于又切回HBase模式了，之前一段時(shí)間因?yàn)楣ぷ鞯脑蛄私饨佑|了一段時(shí)間大數(shù)據(jù)生態(tài)的很多其他組件(諸如Parquet、Carbondata、Hive、SparkSQL、TPC-DS/TPC-H等)，雖然只是走馬觀花，但也受益良多。對視野、思維模式都有極其重要的作用，至少，擴(kuò)展了大數(shù)據(jù)領(lǐng)域的對話圈。這里也斗膽建議朋友能在深入研究一門學(xué)問的同時(shí)博覽周邊學(xué)問，相信必然會大有裨益。
來說正題，操作系統(tǒng)這個(gè)話題其實(shí)很早就想拿出來和大家分享，拖到現(xiàn)在一方面是因?yàn)閷ζ渲懈鞣N理論理解并不十分透徹，怕講不好;另一方面是這個(gè)問題好像一直以來都很少有人關(guān)注，這里算是給這個(gè)話題開個(gè)頭。其實(shí)這幾個(gè)參數(shù)前前后后看過好些次，但卻一直沒有吃透，前段時(shí)間趁著休假又把這些理論翻出來過了一遍，有了進(jìn)一步的理解，這里權(quán)當(dāng)整理梳理。下圖是HBase官方文檔上對操作系統(tǒng)環(huán)境的幾點(diǎn)配置要求：
先不著急解釋每個(gè)配置的具體含義，在這之前需要重點(diǎn)研究一個(gè)概念：swap，對，就這個(gè)大家或多或少聽說過的名詞，負(fù)責(zé)任的說，上述幾個(gè)參數(shù)或多或少都與swap有些關(guān)聯(lián)。
swap是干嘛的?
在Linux下，SWAP的作用類似Windows系統(tǒng)下的“虛擬內(nèi)存”。當(dāng)物理內(nèi)存不足時(shí)，拿出部分硬盤空間當(dāng)SWAP分區(qū)(虛擬成內(nèi)存)使用，從而解決內(nèi)存容量不足的情況。
SWAP意思是交換，顧名思義，當(dāng)某進(jìn)程向OS請求內(nèi)存發(fā)現(xiàn)不足時(shí)，OS會把內(nèi)存中暫時(shí)不用的數(shù)據(jù)交換出去，放在SWAP分區(qū)中，這個(gè)過程稱為SWAP OUT。當(dāng)某進(jìn)程又需要這些數(shù)據(jù)且OS發(fā)現(xiàn)還有空閑物理內(nèi)存時(shí)，又會把SWAP分區(qū)中的數(shù)據(jù)交換回物理內(nèi)存中，這個(gè)過程稱為SWAP IN。
當(dāng)然，swap大小是有上限的，一旦swap使用完，操作系統(tǒng)會觸發(fā)OOM-Killer機(jī)制，把消耗內(nèi)存最多的進(jìn)程kill掉以釋放內(nèi)存。
數(shù)據(jù)庫系統(tǒng)為什么嫌棄swap?
顯然，swap機(jī)制的初衷是為了緩解物理內(nèi)存用盡而選擇直接粗暴OOM進(jìn)程的尷尬。但坦白講，幾乎所有數(shù)據(jù)庫對swap都不怎么待見，無論MySQL、Oracal、MongoDB抑或HBase，為什么?這主要和下面兩個(gè)方面有關(guān)：
1. 數(shù)據(jù)庫系統(tǒng)一般都對響應(yīng)延遲比較敏感，如果使用swap代替內(nèi)存，數(shù)據(jù)庫服務(wù)性能必然不可接受。對于響應(yīng)延遲極其敏感的系統(tǒng)來講，延遲太大和服務(wù)不可用沒有任何區(qū)別，比服務(wù)不可用更嚴(yán)重的是，swap場景下進(jìn)程就是不死，這就意味著系統(tǒng)一直不可用……再想想如果不使用swap直接oom，是不是一種更好的選擇，這樣很多高可用系統(tǒng)直接會主從切換掉，用戶基本無感知。
2. 另外對于諸如HBase這類分布式系統(tǒng)來說，其實(shí)并不擔(dān)心某個(gè)節(jié)點(diǎn)宕掉，而恰恰擔(dān)心某個(gè)節(jié)點(diǎn)夯住。一個(gè)節(jié)點(diǎn)宕掉，最多就是小部分請求短暫不可用，重試即可恢復(fù)。但是一個(gè)節(jié)點(diǎn)夯住會將所有分布式請求都夯住，服務(wù)器端線程資源被占用不放，導(dǎo)致整個(gè)集群請求阻塞，甚至集群被拖垮。
從這兩個(gè)角度考慮，所有數(shù)據(jù)庫都不喜歡swap還是很有道理的!
swap的工作機(jī)制
既然數(shù)據(jù)庫們對swap不待見，那是不是就要使用swapoff命令關(guān)閉磁盤緩存特性呢?非也，大家可以想想，關(guān)閉磁盤緩存意味著什么?實(shí)際生產(chǎn)環(huán)境沒有一個(gè)系統(tǒng)會如此激進(jìn)，要知道這個(gè)世界永遠(yuǎn)不是非0即1的，大家都會或多或少選擇走在中間，不過有些偏向0，有些偏向1而已。很顯然，在swap這個(gè)問題上，數(shù)據(jù)庫必然選擇偏向盡量少用。HBase官方文檔的幾點(diǎn)要求實(shí)際上就是落實(shí)這個(gè)方針：盡可能降低swap影響。知己知彼才能百戰(zhàn)不殆，要降低swap影響就必須弄清楚Linux內(nèi)存回收是怎么工作的，這樣才能不遺漏任何可能的疑點(diǎn)。
先來看看swap是如何觸發(fā)的?
簡單來說，Linux會在兩種場景下觸發(fā)內(nèi)存回收，一種是在內(nèi)存分配時(shí)發(fā)現(xiàn)沒有足夠空閑內(nèi)存時(shí)會立刻觸發(fā)內(nèi)存回收;一種是開啟了一個(gè)守護(hù)進(jìn)程(swapd進(jìn)程)周期性對系統(tǒng)內(nèi)存進(jìn)行檢查，在可用內(nèi)存降低到特定閾值之后主動觸發(fā)內(nèi)存回收。***種場景沒什么可說，來重點(diǎn)聊聊第二種場景，如下圖所示：
這里就要引出我們關(guān)注的***個(gè)參數(shù)：vm.min_free_kbytes，代表系統(tǒng)所保留空閑內(nèi)存的***限watermark[min]，并且影響watermark[low]和watermark[high]。簡單可以認(rèn)為：
- watermark[min] = min_free_kbytes
- watermark[low] = watermark[min] * 5 / 4 = min_free_kbytes * 5 / 4
- watermark[high] = watermark[min] * 3 / 2 = min_free_kbytes * 3 / 2
- watermark[high] - watermark[low] = watermark[low] - watermark[min] = min_free_kbytes / 4
可見，LInux的這幾個(gè)水位線與參數(shù)min_free_kbytes密不可分。min_free_kbytes對于系統(tǒng)的重要性不言而喻，既不能太大，也不能太小。
min_free_kbytes如果太小，[min,low]之間水位的buffer就會很小，在kswapd回收的過程中一旦上層申請內(nèi)存的速度太快(典型應(yīng)用：數(shù)據(jù)庫)，就會導(dǎo)致空閑內(nèi)存極易降至watermark[min]以下，此時(shí)內(nèi)核就會進(jìn)行direct reclaim(直接回收)，直接在應(yīng)用程序的進(jìn)程上下文中進(jìn)行回收，再用回收上來的空閑頁滿足內(nèi)存申請，因此實(shí)際會阻塞應(yīng)用程序，帶來一定的響應(yīng)延遲。當(dāng)然，min_free_kbytes也不宜太大，太大一方面會導(dǎo)致應(yīng)用程序進(jìn)程內(nèi)存減少，浪費(fèi)系統(tǒng)內(nèi)存資源，另一方面還會導(dǎo)致kswapd進(jìn)程花費(fèi)大量時(shí)間進(jìn)行內(nèi)存回收。再看看這個(gè)過程，是不是和Java垃圾回收機(jī)制中CMS算法中老生代回收觸發(fā)機(jī)制神似，想想?yún)?shù)-XX:CMSInitiatingOccupancyFraction，是不是?官方文檔中要求min_free_kbytes不能小于1G(在大內(nèi)存系統(tǒng)中設(shè)置8G)，就是不要輕易觸發(fā)直接回收。
至此，基本解釋了Linux的內(nèi)存回收觸發(fā)機(jī)制以及我們關(guān)注的***個(gè)參數(shù)vm.min_free_kbytes。接下來簡單看看Linux內(nèi)存回收都回收些什么。Linux內(nèi)存回收對象主要分為兩種：
1. 文件緩存，這個(gè)容易理解，為了避免文件數(shù)據(jù)每次都要從硬盤讀取，系統(tǒng)會將熱點(diǎn)數(shù)據(jù)存儲在內(nèi)存中，提高性能。如果僅僅將文件讀出來，內(nèi)存回收只需要釋放這部分內(nèi)存即可，下次再次讀取該文件數(shù)據(jù)直接從硬盤中讀取即可(類似HBase文件緩存)。那如果不僅將文件讀出來，而且對這些緩存的文件數(shù)據(jù)進(jìn)行了修改(臟數(shù)據(jù))，回收內(nèi)存就需要將這部分?jǐn)?shù)據(jù)文件寫會硬盤再釋放(類似MySQL文件緩存)。
2. 匿名內(nèi)存，這部分內(nèi)存沒有實(shí)際載體，不像文件緩存有硬盤文件這樣一個(gè)載體，比如典型的堆、棧數(shù)據(jù)等。這部分內(nèi)存在回收的時(shí)候不能直接釋放或者寫回類似文件的媒介中，這才搞出來swap這個(gè)機(jī)制，將這類內(nèi)存換出到硬盤中，需要的時(shí)候再加載出來。
具體Linux使用什么算法來確認(rèn)哪些文件緩存或者匿名內(nèi)存需要被回收掉，這里并不關(guān)心，有興趣可以參考這里。但是有個(gè)問題需要我們思考：既然有兩類內(nèi)存可以被回收，那么在這兩類內(nèi)存都可以被回收的情況下，Linux到底是如何決定到底是回收哪類內(nèi)存呢?還是兩者都會被回收?這里就牽出來了我們第二個(gè)關(guān)心的參數(shù)：swappiness，這個(gè)值用來定義內(nèi)核使用swap的積極程度，值越高，內(nèi)核就會積極地使用swap，值越低，就會降低對swap的使用積極性。該值取值范圍在0～100，默認(rèn)是60。這個(gè)swappiness到底是怎么實(shí)現(xiàn)的呢?具體原理很復(fù)雜，簡單來講，swappiness通過控制內(nèi)存回收時(shí)，回收的匿名頁更多一些還是回收的文件緩存更多一些來達(dá)到這個(gè)效果。swappiness等于100，表示匿名內(nèi)存和文件緩存將用同樣的優(yōu)先級進(jìn)行回收，默認(rèn)60表示文件緩存會優(yōu)先被回收掉，至于為什么文件緩存要被優(yōu)先回收掉，大家不妨想想(回收文件緩存通常情況下不會引起IO操作，對系統(tǒng)性能影響較小)。對于數(shù)據(jù)庫來講，swap是盡量需要避免的，所以需要將其設(shè)置為0。此處需要注意，設(shè)置為0并不代表不執(zhí)行swap哦!
至此，我們從Linux內(nèi)存回收觸發(fā)機(jī)制、Linux內(nèi)存回收對象一直聊到swap，將參數(shù)min_free_kbytes以及swappiness進(jìn)行了解釋。接下來看看另一個(gè)與swap有關(guān)系的參數(shù)：zone_reclaim_mode，文檔說了設(shè)置這個(gè)參數(shù)為0可以關(guān)閉NUMA的zone reclaim，這又是怎么回事?提起NUMA，數(shù)據(jù)庫們又都不高興了，很多DBA都曾經(jīng)被坑慘過。那這里簡單說明三個(gè)小問題：NUMA是什么?NUMA和swap有什么關(guān)系?zone_reclaim_mode的具體意義?
NUMA(Non-Uniform Memory Access)是相對UMA來說的，兩者都是CPU的設(shè)計(jì)架構(gòu)，早期CPU設(shè)計(jì)為UMA結(jié)構(gòu)，如下圖(圖片來自網(wǎng)絡(luò))所示：
為了緩解多核CPU讀取同一塊內(nèi)存所遇到的通道瓶頸問題，芯片工程師又設(shè)計(jì)了NUMA結(jié)構(gòu)，如下圖(圖片來自網(wǎng)絡(luò))所示：
這種架構(gòu)可以很好解決UMA的問題，即不同CPU有專屬內(nèi)存區(qū)，為了實(shí)現(xiàn)CPU之間的”內(nèi)存隔離”，還需要軟件層面兩點(diǎn)支持：
1. 內(nèi)存分配需要在請求線程當(dāng)前所處CPU的專屬內(nèi)存區(qū)域進(jìn)行分配。如果分配到其他CPU專屬內(nèi)存區(qū)，勢必隔離性會受到一定影響，并且跨越總線的內(nèi)存訪問性能必然會有一定程度降低。
2. 另外，一旦local內(nèi)存(專屬內(nèi)存)不夠用，優(yōu)先淘汰local內(nèi)存中的內(nèi)存頁，而不是去查看遠(yuǎn)程內(nèi)存區(qū)是否會有空閑內(nèi)存借用。
這樣實(shí)現(xiàn)，隔離性確實(shí)好了，但問題也來了：NUMA這種特性可能會導(dǎo)致CPU內(nèi)存使用不均衡，部分CPU專屬內(nèi)存不夠使用，頻繁需要回收，進(jìn)而可能發(fā)生大量swap，系統(tǒng)響應(yīng)延遲會嚴(yán)重抖動。而與此同時(shí)其他部分CPU專屬內(nèi)存可能都很空閑。這就會產(chǎn)生一種怪現(xiàn)象：使用free命令查看當(dāng)前系統(tǒng)還有部分空閑物理內(nèi)存，系統(tǒng)卻不斷發(fā)生swap，導(dǎo)致某些應(yīng)用性能急劇下降。見葉金榮老師的MySQL案例分析：《找到MySQL服務(wù)器發(fā)生SWAP罪魁禍?zhǔn)?/a>》。
所以，對于小內(nèi)存應(yīng)用來講，NUMA所帶來的這種問題并不突出，相反，local內(nèi)存所帶來的性能提升相當(dāng)可觀。但是對于數(shù)據(jù)庫這類內(nèi)存大戶來說，NUMA默認(rèn)策略所帶來的穩(wěn)定性隱患是不可接受的。因此數(shù)據(jù)庫們都強(qiáng)烈要求對NUMA的默認(rèn)策略進(jìn)行改進(jìn)，有兩個(gè)方面可以進(jìn)行改進(jìn)：
1. 將內(nèi)存分配策略由默認(rèn)的親和模式改為interleave模式，即會將內(nèi)存page打散分配到不同的CPU zone中。通過這種方式解決內(nèi)存可能分布不均的問題，一定程度上緩解上述案例中的詭異問題。對于MongoDB來說，在啟動的時(shí)候就會提示使用interleave內(nèi)存分配策略：
- WARNING: You are running on a NUMA machine.
- We suggest launching mongod like this to avoid performance problems:
- numactl –interleave=all mongod [other options]
2. 改進(jìn)內(nèi)存回收策略：此處終于請出今天的第三個(gè)主角參數(shù)zone_reclaim_mode，這個(gè)參數(shù)定義了NUMA架構(gòu)下不同的內(nèi)存回收策略，可以取值0/1/3/4，其中0表示在local內(nèi)存不夠用的情況下可以去其他的內(nèi)存區(qū)域分配內(nèi)存;1表示在local內(nèi)存不夠用的情況下本地先回收再分配;3表示本地回收盡可能先回收文件緩存對象;4表示本地回收優(yōu)先使用swap回收匿名內(nèi)存。可見，HBase推薦配置zone_reclaim_mode=0一定程度上降低了swap發(fā)生的概率。
不都是swap的事
至此，我們探討了三個(gè)與swap相關(guān)的系統(tǒng)參數(shù)，并且圍繞Linux系統(tǒng)內(nèi)存分配、swap以及NUMA等知識點(diǎn)對這三個(gè)參數(shù)進(jìn)行了深入解讀。除此之外，對于數(shù)據(jù)庫系統(tǒng)來說，還有兩個(gè)非常重要的參數(shù)需要特別關(guān)注：
1. IO調(diào)度策略：這個(gè)話題網(wǎng)上有很多解釋，在此并不打算詳述，只給出結(jié)果。通常對于sata盤的OLTP數(shù)據(jù)庫來說，deadline算法調(diào)度策略是***的選擇。
2. THP(transparent huge pages)特性關(guān)閉。THP特性筆者曾經(jīng)疑惑過很久，主要疑惑點(diǎn)有兩點(diǎn)，其一是THP和HugePage是不是一回事，其二是HBase為什么要求關(guān)閉THP。經(jīng)過前前后后多次查閱相關(guān)文檔，終于找到一些蛛絲馬跡。這里分四個(gè)小點(diǎn)來解釋THP特性：
(1)什么是HugePage?
網(wǎng)上對HugePage的解釋有很多，大家可以檢索閱讀。簡單來說，計(jì)算機(jī)內(nèi)存是通過表映射(內(nèi)存索引表)的方式進(jìn)行內(nèi)存尋址，目前系統(tǒng)內(nèi)存以4KB為一個(gè)頁，作為內(nèi)存尋址的最小單元。隨著內(nèi)存不斷增大，內(nèi)存索引表的大小將會不斷增大。一臺256G內(nèi)存的機(jī)器,如果使用4KB小頁, 僅索引表大小就要4G左右。要知道這個(gè)索引表是必須裝在內(nèi)存的，而且是在CPU內(nèi)存，太大就會發(fā)生大量miss，內(nèi)存尋址性能就會下降。
HugePage就是為了解決這個(gè)問題，HugePage使用2MB大小的大頁代替?zhèn)鹘y(tǒng)小頁來管理內(nèi)存，這樣內(nèi)存索引表大小就可以控制的很小，進(jìn)而全部裝在CPU內(nèi)存，防止出現(xiàn)miss。
(2)什么是THP(Transparent Huge Pages)?
HugePage是一種大頁理論，那具體怎么使用HugePage特性呢?目前系統(tǒng)提供了兩種使用方式，其一稱為Static Huge Pages，另一種就是Transparent Huge Pages。前者根據(jù)名稱就可以知道是一種靜態(tài)管理策略，需要用戶自己根據(jù)系統(tǒng)內(nèi)存大小手動配置大頁個(gè)數(shù)，這樣在系統(tǒng)啟動的時(shí)候就會生成對應(yīng)個(gè)數(shù)的大頁，后續(xù)將不再改變。而Transparent Huge Pages是一種動態(tài)管理策略，它會在運(yùn)行期動態(tài)分配大頁給應(yīng)用，并對這些大頁進(jìn)行管理，對用戶來說完全透明，不需要進(jìn)行任何配置。另外，目前THP只針對匿名內(nèi)存區(qū)域。
(3)HBase(數(shù)據(jù)庫)為什么要求關(guān)閉THP特性?
THP是一種動態(tài)管理策略，會在運(yùn)行期分配管理大頁，因此會有一定程度的分配延時(shí)，這對追求響應(yīng)延時(shí)的數(shù)據(jù)庫系統(tǒng)來說不可接受。除此之外，THP還有很多其他弊端，可以參考這篇文章《why-tokudb-hates-transparent-hugepages》
(4)THP關(guān)閉/開啟對HBase讀寫性能影響有多大?
為了驗(yàn)證THP開啟關(guān)閉對HBase性能的影響到底有多大，本人在測試環(huán)境做了一個(gè)簡單的測試：測試集群僅一個(gè)RegionServer，測試負(fù)載為讀寫比1:1。THP在部分系統(tǒng)中為always以及never兩個(gè)選項(xiàng)，在部分系統(tǒng)中多了一個(gè)稱為madvise的選項(xiàng)。可以使用命令 echo never/always > /sys/kernel/mm/transparent_hugepage/enabled 來關(guān)閉/開啟THP。測試結(jié)果如下圖所示：
如上圖，TPH關(guān)閉場景下(never)HBase性能***，比較穩(wěn)定。而THP開啟的場景(always)，性能相比關(guān)閉的場景有30%左右的下降，而且曲線抖動很大。可見，HBase線上切記要關(guān)閉THP。
總結(jié)
任何數(shù)據(jù)庫系統(tǒng)的性能表現(xiàn)都與諸多因素相關(guān)，這里面有數(shù)據(jù)庫本身的各種因素，比如數(shù)據(jù)庫配置、客戶端使用、容量規(guī)劃、表scheme設(shè)計(jì)等，除此之外，基礎(chǔ)系統(tǒng)對其的影響也至關(guān)重要，比如操作系統(tǒng)、JVM等。很多時(shí)候數(shù)據(jù)庫遇到一些性能問題，左查右查都定位不了具體原因，這個(gè)時(shí)候就要看看操作系統(tǒng)的配置是否都合理了。本文從HBase官方文檔要求的幾個(gè)參數(shù)出發(fā)，詳細(xì)說明了這些參數(shù)的具體意義。
