大資料背景下，傳統關係型多維分析 ROLAP 引擎遇到極大挑戰，因而鏈家轉向基於 Hadoop 生態的 MOLAP(Kylin)及 HOLAP （多引擎）。在架構師實踐日北京站中，鏈家大資料叢集架構組負責人鄧鍅元進行演講，分享了鏈家在多維分析引擎方面的一些實踐經驗，主要從 OLAP 的背景和簡介、鏈家多維分析架構演進和展望、OLAP 平臺鏈路優化這三部分來介紹。

1. OLAP vs OLTP

OLAP 翻譯成中文叫聯機分析處理，OLTP 叫聯機事務處理。OLTP 它的核心是事務，實際上就是我們常見的資料庫。我們業務資料庫就是面向於事務。它的併發量會比較高，但是操作的資料量會比較小。它是實時更新的。資料庫的設計會按照 3NF 正規化，更高的話可能會按照 BC 正規化之類的來做。而 OLAP 的核心是分析，面向應用是分析決策，需要分析的資料級會非常大，可能 TB，甚至 PB 都會有。它的資料更新會稍微慢一些，它的設計一般是反正規化的，因為面向分析。常見的是雪花模型和星型模型。

實際上 OLAP 是什麼呢？

非常簡單，就是一個 SQL，這裡按照兩個維度，一個 returnflag，一個 orderstatus 來做 Group By，然後做一下 Sum，Group By 這段就叫維度，From 這段叫做指標，非常簡單。

2. OLAP 引擎分類

OLAP 引擎的一些常見分類大概有這幾種。

• 第一種叫 ROLAP，叫關係型 OLAP，它的特點就是它是基於關係性模型，計算的時候，根據原始資料去做聚合運算。常見的實現，小資料量可以利用 MySQL、Oracle 這種傳統資料庫，而大資料量可以利用 Spark SQL、Presto 這些專案。

• 第二種型別叫 MOLAP

  ，叫多維 OLAP，它的特點就是它會基於一個預定義的模型，我需要知道，要根據什麼維度，要去算哪些指標，我提前就把這些結果弄好，儲存在引擎上。當查詢的時候，根據結果簡單地做一做彙總就可以得出來。今天主要會講到 Kylin 引擎，螞蜂窩的汪老師後續會講到 Druid 引擎。大家也可以做一下對比。

3. HOLAP

最後一種叫 HOLAP，叫混合 OLAP，這個就非常簡單了，就是兩個雜交一下。根據業務場景，採用不同的引擎。 

上圖這是簡單的 ROLAP 模型，具體操作流程剛才已經提到了，它的優勢就是，它其實就是個資料庫，所以任何的 SQL 都可以在裡面執行。資料是沒有冗餘的。缺點就是資料量很大的時候，計算速度會下降很多，所以併發會比較差。它的場景就是不知道要查什麼資料，靈活性非常高時，一般會選 ROLAP。

4. MOLAP

第二種 MOLAP，剛才提到 MOLAP 主要是要定義一個模型。比如說，下圖樣例裡面定義了三個維度：Time，Web page，Action。從這三個維度把所有的組合提前預計算好，存在一個儲存引擎中，需要的時候裡面取出來做一下聚合就可以，所以它的原始資料支援非常大，查詢速度，因為直接算好了，可以很快返回。它的缺點就是因為聚合了以後，就查不到明細資料。它的靈活性稍微差一點，因為需要預先去定義維度，還有指標。所以說是需要能夠知道查詢的模式，才能用這個 MOLAP。

1. 早期分析資料實現

我們剛開始做大資料的時候，Hadoop 組建基本上都是基於開源的。我們會從日誌、Kafka 去導資料，MySQL 資料會用 Sqoop 同步到 Hadoop 中。當時是用一個開源的排程引擎 Ooize，我們根據業務需求去建表，然後把資料導到 MySQL 中，因為要做呈現，必須要在一個比較快的返回的資料庫中。所以放在 MySQL。

它的缺點是什麼？

