歡迎光臨
每天分享高質量文章

在 JVM 中使用透明巨型頁

(給ImportNew加星標,提高Java技能)

 

編譯:唐尤華

鏈接:shipilev.net/jvm-anatomy-park/2-transparent-huge-pages/

 

“[JVM 解剖公園][1]”是一個持續更新的系列迷你博客,閱讀每篇文章一般需要5到10分鐘。限於篇幅,僅對某個主題按照問題、測試、基準程式、觀察結果深入講解。因此,這裡的資料和討論可以當軼事看,不做寫作風格、句法和語意錯誤、重覆或一致性檢查。如果選擇採信文中內容,風險自負。

 

Aleksey Shipilёv,JVM 性能極客   

 

推特 [@shipilev][2] 

  

問題、評論、建議發送到 [[email protected]][3]

 

[1]:https://shipilev.net/jvm-anatomy-park

[2]:http://twitter.com/shipilev

[3]:[email protected]

 

2. 問題

 

什麼是大記憶體頁?什麼是THP(透明巨大頁面)?瞭解它能為我們帶來什麼幫助?

 

3. 理論

 

“虛擬記憶體”概念已經被大家廣泛接受。現在只有少數人還記得”real mode”編程,更不用提實際操作了。在這種樣式下編程,會用到實際物理記憶體。與”real mode”相反,每個行程都擁有自己的虛擬記憶體空間,虛擬記憶體空間會映射到實際記憶體。例如,兩個行程可以在相同的虛擬地址 `0x42424242` 中儲存不同資料,這些資料實際存放在不同的物理記憶體中。當程式訪問該地址時,通過某種機制會把虛擬地址轉換成實際物理地址。

 

這個過程一般通過由操作系統維護的”[頁表][4]”實現,硬體通過”遍歷頁表”進行地址轉換。雖然以頁面為單位進行地址轉換更容易,但由於每次訪問記憶體都會發生地址轉換會帶來不小開銷。為此,引入 [TLB(轉換查找緩衝)][5]快取最近的轉換記錄。TLB 要求至少要與 L1 快取一樣快,因此通常快取少於100條。對工作負載較大的情況,TLB 缺失和由此引發的頁表遍歷需要很多時間。

 

[4]:https://en.wikipedia.org/wiki/Page_table

[5]:https://en.wikipedia.org/wiki/Translation_lookaside_buffer

 

雖然不能創建更大的 TLB,但我們還可以做一些別的事情:創建更大的記憶體頁!大多數硬體都提供4K大小的基本頁,2M/4M/1G”大頁面”。 使用更大的頁面改寫同一區域也可以縮小頁表,從而減少頁面遍歷的時間。

 

在 Linux 世界,至少有兩種截然不同的方法可以在應用程式中做到這一點:

 

– [hugetlbfs][6]。裁剪一塊系統記憶體作為虛擬檔案系統,應用程式通過 mmap(2) 對其進行訪問。這是一種特殊接口,需要同時配置操作系統和應用程式後才能使用。這也是一種”全有或全無”的處理:為 hugetlbfs 分配的(持久化)空間不能為其它常規行程使用。

 

– [THP(透明巨型頁)][7]。應用程式可以像平常那樣分配記憶體,但 THP 會嘗試嚮應用程式透明地提供後臺大頁面儲存支持。理想情況下,啟用 THP 無需修改應用程式,但是我們能夠看到應用程式從中受益。實際上,啟用 THP 會帶來記憶體開銷或者時間開銷。前者因為可能會為一些較小的內容分配整個大頁面,後者因為 THP 分配頁面有時需要進行記憶體碎片整理(defrag)。好訊息是這裡有一種折衷方法:應用程式呼叫 madvise(2) 建議 Linux 在何處啟用 THP。

 

[6]:https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt

[7]:https://www.kernel.org/doc/Documentation/vm/transhuge.txt

 

我不明白為什麼術語”large”和”huge”可以互換。 不管怎樣,OpenJDK 支持兩種樣式:

 

