HBase最佳實踐-管好你的操做系統

本文由  網易雲 發佈。

 

做者：範欣欣

本篇文章僅限本站分享，如需轉載，請聯繫網易獲取受權。

 

操做系統這個話題其實很早就想拿出來和你們分享，拖到如今一方面是由於對其中各類理論理解並不十分透徹，怕講很差；另外一方面是這個問題好像一直以來都不多有人關注，這裏算是給這個話題開個頭。其實這幾個參數前先後後看過好些次，但卻一直沒有吃透，前段時間趁着休假又把這些理論翻出來過了一遍，有了進一步的理解，這裏權當整理梳理。下圖是HBase官方文檔上對操做系統環境的幾點配置要求：

 

 

先不着急解釋每一個配置的具體含義，在這以前須要重點研究一個概念：swap，對，就這個你們或多或少據說過的名詞，負責任的說，上述幾個參數或多或少都與swap有些關聯。

swap是幹嗎的？

 

在Linux下，SWAP的做用相似Windows系統下的「虛擬內存」。當物理內存不足時，拿出部分硬盤空間當SWAP分區（虛擬成內存）使用，從而解決內存容量不足的狀況。

SWAP意思是交換，顧名思義，當某進程向OS請求內存發現不足時，OS會把內存中暫時不用的數據交換出去，放在SWAP分區中，這個過程稱爲SWAPOUT。當某進程又須要這些數據且OS發現還有空閒物理內存時，又會把SWAP分區中的數據交換回物理內存中，這個過程稱爲SWAPIN。

固然，swap大小是有上限的，一旦swap使用完，操做系統會觸發OOM-Killer機制，把消耗內存最多的進程kill掉以釋放內存。

數據庫系統爲何嫌棄swap？

顯然，swap機制的初衷是爲了緩解物理內存用盡而選擇直接粗暴OOM進程的尷尬。但坦白講，幾乎全部數據庫對swap都不怎麼待見，不管MySQL、Oracal、MongoDB抑或HBase，爲何？這主要和下面兩個方面有關：

1.數據庫系統通常都對響應延遲比較敏感，若是使用swap代替內存，數據庫服務性能必然不可接受。對於響應延遲極其敏感的系統來說，延遲太大和服務不可用沒有任何區別，比服務不可用更嚴重的是，swap場景下進程就是不死，這就意味着系統一直不可用……再想一想若是不使用swap直接oom，是否是一種更好的選擇，這樣不少高可用系統直接會主從切換掉，用戶基本無感知。

2.另外對於諸如HBase這類分佈式系統來講，其實並不擔憂某個節點宕掉，而偏偏擔憂某個節點夯住。一個節點宕掉，最多就是小部分請求短暫不可用，重試便可恢復。可是一個節點夯住會將全部分佈式請求都夯住，服務器端線程資源被佔用不放，致使整個集羣請求阻塞，甚至集羣被拖垮。

從這兩個角度考慮，全部數據庫都不喜歡swap仍是頗有道理的！

swap的工做機制

既然數據庫們對swap不待見，那是否是就要使用swapoff命令關閉磁盤緩存特性呢？非也，你們能夠想一想，關閉磁盤緩存意味着什麼？實際生產環境沒有一個系統會如此激進，要知道這個世界永遠不是非0即1的，你們都會或多或少選擇走在中間，不過有些偏向0，有些偏向1而已。很顯然，在swap這個問題上，數據庫必然選擇偏向儘可能少用。HBase官方文檔的幾點要求實際上就是落實這 個方針：儘量下降swap影響。知己知彼才能百戰不殆，要下降swap影響就必須弄清楚Linux內存回收是怎麼工做的，這樣才能不遺漏任何可能的疑點。

swap是如何觸發的？

簡單來講，Linux會在兩種場景下觸發內存回收，一種是在內存分配時發現沒有足夠空閒內存時會馬上觸發內存回收；一種是開啓了一個守護進程（swapd進程）週期性對系統內存進行檢查，在可用內存下降到特定閾值以後主動觸發內存回收。第一種場景沒什麼可說的，來重點聊聊第二種場景，以下圖所示：

 

這裏就要引出咱們關注的第一個參數：vm.min_free_kbytes，表明系統所保留空閒內存的最低限watermark[min]，而且影響watermark[low]和watermark[high]。簡單能夠認爲：

 

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的這幾個水位線與參數min_free_kbytes密不可分。min_free_kbytes對於系統的重要性不言而喻，既不能太大，也不能過小。

min_free_kbytes若是過小，［min,low］之間水位的buffer就會很小，在kswapd回收的過程當中一旦上層申請內存的速度太快

（典型應用：數據庫），就會致使空閒內存極易降至watermark[min]如下，此時內核就會進行directreclaim（直接回收），直接在應用程序的進程上下文中進行回收，再用回收上來的空閒頁知足內存申請，所以實際會阻塞應用程序，帶來必定的響應延遲。固然，min_free_kbytes也不宜太大，太大一方面會致使應用程序進程內存減小，浪費系統內存資源，另外一方面還會致使kswapd進程花費大量時間進行內存回收。再看看這個過程，是否是和Java垃圾回收機制中CMS算法中老生代回收觸發機制神似，想一想參數-XX:CMSInitiatingOccupancyFraction ， 是否是？ 官方文檔中要求min_free_kbytes不能小於1G （ 在大內存系統中設置8G），就是不要輕易觸發直接回收。

 