當它的資料量越來越大，MySQL 做儲存，它的擴充套件性是非常不好的。資料量大以後，第二個問題速度會比較慢。第三個，面臨分析的維度非常多，每個維度的分析，都要一個數據開發做需求，平均做一個需求時間可能要兩週。

2. 技術選型

能不能用一些 OLAP 引擎來簡化操作？我們總結了對 OLAP 引擎的一些需求。

第一，響應要快。因為業務分析人員等不了太久。需要一定併發。最好有一個 SQL 介面。支援資料級要非常大。當然離線方面，我們目前是 T+1 的模式，所以說綜合考慮選擇了 Kylin。Kylin 就是基於 Hadoop 之上的提供 SQL 查詢和多維分析的能力，它能支援超大規模資料級。它能在亞秒返回巨大的一個查詢。實際上它就是標準的 MOLAP 方案，我們需要預先定義維度和指標，提前預計算它的 Cube，把結果存在 HBase，查詢時解析 SQL，根據路由把它到 HBase 到對應的表中去拿取資料。

下圖是 Kylin 的架構圖，最下面是構建引擎，左邊是 Hadoop 資料倉庫，右邊是 HBase。最下面會根據 Hadoop 不同的原始資料進行構建，然後把資料存在 HBase。查詢的時候，在 Query Engine 做解析，解析完了以後，下面路由選擇，去 HBase 中查對應的資料。

左邊大家看到有根虛線，這個是什麼意思呢？剛才提到 MOLAP 只能支援預聚合的資料，要查原始的明細資料應該怎麼辦，Kylin 是不支援的。這條虛線劃出來，官方說會在後續某個版本支援，但實際上一直沒做。後面會講到我們是怎麼解決這個問題的。

再介紹一下鏈家 Kylin 使用統計，定位是離線的 OLAP 引擎。線上有 100 多個 Cube，公司 8 個業務現在使用，總共儲存容量應該也到 30T。總的資料量應該 800 億行左右，單個 Cube 最大已經到 40 億行。每天的查詢量大概有 10 萬多，查詢效能還是非常好的，95% 能在 500ms 以內，99% 都在 1s 中返回。除開那種超大的，可能會在 10s 左右，還是非常滿足我們需求的。

3. 鏈家 OLAP 平臺架構

上圖是鏈家整個 OLAP 平臺的架構。

首先核心還是基於 Kylin 這樣一個 MOLAP 引擎，我們 Kylin 做了讀寫分離的部署，也做了負載均衡的高可用。Build 機器是構建任務的機器，下面對接的是主要的 Hadoop 叢集，負責所有的資料倉庫儲存和所有的計算。

我們有自研的排程系統，每天會去排程 Kylin 的構建任務。關於排程系統，排程提供了很多功能，比如說分散式排程，會根據機器的負載情況去分發任務，會做任務的依賴，會做任務的監控等等。

為什麼第一塊是HBase叢集，而且還是單獨的叢集呢？

如果 HBase 跟 Hadoop 在一起，Hadoop 一旦執行大的任務，記憶體壓力大的時候，HBase 就會效能非常差，所以把查詢服務獨立出來。所有的查詢 Query 機器都會去查 HBase。上面指標分析平臺就是鏈家視覺化的分析平臺，它底層的引擎主要就是 Kylin，它所有的預建模的查詢都會走 Kylin，當然會做快取，把那些常用的 SQL，重複的 SQL 快取住。

第二塊就是剛才提到的，如果有查明細資料該怎麼辦？

鏈家這邊叢集組做了另一個引擎叫 Query Engine，這是我們自己的。它主要是給另外一個業務提供服務，提供即時查詢服務。它底層是兩個引擎，Presto 和 Spark SQL。在指標上會把明細的查詢和靈活的查詢，如果 Kylin 不支援，就會把它轉到 Query Engine，Query Engine 會根據它的 Cost來做優化，來選擇 Presto 或者 Spark SQL 來查詢。這樣就解決了明細查詢的問題。

