Huge Page 是不是拯救性能的萬能良藥？

時間 2019-12-12

標籤 huge page 是不是拯救性能萬能良藥欄目系統性能简体版

原文原文鏈接

本文將分析是否Huge Page在任何條件下（特別是NUMA架構下）都能帶來性能提高。node

本博客已經遷移至：

http://cenalulu.github.io/linux

爲了更好的體驗，請經過此連接閱讀：

http://cenalulu.github.io/linux/huge-page-on-numa/git

文章歡迎轉載，但轉載時請保留本段文字，並置於文章的頂部
做者：盧鈞軼(cenalulu)
本文原文地址：http://cenalulu.github.io/linux/huge-page-on-numa/github

準備知識

在閱讀本文以前，須要讀者至少了解如下基礎知識數據庫

CPU Cache的基本概念，具體可參見關於CPU Cache -- 程序猿須要知道的那些事。
NUMA的基本概念，具體可參見博客以前的科普介紹
目前Linux基於多核CPU繁忙程度的線程調度機制，參看Chip Multi Processing aware Linux Kernel Scheduler論文

關於Huge Page

在正式開始本文分析前，咱們先大概介紹下Huge Page的歷史背景和使用場景。數組

爲何須要Huge Page
瞭解CPU Cache大體架構的話，必定聽過TLB Cache。Linux系統中，對程序可見的，可以使用的內存地址是Virtual Address。每一個程序的內存地址都是從0開始的。而實際的數據訪問是要經過Physical Address進行的。所以，每次內存操做，CPU都須要從page table中把Virtual Address翻譯成對應的Physical Address，那麼對於大量內存密集型程序來講page table的查找就會成爲程序的瓶頸。因此現代CPU中就出現了TLB(Translation Lookaside Buffer) Cache用於緩存少許熱點內存地址的mapping關係。然而因爲制形成本和工藝的限制，響應時間須要控制在CPU Cycle級別的Cache容量只能存儲幾十個對象。那麼TLB Cache在應對大量熱點數據Virual Address轉換的時候就顯得捉襟見肘了。咱們來算下按照標準的Linux頁大小(page size) 4K，一個能緩存64元素的TLB Cache只能涵蓋4K*64 = 256K的熱點數據的內存地址，顯然離理想很是遙遠的。因而Huge Page就產生了。
Tips: 這裏不要把Virutal Address和Windows上的虛擬內存搞混了。後者是爲了應對物理內存不足，而將內容從內存換出到其餘設備的技術（相似於Linux的SWAP機制）。緩存

什麼是Huge Page
既然改變不了TLB Cache的容量，那麼只能從系統層面增長一個TLB Cache entry所能對應的物理內存大小，從而增長TLB Cache所能涵蓋的熱點內存數據量。假設咱們把Linux Page Size增長到16M，那麼一樣一個容納64個元素的TLB Cache就能顧及64*16M = 1G的內存熱點數據，這樣的大小相較上文的256K就顯得很是適合實際應用了。像這種將Page Size加大的技術就是Huge Page。session

Huge Page是萬能的？

瞭解了Huge Page的由來和原理後，咱們不難總結出能從Huge Page受益的程序必然是那些熱點數據分散且至少超過64個4K Page Size的程序。此外，若是程序的主要運行時間並非消耗在TLB Cache Miss後的Page Table Lookup上，那麼TLB再怎麼大，Page Size再怎麼增長都是徒勞。在LWN的一篇入門介紹中就提到了這個原理，而且給出了比較詳細的估算方法。簡單的說就是：先經過oprofile抓取到TLB Miss致使的運行時間佔程序總運行時間的多少，來計算出Huge Page所能帶來的預期性能提高。
簡單的說，咱們的程序若是熱點數據只有256K，而且集中在連續的內存page上，那麼一個64個entry的TLB Cache就足以應付了。說道這裏，你們可能有個疑問了：既然咱們比較難預測本身的程序訪問邏輯是否能從開啓Huge Page中受益。反正Huge Page看上去只改了一個Page Size，不會有什麼性能損失。那麼咱們就索性對全部程序都是用Huge Page好啦。
其實這樣的想法是徹底錯誤的！也正是本文想要介紹的一個主要內容，在目前常見的NUMA體系下Huge Page也並不是萬能鑰匙，使用不當甚至會使得程序或者數據庫性能降低10%。下面咱們重點分析。架構

Huge Page on NUMA