至此，基本解釋了Linux的內存回收觸發機制以及咱們關注的第一個參數vm.min_free_kbytes。接下來簡單看看Linux內存回收都回收些什麼。Linux內存回收對象主要分爲兩種：

1.文件緩存，這個容易理解，爲了不文件數據每次都要從硬盤讀取，系統會將熱點數據存儲在內存中，提升性能。若是僅僅將文件讀出來，內存回收只須要釋放這部份內存便可，下次再次讀取該文件數據直接從硬盤中讀取便可（相似HBase文件緩存）。那若是不只將文件讀出來，並且對這些緩存的文件數據進行了修改（髒數據），回收內存就須要將這部分數據文件寫會硬盤再釋放（相似MySQL文件緩存）。

2.匿名內存，這部份內存沒有實際載體，不像文件緩存有硬盤文件這樣一個載體，好比典型的堆、棧數據等。這部份內存在回收的時候不能直接釋放或者寫回相似文件的媒介中，這才搞出來swap這個機制，將這類內存換出到硬盤中，須要的時候再加載出來。

 

具體Linux使用什麼算法來確認哪些文件緩存或者匿名內存須要被回收掉，這裏並不關心，有興趣能夠參考這裏。可是有個問題須要咱們思考：既然有兩類內存能夠被回收，那麼在這兩類內存均可以被回收的狀況下，Linux究竟是如何決定究竟是回收哪類內存呢？仍是二者都會被回收？這裏就牽出來了咱們第二個關心的參數：swappiness，這個值用來定義內核使用swap的積極程度， 值越高，內核就會積極地使用swap，值越低，就會下降對swap的使用積極性。該值取值範圍在0～100，默認是60。這個swappiness究竟是怎麼實現的呢？具體原理很複雜，簡單來說，swappiness經過控制內存回收時，回收的匿名頁更多一些仍是回收的文件緩存更多一些來達到這個效果。swappiness等於100，表示匿名內存和文件緩存將用一樣的優先級進行回收，默認60 表示文件緩存會優先被回收掉，至於爲何文件緩存要被優先回收掉，你們不妨想一想（回收文件緩存一般狀況下不會引發IO操做，對系統性能影響較小）。對於數據庫來說，swap是儘可能須要避免的，因此須要將其設置爲0。此處須要注意，設置爲0並不表明不執行swap哦！

 

至此，咱們從Linux內存回收觸發機制、Linux內存回收對象一直聊到swap，將參數min_free_kbytes以及swappiness進行了解釋。接下來看看另外一個與swap 有關係的參數： zone_reclaim_mode ， 文檔說了設置這個參數爲0 能夠關閉NUMA 的zonereclaim，這又是怎麼回事？提起NUMA，數據庫們又都不高興了，不少DBA都曾經被坑慘過。那這裏簡單說明三個小問題：NUMA是什麼？NUMA和swap有什麼關係？zone_reclaim_mode的具體意義？

NUMA（Non-UniformMemoryAccess）是相對UMA來講的，二者都是CPU的設計架構，早期CPU設計爲UMA結構，以下圖

(圖片來自網絡)所示：

  

 

爲了緩解多核CPU讀取同一塊內存所遇到的通道瓶頸問題，芯片工程師又設計了NUMA結構，以下圖（圖片來自網絡）所示：

 

 

 

這種架構能夠很好解決UMA的問題，即不一樣CPU有專屬內存區，爲了實現CPU之間的」內存隔離」，還須要軟件層面兩點支持：

1.內存分配須要在請求線程當前所處CPU的專屬內存區域進行分配。若是分配到其餘CPU專屬內存區，勢必隔離性會受到必定影 響，而且跨越總線的內存訪問性能必然會有必定程度下降。

2.另外，一旦local內存（專屬內存）不夠用，優先淘汰local內存中的內存頁，而不是去查看遠程內存區是否會有空閒內存借用。

 

這樣實現，隔離性確實好了，但問題也來了：NUMA這種特性可能會致使CPU內存使用不均衡，部分CPU專屬內存不夠使用，頻繁須要回收，進而可能發生大量swap，系統響應延遲會嚴重抖動。而與此同時其餘部分CPU專屬內存可能都很空閒。這就會產生一種怪現象：使用free命令查看當前系統還有部分空閒物理內存，系統卻不斷髮生swap，致使某些應用性能急劇降低。見葉金榮老師的MySQL案例分析：《找到MySQL服務器發生SWAP罪魁禍首》。

 

因此，對於小內存應用來說，NUMA所帶來的這種問題並不突出，相反，local內存所帶來的性能提高至關可觀。可是對於數據庫這類內存大戶來講，NUMA默認策略所帶來的穩定性隱患是不可接受的。所以數據庫們都強烈要求對NUMA的默認策略進行改進，有兩個方面能夠進行改進：