指標分析平臺同時也對外提供 API，如果其他業務需要我們的資料，可以提供 API 的形式。然後 Cube 管理，Kylin 有原生頁面來做 Cube 管理的，但是那個原生的頁面會有很多問題。比如說涉及 LDAP 的許可權控制，跟鏈家的許可權是沒有打通的。它本身的效能是非常差。刷一個頁面可能要發幾十個 Post 請求，非常卡。於是我們獨立開發了一套 Cube 管理，集成了鏈家的許可權管理，效能會比原來好很多。

最後一塊就是預警監控，我們所有模組都有 Supervisior 存活監控，保證它掛了以後能啟動，整個鏈路都會上報到 OP 部門 維護的基於 Falcon 的監控平臺。

下圖是報表查詢頁面，這裡會顯示我有許可權的報表，在裡面搜尋一下，我想看的一些報表。

首先選擇一個時間的維度，然後這裡可以篩選很多條件，比如說根據分公司，根據店組去查。比如想看東北區的詳情，點進去就可以顯示到這個區裡面所有店主。如果需要看這個店主再點進去，就可以到這個店主裡面的每個人。這個在 OLAP 領域，這個過程叫做下鑽的過程。如果往回這個過程叫上卷，相當於把那個結果再往回聚合。我們感覺 UI 設計的還可以。

然後下圖這是我們自研的 Cube 管理。

如果大家有用過 Kylin 的話，應該覺得主要的功能都是差不多的，因為都是根據 Kylin 來做定製的。比如說選擇維度，選擇指標。然後可以設定一些引數，可以在這裡面做查詢。它的可能就是它對接了我們許可權平臺，能夠自己對它做管理。

4. 鏈家 OLAP 特色

總結一下鏈家 OLAP 的一些特色。

• 這是自研的視覺化平臺，支援上卷下鑽，維度對比，視覺化報表建立，指標管理。

• 開源的時候，其實有些開源產品比如說叫 Saiku，有些公司有應用。相比於它的話，個人感覺 UI 還是美觀一些，更切近業務，方便靈活定製。

• 我們的引擎能力，其實並不是簡單的 MOLAP，而是一個混合的 OLAP 模型，既支援明細查詢，又支援聚合查詢。

• 針對需求實現了跨 Cube 查詢的功能。就是 Kylin 中，一個 Cube 對應一張實時表。一個 Cube 裡面只能查一張實時表的資料。假如說有多個實時表，但是我查的維度是類似的，我想把結果做聚合運算，Kylin 是不支援的，我們平臺裡面支援了跨 Cube 查詢。

• 然後在這裡面完整監控，有高可用的架構。

• 前端做一些了簡化，對接了許可權，簡化配置，提升我們的管理效率。

5. OLAP 展望

下面是我們 OLAP 下半年的展望。

一是擴充套件能力。剛才提到已經有跨 Cube 查詢，但是隨著業務增長，可能有更多的需求。比如說想把 Kylin 的資料去跟 Hive 裡的資料做計算，或者業務那邊接入他們自己的 Oracle，裡面放了一些他們不想給我們的資料，但是想跟我們的資料做一些混合運算，我們這邊做一個多元資料查詢。

第二塊會做一些更多的路由優化，優化查詢效率。第三就是 Kylin 目前它的源資料同步，Build 機器相當於 Master，Query的機器相當於 Slave，目前是 Push 的模式，Build 機器 build 好了，把一些元資料同步過去。但是缺點是有時候會出現失敗的情況。我們目前做得非常 low，就是用 Crontab，定期讓 Slave 去重新刷一下快取。

