談談對Linux的Huge Pages與Transparent Huge Pages的認識

因為安裝MangoDB要禁用THP，就比較好奇原因，所以才有了以下。

Huge Pages（以下簡稱HP），又叫「大頁」（編者註：你看我們搞IT的，翻譯起來就是那麼的直白生猛），或者叫「標準大頁」、「傳統大頁」——這就是相對Transparent Huge Pages（以下簡稱THP）「透明大頁」來的名字。

我們知道CPU讀取數據，順序一般是：一級緩存-->二級緩存-->內存-->硬碟（不嚴謹，但是大家都明白這個意思）。讀取速度依次變慢。

拋開Cache不談，我們做個不恰當的比喻，CPU就是售貨員，負責拿貨給客人，要想速度快，最好的辦法就是把商品（程序的數據、指令等）放在櫃檯（內存）里，但是櫃檯畢竟有限，而且要裝很多種商品（不同的程序），不可能完全放下，那麼大量的商品還是會放在後面的倉庫（硬碟）。

這樣處理，問題：

A、櫃檯對所有商品是開放的。甲商品可以把櫃檯里放著的乙商品隨意處置，乙商品就懵B了。

B、櫃檯空間不足，賣的甲商品一旦過多，就得把其他商品挪到倉庫里，再把甲商品從倉庫提出來放在櫃檯里。這一進一出，效率極其低下。

C、我們可以將程序分割成小份，先在內存處理A部分，然後從硬碟調取B部分，駐留在內存進行處理。但是現在的程序功能複雜，用戶腦洞太大，程序員也無法預測處理完A部分之後，接下來一定就是B部分。

等等吧，以上這些內存的定址、讀取、清理等操作，要全靠程序員來處理，所以打擊知道為什麼程序員多禿頂了吧。

為了解決這些問題，不讓程序員干預內存的處理，就有了虛擬內存技術。

簡單地說，在硬碟划出一塊，叫SWAP分區，跟物理內存一樣，被系統當做內存對待，但畢竟不是真內存，故稱虛擬內存。

OS把暫時用不到的數據，放入SWAP區，當要處理的數據不在物理內存中時，從硬碟再讀取至內存。

各位看官會說，這和剛才我們說的問題C有什麼區別？區別就在「地址」！

在問題C的處理中，程序必須知道數據在內存的地址（比如M1、M2、M9......），還要知道在硬碟的地址（比如D21、D22、D29......）。同一份數據，每次從硬碟讀取到內存的地址都是隨機的（D21的數據這次在M1，下次可能就在M9）。

而虛擬內存則是把內存、硬碟的地址統一編號（S1、S2、S3......），對於程序來說，這份數據在S3就在S3，不管它是在內存還是硬碟，我不care。

還有其他的好處，比如我們說到的問題A，虛擬內存就可以控制進程對內存的訪問許可權，再不能隨意處理了。對於程序來說，可以分配連續的虛擬內存地址——哪怕物理地址不連續。通過頁面調度（從硬碟讀取數據至內存，從內存寫數據至硬碟）演算法——先進先出（FIFO）、最近最少使用（LRU）、最佳頁面替換（OPT）等，盡量避免問題B中，裝入裝出大量數據造成的性能浪費。不再一一解釋。

關鍵在於虛擬內存地址，它畢竟不是真實的地址，程序說我要S1的數據，CPU就必須給出真實的地址（M1或D21），這塊工作是有Translation Lookaside Buffer（TLB）來做的，TLB通過頁表（Page Table）這種數據結構，緩存了虛擬頁與物理頁的映射關係。打個比方，有點類似虛擬地址:物理地址這樣的鍵值對（當然沒那麼簡單，大家理解即可）。

但是當我們使用Oracle、MangoDB這樣需要大內存的應用時，可想而知，這個頁表會很大很大。我們知道Linux管理內存，是以4K為一個頁面進行管理的。當數據很大的時候，除以4K，所需的頁表也會越來越大，維護頁表就變得很消耗資源。

舉個例子，一個公務員如果想建立一個居民信息表，要是以家庭為單位，那麼映射表就會很大，解決辦法呢？我們就用小區為單位吧~~~

這就是「大頁」（Huge Pages），更大的頁！同樣的數據，除以4K，需要多少條目，除以2M（HP默認的大小），又需要多少條目，不言而喻。

終於說到本文主題了，不過好像可說的也不多了。

THB相對於HB來說，區別主要在於HB是要預分配的，而THB則是由khugepaged進程進行動態分配。可想而知，對於DB這種內存操作頻繁的應用，預分配的更省事，第一次搞好即可，不用每次現分配。Oracle就要求關閉Linux默認啟用的THB。

今天是2019乙亥豬年初一，文章前兩天就開始邊查資料邊寫，很倉促，裡面很多知識點沒有寫，比如虛擬內存、HB的優點、HB/TLB的各種操作都沒有寫，以後有機會再寫吧。即便是文章寫道的也肯定會有謬誤，請大家批評指正。

祝大家新春玉快，闔家歡落~~~

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！