```java
$ java -XX:+PrintFlagsFinal 2>&1 | grep Huge
  bool UseHugeTLBFS             = false      {product} {default}
  bool UseTransparentHugePages  = false      {product} {default}
$ java -XX:+PrintFlagsFinal 2>&1 | grep LargePage
  bool UseLargePages            = false   {pd product} {default}
```

 

`-XX:+UseHugeTLBFS` 把 Java 堆 mmaps 到獨立的 hugetlbfs 中。

 

`-XX:+UseTransparentHugePages` 用 madvise -s 建議 Java 堆應該使用 THP。這是一個便捷選項,因為我們知道 Java 堆很大且大部分是連續的,並且極有可能因大頁面受益。

 

`-XX:+UseLargePages` 是一種啟用所有功能的快捷方式。在 Linux 上,該選項會啟用 hugetlbfs 而不是 THP。我想這是歷史的原因,因為 hugetlbfs 出現得更早。

 

一些應用程式在啟用大頁面時確實會[受到影響][8](有時會看到人們為了避免 GC 手動記憶體管理,結果卻觸發 THP 碎片整理進而導致延遲達到峰值)。我的直覺是 THP 在生命周期較短的應用程式上效果不佳,這些應用程式碎片整理耗費的時間與應用生命周期相比非常可觀。

 

[8]:https://bugs.openjdk.java.net/browse/JDK-8024838

 

 4. 實驗

 

能否舉例展示大頁面給我們帶來的好處?當然可以。任何一位系統性能工程師在三十多歲時至少運行過一次類似這樣的工作負載,分配並隨機訪問 `byte[]` 陣列:

 

```java
public class ByteArrayTouch {

    @Param(...)
    int size;

    byte[] mem;

    @Setup
    public void setup() {
        mem = new byte[size];
    }

    @Benchmark
    public byte test() {
        return mem[ThreadLocalRandom.current().nextInt(size)];
    }
}
```

 

(完整原始碼參見[這裡][9])

 

[9]:https://shipilev.net/jvm/anatomy-quarks/2-transparent-huge-pages/ByteArrayTouch.java

 

我們知道陣列大小各有不同,程式性能可能最終由 L1 快取失敗、L2 快取失敗或 L3 快取失敗決定。這裡通常忽略 TLB 失敗成本。

 

運行測試前,我們需要確定堆大小。我的電腦 L3 大約8M,所以100M陣列足以超過。這意味著用 `-Xmx1G -Xms1G` 分配1G大小的堆就可以滿足測試條件。同時,也可以參照這種方式確定 hugetlbfs 所需資源。

 

接下來,確保設置下列選項:

 

```
# HugeTLBFS 應該分配 1000*2M 頁面:
sudo sysctl -w vm.nr_hugepages=1000

# THP 僅進行 "madvise" 建議(一些發行版本提供設置預設值選項):
echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/defrag
```

 

我比較喜歡為 THP 做 “madvise”,因為它允許我選擇已經知道可能受益的特定記憶體。

 

在 i7 4790K、Linux x86_64、JDK 8u101 環境下運行:

 

```java
Benchmark               (size)  Mode  Cnt   Score   Error  Units

# Baseline
ByteArrayTouch.test       1000  avgt   15   8.109 ± 0.018  ns/op
ByteArrayTouch.test      10000  avgt   15   8.086 ± 0.045  ns/op
ByteArrayTouch.test    1000000  avgt   15   9.831 ± 0.139  ns/op
ByteArrayTouch.test   10000000  avgt   15  19.734 ± 0.379  ns/op
ByteArrayTouch.test  100000000  avgt   15  32.538 ± 0.662  ns/op

# -XX:+UseTransparentHugePages
ByteArrayTouch.test       1000  avgt   15   8.104 ± 0.012  ns/op
ByteArrayTouch.test      10000  avgt   15   8.060 ± 0.005  ns/op
ByteArrayTouch.test    1000000  avgt   15   9.193 ± 0.086  ns/op // !
ByteArrayTouch.test   10000000  avgt   15  17.282 ± 0.405  ns/op // !!
ByteArrayTouch.test  100000000  avgt   15  28.698 ± 0.120  ns/op // !!!

# -XX:+UseHugeTLBFS
ByteArrayTouch.test       1000  avgt   15   8.104 ± 0.015  ns/op
ByteArrayTouch.test      10000  avgt   15   8.062 ± 0.011  ns/op
ByteArrayTouch.test    1000000  avgt   15   9.303 ± 0.133  ns/op // !
ByteArrayTouch.test   10000000  avgt   15  17.357 ± 0.217  ns/op // !!
ByteArrayTouch.test  100000000  avgt   15  28.697 ± 0.291  ns/op // !!!
```

 