後期我們正在做的就是讓 Slave 用心跳機制，Master 那裡用一個狀態機模型，把每一個要下發的任務放在狀態機裡，Slave 心跳了之後來取這個狀態。當我更新完快取以後，我在下次心跳的時候，把這個狀態再置為已經更新。其實這個非常類似於 Hadoop 裡面的 YARN 架構，都是基於狀態機的。這樣的話，擴充套件性會非常好，減少 Master 的一些壓力。我們正在做 Kylin 2.0 調研，比如它支援雪花模型，不用轉化資料倉庫。支援 Spark 構建，提升速度。

 第三塊，我們目前的 OLAP 還是一個離線服務，隨著業務的發展，我們有更多實時需求。主要是 MOLAP 裡面的一些實時的方向，一個是 Kylin 自身支援 Streaing Cubing，類似於 Spark Streaming，實際上是小批量近實時的，做到分鐘級。另外我們也考慮 Druid 或者 Palo 這些架構，它們是 Lambda 的架構。就是記憶體中會維護最新的狀態，這樣可以做到純實時的更新。

1. Kylin 全鏈路架構

最後講一些比較接地氣的，我們在 OLAP 平臺全鏈路的一些優化經驗。

首先看一下 Kylin 的整個鏈路。最上頭的 Kylin，它的儲存引擎是 HBase，HBase 又基於 HDFS。所有程式都跑到了JVM 上。首先是 Kylin 本身有一些優化，我們知道假如我們定義了 N 個維度，我查詢的時候，每一個維度可選擇或者不選擇，其實有 2 的 N 次方種選擇。比如說 A、B、C、D 四個維度，這裡頭一共有 16 種維度選擇。這個 Kylin 裡面會提供很多方式來避免這種維度的膨脹。

我這兒簡要介紹一下，見下圖。

第一個是聚合組，使用者查詢的時候不會所有條件都查，而是同時只會出現某幾個維度，我們就把這幾個維度定義為一個聚合組。比如說這裡就用了 A、B、C 和 B、C、D。於是只有 A、B、C 內部的這些維度和 B、C、D 內部維度會進行計算，而且如果兩個有交叉，就會計算一份。

其他的各種衍生維度、強制維度、層次維度，大家如果做 Kylin 引擎，後續可以在這塊著重關注一下，我這邊就不詳細解釋了。反正原理都是儘量根據查詢的一些條件或者業務的一些條件，儘量減少要計算的維度搭配。

2. Kylin 改造以及優化

我們在 Kylin 裡面做了很多改造和優化，第一個是 Kylin 預設只能在 HBase 中，放在預設庫裡面，字首是 Kylin 加下劃線。我們如果要在上面部署多套環境就會有衝突，我們這邊修改了一下，讓它支援配置一個字首，可以在一套 HBase 中部署多套 Kylin。

我們之前講漏了一件事兒，剛才架構圖裡面有一個預上線的 Kylin，我們所有的，因為上線前都會在預上線的 Kylin 裡面進行驗證，然後只有它的資料 OK 了以後才會上到線上，預上線的環境。還有第二個功能就是雙寫。假如一些重要的業務，我會在兩個叢集裡邊同時構建。如果主叢集先出現問題，立馬切到備用叢集。我們修復了它裡面的一個死鎖的問題，主要是更新快取部分，這個引擎加了社群。

然後接下來是一些，比如說構建的時候，MR 引擎的一些優化，比如開啟壓縮等等。Kylin 也是記憶體型的查詢服務，它是 Java 寫的，所以說自然 GC 的問題，等一下會詳細講一下。如果你使用全域性字典，你是要調大一些 MAP 記憶體。定期會做 Segment 的合併，清理一些過期資料，減少HBase Region 個數。因為 HBase 如果 Region Server 太多，壓力非常大。

最後還有一個預設使用的授權的時候，有個 Byct 加密，這個非常影響效能。後續我會講如何定位這個問題。

3. 系統性能調優

關於系統調優給大家推薦一個工具叫火焰圖，見下圖。

火焰圖是什麼呢？

它就是一個視覺化的去展示 CPU 佔用情況的圖。每一個小方框裡面都是一個函式，水平方向看它的寬度就是 CPU 的時間佔用，垂直方向看就是一個函式的堆疊。下面的函式就會呼叫上面的函式。所以自然上面函式的時間會累加到下面函式中。

如何定位效能的問題呢？

