大數據背景下，傳統關系型多維分析 ROLAP 引擎遇到極大挑戰，因而鏈家轉向基于 Hadoop 生態的 MOLAP(Kylin)及 HOLAP (多引擎)。

[[204914]]

本文分享鏈家在多維分析引擎方面的一些實踐經驗，主要從 OLAP 的背景和簡介、鏈家多維分析架構演進和展望、OLAP 平臺鏈路優化這三部分來介紹。

OLAP 的背景和簡介

01OLAP vs OLTP

OLAP 翻譯成中文叫聯機分析處理，OLTP 叫聯機事務處理。OLTP 的核心是事務，實際上就是我們常見的數據庫。

我們的業務數據庫面向事務，并發量比較高，但是操作的數據量比較小，它是實時更新的。

數據庫的設計會按照 3NF 范式，更高的話可能會按照 BC 范式之類的來做。而 OLAP 的核心是分析，面向應用是分析決策，需要分析的數據級會非常大，可能 TB，甚至 PB 都會有。

它的數據更新會稍微慢一些，因為面向分析的設計一般是反范式的。常見的是雪花模型和星型模型。

OLAP 實際上是什么呢?就是一個 SQL，這里按照兩個維度，一個 returnflag，一個 orderstatus 來做 Group By，然后做一下 Sum，Group By 這段就叫維度，From 這段叫做指標，非常簡單。

02OLAP 引擎分類

OLAP 引擎的一些常見分類大概有這兩種：

• ROLAP，叫關系型 OLAP。它的特點是基于關系性模型，計算的時候，根據原始數據去做聚合運算。常見的小數據量可以利用 MySQL、Oracle 這種傳統數據庫，而大數據量可以利用 Spark SQL、Presto 這些項目。
• MOLAP，叫多維 OLAP。它的特點就是它會基于一個預定義的模型，我需要知道，要根據什么維度，要去算哪些指標，我提前就把這些結果弄好，存儲在引擎上。當查詢的時候，根據結果簡單地做下匯總就可以得出來。

03HOLAP

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

圖1

如圖 1，是簡單的 ROLAP 模型，具體操作流程剛才已經提到了，它的優勢就是，它其實就是個數據庫，所以任何的 SQL 都可以在里面執行。數據是沒有冗余的。

缺點就是數據量很大的時候，計算速度會下降很多，所以并發會比較差。它的場景就是不知道要查什么數據，靈活性非常高時，一般會選 ROLAP。

04MOLAP

第二種 MOLAP，剛才提到 MOLAP 主要是要定義一個模型，比如說圖 2 樣例里面定義了三個維度：Time，Web page，Action。

圖2

從這三個維度把所有的組合提前預計算好，存在一個存儲引擎中，需要的時候里面取出來做一下聚合就可以，所以它的原始數據支持非常大，查詢速度，因為直接算好了，可以很快返回。

它的缺點就是因為聚合了以后，就查不到明細數據。它的靈活性稍微差一點，因為需要預先去定義維度，還有指標。所以說當需要能夠知道查詢的模式，才能用這個 MOLAP。

鏈家多維分析架構演進和展望

01早期分析數據實現

我們剛開始做大數據的時候，Hadoop 組建基本上都是基于開源的。我們會從日志、Kafka 去導數據，MySQL 數據會用 Sqoop 同步到 Hadoop 中。

當時是用一個開源的調度引擎 Ooize，我們根據業務需求去建表，然后把數據導到 MySQL 中，因為要做呈現，必須要在一個比較快的返回的數據庫中，所以放在 MySQL。

它的缺點是什么?當它的數據量越來越大，MySQL 做存儲，它的擴展性是非常不好的。數據量大以后，第二個問題是速度會比較慢。第三個，面臨分析的維度非常多，每個維度的分析，都要一個數據開發做需求，平均做一個需求時間可能要兩周。

圖3

02技術選型

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

響應要快，因為業務分析人員等不了太久，需要一定并發，***有一個 SQL 接口，支持數據級要非常大。當然離線方面，我們目前是 T+1 的模式，所以說綜合考慮選擇了 Kylin。

Kylin 就是基于 Hadoop 之上的提供 SQL 查詢和多維分析的能力，它能支持超大規模數據級。它能在亞秒返回巨大的一個查詢。