下麵是一些觀察結果:

 

  1. 對於較小的陣列,快取和 TLB 表現都很好,與基準測試沒有顯著差別。
  2. 在大陣列情況下,快取失敗開始占主導地位,這就是為什麼每種配置開銷都在增加。
  3. 對於較大的陣列,會出現 TLB 錯誤,啟用更大的頁面非常有幫助!
  4. `UseTHP` 和 `UseHTLBFS` 都能起到幫助,因為它們嚮應用程式提供了相同的服務。

 

為了驗證出現 TLB 失敗這一假設,可以查看硬體計數器。執行 JMH `-prof perfnorm` 會按操作輸出統一結果。

 

```java
Benchmark                                (size)  Mode  Cnt    Score    Error  Units

# Baseline
ByteArrayTouch.test                   100000000  avgt   15   33.575 ±  2.161  ns/op
ByteArrayTouch.test:cycles            100000000  avgt    3  123.207 ± 73.725   #/op
ByteArrayTouch.test:dTLB-load-misses  100000000  avgt    3    1.017 ±  0.244   #/op  // !!!
ByteArrayTouch.test:dTLB-loads        100000000  avgt    3   17.388 ±  1.195   #/op

# -XX:+UseTransparentHugePages
ByteArrayTouch.test                   100000000  avgt   15   28.730 ±  0.124  ns/op
ByteArrayTouch.test:cycles            100000000  avgt    3  105.249 ±  6.232   #/op
ByteArrayTouch.test:dTLB-load-misses  100000000  avgt    3   ≈ 10⁻³            #/op
ByteArrayTouch.test:dTLB-loads        100000000  avgt    3   17.488 ±  1.278   #/op
```

 

好了!在基準測試中,每個操作都會發生一次 dTLB 加載失敗,啟用 THP 後會少得多。

 

當然,啟用 THP 碎片整理後,在分配或訪問時會有碎片整理開銷。為了將這些成本轉移到 JVM 啟動階段,避免應用程式運行中出現意料之外的延遲問題,可以讓 JVM 在初始化時使用 `-XX:+AlwaysPreTouch` 訪問 Java 堆中的每個頁面。無論如何,為較大的堆啟用 `pre-touch` 是一個好辦法。

 

有趣的是: 實際使用中,啟用 `-XX:+UseTransparentHugePages` 讓 `-XX:+AlwaysPreTouch` 變得更快。因為 JVM 知道,現在它必須以更大的量程(比如每2M一個位元組),而不是更小的量程(每4K一個位元組)訪問堆。啟用 THP 行程死亡記憶體釋放速度也會加快,這種粗暴的效果要等到併發記憶體釋放補丁加入發行版內核才會結束。

 

例如,使用 4TB (Terabyte)大小的堆:

 

```java
$ time java -Xms4T -Xmx4T -XX:-UseTransparentHugePages -XX:+AlwaysPreTouch
real    13m58.167s
user    43m37.519s
sys     1011m25.740s

$ time java -Xms4T -Xmx4T -XX:+UseTransparentHugePages -XX:+AlwaysPreTouch
real    2m14.758s
user    1m56.488s
sys     73m59.046s
```

 

提交和釋放4TB肯定需要一段相當長的時間了。

 

5. 觀察

 

使用大頁面是一種提高應用程式性能的簡單技巧。內核中 THP 讓應用訪問記憶體變得更加容易。JVM 中對 THP 的支持讓選擇大頁面更方便。當應用程式擁有大量資料和大堆棧時,嘗試使用大頁面總是一個好主意。

    赞(0)

    分享創造快樂