從下往上看，可以理解成，如果一個山峰一直沒有縮短，到最頂層的時候，呼叫堆疊最上面的一個函式，那是最終呼叫的函式，如果它佔用非常多，一定是它的效能問題。

我們之前發現 Kylin 在高併發的時候，CPU 會滿載，非常高，但是查詢非常簡單。利用火焰圖去分析發現，它有 80% 的時間在做一個 Spring 的 Bcybt 加密的驗證。然後右邊那一小塊佔 4% 的，這個才是 Kylin 的查詢。

我們查了一下，其實 Bcybt 加密是一個比較好，相當於是比較不容易破解的加密。它的方式就是讓它每次計算非常耗效能，降低它的速度。我們 將 Bcybt 加密換成了其他加密的演算法。大家可以看到，這段（Kylin 查詢部分）就是之前 4% 的時間，因為我把其他時間消掉了，所以它的佔比就大幅度提升，提升到 40%。提升了大概 1 倍 QPS。

第二塊就是 Java GC。其實 Java 大家應該還是比較熟悉的。像傳統的 CMS 非常經典，但是它的缺點就是對於大記憶體回收會有問題，而我們現在線上基本開到 80G，甚至 90G，CMS 在這種情況下基本上是 STW 非常長，可能要達到幾分鐘。

G1 是 Java 最新的垃圾回收演算法。它的核心還是保留了 CMS 的分代概念，但是它把每一代分成了很多 Region，打散。G1 定位是暫停時間可控的 GC，它會根據你設定暫停時間，在暫停時間內儘可能多地回收記憶體。因為打散成了很多 Region，我可以不全部回收，我可以回收部分，保證我每次回收的時間可控。因為新生代的 GC 是發生非常頻繁的，所以我們要控制新生代的大小，保證每次回收時間可控。

上圖是 GC 調優後的對比圖，上面是 CMS，下面是 Java。可以看到，GC 頻率和時間都有大幅地縮短。

第二塊就是我們 Java 的儲存是放在 Hbase 中，HBase 又放在 HDFS 中，HDFS 的底層就是物理上的磁碟。我想提升 Java 的查詢效能，從硬體上我就想，現在主流的磁碟 IOPS 可能就幾百，但是現在的 SSD，普通的 SSD 能達到幾萬，像 PCI 組建的 SSD 現在已經達到 30、40 萬 IOPS。

我們今年年初做了一件事情，我們把 Hadoop 叢集從 2.4 升到了 2.7，2.7 裡面引入了一個非常重要的特性，叫異構儲存，或叫混合儲存。就是 Hadoop 支援我把我的磁碟標記一個標籤，支援四種標籤。第一種叫記憶體磁碟，第二種叫 SSD，第三個是普通磁碟，最後一種是歸檔，歸檔是一種效能非常差的磁碟，可以認為。定義了儲存策略。比如說 ALLSSD 是指我的所有副本全放在 SSD 中，ONE-SSD 就是放一份，放在 SSD 中。預設是 Hot 全部放磁碟。我們這邊會把 HBase 的核心日誌，還有核心業務都會放在 ALLSSD 中，對重要業務會使用 ONE-SSD，如果是普通業務放在磁碟上就行了。

剛才提到，我們其實為了節省成本，如果用 SSD 也是主要用  ONE-SSD。ONE-SSD 有一個問題，假如說這個客戶端讀取資料，我有三個備份。其中一個是 SSD，但是我本地的副本是一個機械磁碟，預設的社群版會優先讀取本地，因為它的想法就是網路延遲是比較高的。但實際上我們鏈家大資料已經全部是萬兆的架構，所以說網路瓶頸已經是不存在的。我們這裡給它定製了一個 First 選擇策略，叫 SSD-FIRST。就是如果我遠端有 SSD，我還是優先使用遠端的。後面會給一個對比資料，這個已經提交給社群。

下圖是一個 HBase 就是讀寫分離。