實際上它就是標準的 MOLAP 方案，我們需要預先定義維度和指標，提前預計算它的 Cube，把結果存在 HBase，查詢時解析 SQL，根據路由把它到 HBase 到對應的表中去拿取數據。

圖4

圖 4 是 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 左右，還是非常好的滿足了我們的需求。

03鏈家 OLAP 平臺架構

圖5

圖 5 是鏈家整個 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 的監控平臺。

圖6

圖 6 是報表查詢頁面，這里會顯示我有權限的報表，在里面搜索一下，我想看的一些報表。這是一張，首先選擇一個時間的維度，然后這里可以篩選很多條件，比如說根據分公司，根據店組去查。

比如想看東北區的詳情，點進去就可以顯示到這個區里面所有店主。如果需要看這個店主再點進去，就可以到這個店主里面的每個人。

這個在 OLAP 領域，這個過程叫做下鉆的過程。如果往回這個過程叫上卷，相當于把那個結果再往回聚合，我們感覺 UI 設計的還可以。

圖7

然后圖 7 這是我們自研的 Cube 管理。如果大家有用過 Kylin 的話，應該覺得主要的功能都是差不多的，因為都是根據 Kylin 來做定制的。

比如說選擇維度，選擇指標。然后可以設置一些參數，可以在這里面做查詢。它的未來可能就是它對接了我們權限平臺，能夠自己對它做管理。

04鏈家 OLAP 特色

總結一下鏈家 OLAP 的一些特色。一是自研的可視化平臺，支持上卷下鉆，維度對比，可視化報表創建，指標管理。

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

我們的引擎能力，其實并不是簡單的 MOLAP，而是一個混合的 OLAP 模型，既支持明細查詢，又支持聚合查詢。針對需求實現了跨 Cube 查詢的功能，就是 Kylin 中，一個 Cube 對應一張實時表，一個 Cube 里面只能查一張實時表的數據。

假如說有多個實時表，但是我查的維度是類似的，我想把結果做聚合運算，Kylin 是不支持的，我們平臺里面支持了跨 Cube 查詢。

然后在這里面完整監控，有高可用的架構。Cube 管理剛才也提到，前端會做一些簡化，對接了權限，簡化配置，提升我們的管理效率。

05OLAP 展望

下面是我們 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 的架構。就是內存中會維護***的狀態，這樣可以做到純實時的更新。

OLAP 平臺鏈路優化實踐

01Kylin 全鏈路架構

***講一些比較接地氣的，我們在 OLAP 平臺全鏈路的一些優化經驗。首先看一下 Kylin 的整個鏈路，最上頭的 Kylin，它的存儲引擎是 HBase，HBase 又基于 HDFS，所有程序都跑到了JVM 上。

首先是 Kylin 本身有一些優化，我們知道假如我們定義了 N 個維度，我查詢的時候，每一個維度可選擇或者不選擇，其實有 2 的 N 次方種選擇。

比如說 A、B、C、D 四個維度，這里頭一共有 16 種維度選擇。這個 Kylin 里面會提供很多方式來避免這種維度的膨脹，見圖 8。

圖8

***個是聚合組，用戶查詢的時候不會所有條件都查，而是同時只會出現某幾個維度，我們就把這幾個維度定義為一個聚合組。

比如說這里就用了 A、B、C 和 B、C、D，于是只有 A、B、C 內部的這些維度和 B、C、D 內部維度會進行計算，而且如果兩個有交叉，就會計算一份。

其他的各種衍生維度、強制維度、層次維度，大家如果做 Kylin 引擎，后續可以在這塊著重關注一下，我這邊就不詳細解釋了。

反正原理都是盡量根據查詢的一些條件或者業務的一些條件，盡量減少要計算的維度搭配。

02Kylin 改造以及優化

我們在 Kylin 里面做了很多改造和優化，***個是 Kylin 默認只能在 HBase 中，放在默認庫里面，前綴是 Kylin 加下劃線。

我們如果要在上面部署多套環境就會有沖突，我們這邊修改了一下，讓它支持配置一個前綴，可以在一套 HBase 中部署多套 Kylin。

