談談對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的處理中，程序必須知道數據在內存的地址（好比M一、M二、M9......），還要知道在硬盤的地址（好比D2一、D2二、D29......）。同一份數據，每次從硬盤讀取到內存的地址都是隨機的（D21的數據此次在M1，下次可能就在M9）。

而虛擬內存則是把內存、硬盤的地址統一編號（S一、S二、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的各類操做都沒有寫，之後有機會再寫吧。即使是文章寫道的也確定會有謬誤，請你們批評指正。

祝你們新春玉快，闔家歡落~~~