Large Pages May Be Harmful on NUMA Systems一文的做者曾今作過一個實驗，測試Huge Page在NUMA環境的各類不一樣應用場景下帶來的性能差別。從下圖能夠看到Huge Page對於至關一部分的應用場景並不能很好的提高性能，甚至會帶來高達10%的性能損耗。
app

性能降低的緣由主要有如下兩點

CPU對同一個Page搶佔增多

對於寫操做密集型的應用，Huge Page會大大增長Cache寫衝突的發生機率。因爲CPU獨立Cache部分的寫一致性用的是MESI協議，寫衝突就意味：

經過CPU間的總線進行通信，形成總線繁忙
同時也下降了CPU執行效率。
CPU本地Cache頻繁失效

類比到數據庫就至關於，原來一把用來保護10行數據的鎖，如今用來鎖1000行數據了。必然這把鎖在線程之間的爭搶機率要大大增長。

從下圖咱們能夠看到，本來在4K小頁上能夠連續分配，並由於較高命中率而在同一個CPU上實現locality的數據。到了Huge Page的狀況下，就有一部分數據爲了填充統一程序中上次內存分配留下的空間，而被迫分佈在了兩個頁上。而在所在Huge Page中佔比較小的那部分數據，因爲在計算CPU親和力的時候權重小，天然就被附着到了其餘CPU上。那麼就會形成：本該以熱點形式存在於CPU2 L1或者L2 Cache上的數據，不得不經過CPU inter-connect去remote CPU獲取數據。
假設咱們連續申明兩個數組，Array A和Array B大小都是1536K。內存分配時因爲第一個Page的2M沒有用滿，所以Array B就被拆成了兩份，分割在了兩個Page裏。而因爲內存的親和配置，一個分配在Zone 0，而另外一個在Zone 1。那麼當某個線程須要訪問Array B時就不得不經過代價較大的Inter-Connect去獲取另一部分數據。

delays re-sulting from traversing a greater physical distance to reach a remote node, are not the most important source of performance overhead. On the other hand, congestion on interconnect links and in memory controllers, which results from high volume of data flowing across the system, can dramatically hurt performance.

Under interleaving, the memory latency re- duces by a factor of 2.48 for Streamcluster and 1.39 for PCA. This effect is entirely responsible for performance improvement under the better policy. The question is, what is responsible for memory latency improvements? It turns out that interleaving dramatically reduces memory controller and interconnect congestion by allevi- ating the load imbalance and mitigating traffic hotspots.

對策

理想

咱們先談談理想狀況。上文提到的論文其實他的主要目的就是討論一種適用於NUMA架構的Huge Page自動內存管理策略。這個管理策略簡單的說是基於Carrefour的一種對Huge Page優化的變種。（注：不熟悉什麼是Carrefour的讀者能夠參看博客以前的科普介紹或者閱讀原文）
下面是一些相關技術手段的簡要歸納：

爲了減小隻讀熱點數據跨NUMA Zone的訪問，能夠將讀寫比很是高的Page，使用Replication的方式在每一個NUMA Zone的Direct內存中都複製一個副本，下降響應時間。
爲了減小False Sharing，監控形成大量Cache Miss的Page，並進行拆分重組。將同一CPU親和的數據放在同一個Page中

現實

談完了理想，咱們看看現實。現實每每是殘酷的，因爲沒有硬件級別的PMU(Performance Monitor Unit)支持，獲取精準的Page訪問和Cache Miss信息性能代價很是大。因此上面的理想僅僅停留在實驗和論文階段。那麼在理想實現以前，咱們如今該怎麼辦呢？
答案只有一個就是測試

實際測試
實際測試的結果最具備說服力。所謂實際測試就是把優化對象給予真實環境的壓力模擬。經過對比開啓和關閉Huge Page時的性能差異來驗證Huge Page是否會帶來性能提高。固然大多數應用程序，要想模擬真實環境下的運行狀況是很是困難的。那麼咱們就能夠用下面這種理論測試

理論測試
理論測試能夠經過profile預估出Huge Page可以帶來的潛在提高。具體原理就是計算當前應用程序運行時TLB Miss致使的Page Walk成本佔程序總執行時間的佔比。固然這種測試方式沒有把上文提到的那兩種性能損失考慮進去，因此只能用於計算Huge Page所能帶來的潛在性能提高的上限。若是計算出來這個值很是低，那麼能夠認爲使用Huge Page則會帶來額外的性能損失。具體方法見LWN上介紹的方法
具體的計算公式以下圖：

若是沒有hardware的PMU支持的話，計算須要用到oprofile和calibrator。