我們之前講漏了一件事兒，剛才架構圖里面有一個預上線的 Kylin，我們所有的，因為上線前都會在預上線的 Kylin 里面進行驗證，然后只有它的數據 OK 了以后才會上到線上，預上線的環境。

還有第二個功能就是雙寫，假如一些重要的業務，我會在兩個集群里邊同時構建。如果主集群先出現問題，立馬切到備用集群。我們修復了它里面的一個死鎖的問題，主要是更新緩存部分，這個引擎加了社區。

然后接下來是一些，比如說構建的時候，MR 引擎的一些優化，比如開啟壓縮等等。Kylin 也是內存型的查詢服務，它是 Java 寫的，所以說自然 GC 的問題，等一下會詳細講一下。

如果你使用全局字典，你是要調大一些 MAP 內存。定期會做 Segment 的合并，清理一些過期數據，減少 HBase Region 個數。因為 HBase 如果 Region Server 太多，壓力非常大。

***還有一個默認使用的授權的時候，有個 Byct 加密，這個非常影響性能。后續我會講如何定位這個問題。

03系統性能調優

關于系統調優給大家推薦一個工具叫火焰圖，見圖 9。火焰圖是什么呢?它就是一個可視化的去展示 CPU 占用情況的圖。

圖9

每一個小方框里面都是一個函數，水平方向看它的寬度就是 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，我還是優先使用遠程的。后面會給一個對比數據，這個已經提交給社區。

圖10

圖10 是一個 HBase 就是讀寫分離。HBase 默認所有隊列和處理線程實際上是不區分的，我查詢請求分 Scan、Get、Write，三種請求都會打到相同的隊列里面。

如果出現了 Scan，把所有隊列和線程都堵滿了以后，簡單的小查詢都會卡住。這個是 HBase 在 1.2，還是 1.3 的時候已經實現了，我們可以把隊列和線程按照比例去分配給 Scan、Get、Write 三種請求，避免 Scan 請求阻塞小請求。

圖11

圖 11 是我們 HBase 的測試數據。大概是三臺機器，使用 ONESSD 測試工具。我們就關注綠色這條線，這條線就是吞吐量，或者叫 QPS 。

最右邊是 HDD，當我們使用 ONE-SSD 以后，大概能提升 4 倍左右的吞吐。我們再作用，上線 SSD-FIRST 策略以后，又能提升一倍的吞吐。

***在上線讀寫分離以后又能提升一倍，整體提升的大概 10 多倍。而且只有***步是需要硬件成本的，后面的兩個策略都是純策略上的調整。

圖12

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

下面講一些操作系統常見的一些調優。首先給大家講一個最常見的命令 Free，運行出來能顯示當前內存的情況。

我這里寫了三種境界，***種是剛接觸 Linux 同學，Free 是 0，是不是內存不夠了，是不是感覺要掛。經過一段時間學習，發現 Cache，Buffer 都是可以拿來用的，看第二行， Free 是 4G，內存什么問題都沒有。真正老司機是什么樣的呢?

我們要知道 Cache 是用來干什么的，使用的***率如何，Cache 是干什么的，Cache 默認就是 Page Cache，就是頁面緩存，主要是為了緩存文件系統，它在 VFS 里面會用到的。然后一般的 Cache 都是可以釋放出來給程序使用的。

但是有一種情況 Cache 不能釋放。就是有一種文件系統叫 tempfs，相當于內存的一個文件系統，利用了 Page Cache 的空間來做存儲，這種數據是沒法被清掉的。

所以 Cache 并不是所有的可以用。如果拿來做文件緩存，本身操作系統這么設計一定是有它的作用，我們想知道這個緩存***率如何。

我看了一下網上各種工具，實際上沒有一個對緩存***率計算的方法。還是剛才提到做火焰圖那哥們，在他的博客上公布了一個利用 ftrace 的方案，原理非常簡單。

***率我們現在算 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 這一塊。

[[204920]]

鄧鈁元

鏈家網大數據資深研發工程師

2015 年開始負責鏈家大數據集群建設，專注于 Hadoop 生態組的定制開發及應用，深入 Hadoop/HBase 等源碼，成為 contributor 回饋社區。擅長底層性能調優，打造公司級計算存儲平臺。