1. 將內存分配策略由默認的親和模式改成interleave模式，即會將內存page打散分配到不一樣的CPUzone中。經過這種方式解決內存可能分佈不均的問題，必定程度上緩解上述案例中的詭異問題。對於MongoDB來講，在啓動的時候就會提示使用interleave內存分配策略：

 

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. 改進內存回收策略：此處終於請出今天的第三個主角參數zone_reclaim_mode，這個參數定義了NUMA架構下不一樣的內存回收策略，能夠取值0/1/3/4，其中0表示在local內存不夠用的狀況下能夠去其餘的內存區域分配內存；1表示在local內存不夠用的狀況下本地先回收再分配；3表示本地回收儘量先回收文件緩存對象；4表示本地回收優先使用swap回收匿名內存。可見，HBase 推薦配置zone_reclaim_mode＝0必定程度上下降了swap發生的機率。

 

不都是swap的事

 

1. IO調度策略：這個話題網上有不少解釋，在此並不打算詳述，只給出結果。一般對於sata盤的OLTP數據庫來講，deadline算法

調度策略是最優的選擇。

2. THP（transparenthugepages）特性關閉。THP特性筆者曾經疑惑過好久，主要疑惑點有兩點，其一是THP和HugePage是否是一回事，其二是HBase爲何要求關閉THP。通過前先後後屢次查閱相關文檔，終於找到一些蛛絲馬跡。這裏分四個小點來解釋THP特性：

（1）什麼是HugePage？

網上對HugePage的解釋有不少，你們能夠檢索閱讀。簡單來講，計算機內存是經過表映射（內存索引表）的方式進行內存尋址，目前系統內存以4KB爲一個頁，做爲內存尋址的最小單元。隨着內存不斷增大，內存索引表的大小將會不斷增大。一臺256G 內存的機器,若是使用4KB小頁,僅索引表大小就要4G左右。要知道這個索引表是必須裝在內存的，並且是在CPU內存，太大就會發生大量miss，內存尋址性能就會降低。

HugePage就是爲了解決這個問題，HugePage使用2MB大小的大頁代替傳統小頁來管理內存，這樣內存索引表大小就能夠控制的很小，進而所有裝在CPU內存，防止出現miss。

（2）什麼是THP（TransparentHugePages）?

HugePage是一種大頁理論，那具體怎麼使用HugePage特性呢？目前系統提供了兩種使用方式，其一稱爲StaticHugePages， 另外一種就是TransparentHugePages。前者根據名稱就能夠知道是一種靜態管理策略，須要用戶本身根據系統內存大小手動配置大頁個數，這樣在系統啓動的時候就會生成對應個數的大頁，後續將再也不改變。而TransparentHugePages是一種動態管理策略，它會在運行期動態分配大頁給應用，並對這些大頁進行管理，對用戶來講徹底透明，不須要進行任何配置。另外，目前THP 只針對匿名內存區域。

（3）HBase（數據庫）爲何要求關閉THP特性？

THP是一種動態管理策略，會在運行期分配管理大頁，所以會有必定程度的分配延時，這對追求響應延時的數據庫系統來講不可接受。除此以外，THP還有不少其餘弊端，能夠參考這篇文章《why-tokudb-hates-transparent-hugepages》

（4）THP關閉/開啓對HBase讀寫性能影響有多大？

 

爲了驗證THP開啓關閉對HBase性能的影響到底有多大，本人在測試環境作了一個簡單的測試：測試集羣僅一個RegionServer， 測試負載爲讀寫比1:1。THP在部分系統中爲always以及never兩個選項，在部分系統中多了一個稱爲madvise的選項。可使用命令echonever/always>/sys/kernel/mm/transparent_hugepage/enabled來關閉/開啓THP。測試結果以下圖所示：

 

 

 

如上圖，TPH關閉場景下（never）HBase性能最優，比較穩定。而THP開啓的場景（always），性能相比關閉的場景有30%左右的降低，並且曲線抖動很大。可見，HBase線上切記要關閉THP。

總結

任何數據庫系統的性能表現都與諸多因素相關，這裏面有數據庫自己的各類因素，好比數據庫配置、客戶端使用、容量規劃、表scheme設計等，除此以外，基礎系統對其的影響也相當重要，好比操做系統、JVM等。不少時候數據庫遇到一些性能問題，左查右查都定位不了具體緣由，這個時候就要看看操做系統的配置是否都合理了。本文從HBase官方文檔要求的幾個參數出發，詳細說明了這些參數的具體意義。

 

網易有數：企業級大數據可視化分析平臺。面向業務人員的自助式敏捷分析平臺，採用PPT模式的報告製做，更加易學易用，具有強大的探索分析功能，真正幫助用戶洞察數據發現價值。可點擊這裏免費試用。

 

瞭解 網易雲 ：
網易雲官網：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網易雲社區：https://sq.163yun.com/