HBase 預設所有佇列和處理執行緒實際上是不區分的，我查詢請求分 Scan、Get、Write。三種請求都會打到相同的佇列裡面。如果出現了 Scan，把所有佇列和執行緒都堵滿了以後，簡單的小查詢都會卡住。這個是 HBase 在 1.2，還是 1.3 的時候已經實現了，我們可以把佇列和執行緒按照比例去分配給 Scan、Get、Write 三種請求，避免 Scan 請求阻塞小請求。

下圖是我們 HBase 的測試資料。

大概是三臺機器，使用 ONESSD 測試工具。我們就關注綠色這條線，這條線就是吞吐量，或者叫 QPS 。最右邊是 HDD，當我們使用 ONE-SSD 以後，大概能提升 4 倍左右的吞吐。我們再作用，上線 SSD-FIRST 策略以後，又能提升一倍的吞吐。最後在上線讀寫分離以後又能提升一倍，整體提升的大概 10 多倍。而且只有第一步是需要硬體成本的，後面的兩個策略都是純策略上的調整。

下圖是很多常見的一些優化項，我這邊就不詳細解釋了。主要是針對 Hadoop 的一些讀寫優化。

一些作業系統常見的部分調優

首先給大家講一個最常見的命令 Free，執行出來能顯示當前記憶體的情況。我這裡寫了三種境界，第一種是剛接觸 Linux 同學，Free 是 0，是不是記憶體不夠了，是不是感覺要掛。經過一段時間學習，發現 Cache，Buffer 都是可以拿來用的。

看第二行， Free 是 4G，記憶體什麼問題都沒有。真正老司機是什麼樣的呢？我們要知道 Cache 是用來幹什麼的，使用的命中率如何，Cache 是幹什麼的，Cache 預設就是 Page Cache，就是頁面快取，主要是為了快取檔案系統，它在 VFS 裡面會用到的。然後一般的 Cache 都是可以釋放出來給程式使用的。但是有一種情況 Cache 不能釋放。就是有一種檔案系統叫 tempfs，相當於記憶體的一個檔案系統，利用了 Page Cache 的空間來做儲存，這種資料是沒法被清掉的。所以 Cache 並不是所有的可以用。如果拿來做檔案快取，本身作業系統這麼設計一定是有它的作用，我們想知道這個快取命中率如何。

我看了一下網上各種工具，實際上沒有一個對快取命中率計算的方法。命中率我們現在算 100%-Miss 的概率，Miss 是什麼情況呢？Miss 的分母就是 Page 的訪問次數，分子是，如果發生了 Misses，我就會把它從磁碟上讀出來，再放到快取中。所以說分子就是新增到 Page 快取的一個次數。

我們這邊因為 ftrace 會在系統上有問題，我用 System Tap 把指令碼改寫了一下，著重是四個系統的呼叫，System Tap 就是一個動態跟蹤技術，它可以在核心任何一個函式上動態去注入一段程式碼，然後可以規定在函式執行前或者是執行後，我們這裡只是給了四個過濾器，就是在四個條件上面做了過濾。

下面大家看一下 Total，裡面第一項叫 Mark Page Accessed，就是頁面訪問次數，Miss 的第一項就是新增到 LRU 快取的一個次數。後面減掉的一部分是什麼呢？大家知道，頁面快取除了去讀的時候用到，寫的時候也會用到。任何一次寫入都會寫入到 Page 中。有時候我們要從分子分母中把寫入的那部分資料給減掉。我們會把 Cache 的命中率定期同步到我們裡面做監控。我們線上現在應該能達到 70%-90% 的命中率。據我們的試驗，一般在 60% 以上，HBase 會比較穩定，因為 HBase 對於 IO 效能要求非常高。如果 Cache 命中率非常高，實際上每次讀寫都會非常快。當然這個也跟業務有關係。如果你的查詢是非常隨機的話，這個快取也很容易被弄髒。

下面講一個比較大的坑：NUMA。現在大家的伺服器基本上都是多個 CPU，常見的有兩種架構，一種叫 SMP，對稱多處理。記憶體其實是跟 CPU 之間連著一根匯流排。它的問題就是隨著CPU 越來越多，記憶體越來越大，所有的瓶頸都壓在總線上。接下來英特爾公司就想到另一個方案，就是我每個 CPU 給它自己專屬的記憶體，這個 CPU 的專屬記憶體訪問速度非常快。現在記憶體非常大，每個地方的專屬記憶體應該是足夠的，如果我實在是需要遠端記憶體，我再走主線。

預設是一個親和模式，什麼意思呢？

就是我這個 CPU 分配的記憶體和淘汰的記憶體都會優先從我的專屬記憶體中來找，比如說我專屬記憶體不夠用了，我就會優先從我專屬記憶體裡去淘汰。這樣會導致一個問題，我係統看系統非常充足，但是我發現有 SWAP 佔用，我的 Java 在做 GC。這個就非常奇怪。其實就是因為預設的親和模式造成的。

這個親和模式實際上對小記憶體應用非常好的，因為我一看 CPU 記憶體其實也很大了，至少 64G、128 個 G 都有，因為總共可能 256、512。單個小記憶體應用記憶體是足夠的，但是像 HBase 或者說資料庫，我們現在可以到 80G，甚至 100G，實際上單個 CPU 的專屬記憶體是不夠用的。我們這兒主要做了一個調整策略，就是把它的分配引數調整了一下。如果專屬記憶體不夠的時候，我允許從其他地方獲取記憶體，而不是去做本地的回收。

最後一個也是比較大的一個坑，就是透明大頁。什麼是透明大頁呢？大家知道，現在作業系統都是分頁的，每一個程式有一個頁表。程式分配都是邏輯地址，它要真的訪記憶體要通過一次邏輯地址到實體地址對映，然後 TLB 是用來做一個加速的，現在預設的大小是 4K，隨著記憶體越來越大就會有問題，頁表會越來越長，TLB 快取命中率也會降低。

作業系統想到一個方式，我就把配置調大，就給了兩個選項，一個是 2M，最大可以開到 1G。這樣看起來非常完美，但是在 6.5 的 centOS 中，這個大頁是預設開啟的，但是我們會發現 HBase 在使用過程中，CPU 佔用會非常異常，System Tap CPU 會非常高。大家可以看，JVM 的使用才 24%，但是我核心達到  32%，我們用 Perf 工具來做這個實時取樣。

會發現 Kernel 會發生在一個自選鎖上，自選鎖裡面是什麼呢？就能看到，會做一個異名的一個大頁記憶體分配。這個就會造成在系統非常繁忙的時候，核心的 CPU 佔用非常高。然後我們做了一個測試，在開啟透明大頁和關閉透明大頁，看藍色和紅色的線，在開啟透明大頁的功能以後，就是 Always 這個選項下，它的效能有很多毛刺，效能總體會下降 30%- 40%。所以說我們推薦把透明大頁關閉。當然作業系統還有很多其他的一些選項，這邊就不詳細說了，比如說檔案數限制，關閉 SWAP ，TCP 這一塊。

作者介紹：鄧鍅元，鏈家網大資料資深研發工程師。2015 年開始負責鏈家大資料叢集建設，專注於 Hadoop 生態組的定製開發及應用，深入 Hadoop/HBase 等原始碼，成為 contributor 回饋社群。擅長底層效能調優，打造公司級計算儲存平臺。

轉載自：http://mp.weixin.qq.com/s/nal1vKBcsQU3wgV5f4XH0g

相關閱讀：

資源下載

關注公眾號：資料和雲（OraNews）回覆關鍵字獲取

‘2017DTC’，2017DTC大會PPT

‘DBALIFE’，“DBA的一天”海報

‘DBA04’，DBA手記4經典篇章電子書

‘RACV1’, RAC系列課程視訊及ppt

‘122ARCH’，Oracle 12.2體系結構圖

‘2017OOW’，Oracle OpenWorld資料

‘PRELECTION’，大講堂講師課程資料