作業系統HugePage配置導致記憶體驟降探究

一、故障描述

某次，使用者某套資料庫最初的大頁引數設定值為 vm.nr_hugepages = 138246，執行 Oracle官方指令碼 hugepages_settings.sh之後，將對應的引數值進行了微調 vm.nr_hugepages = 204810，大頁新值生效後，驟然，系統可用實體記憶體出現急速下降。

二、根因分析

透過具體分析， vm.nr_hugepages 值設定為 138246時，系統記憶體使用情況：

vm.nr_hugepages 值設定為 204810時，系統記憶體使用情況：

透過上圖可以看出，引數調整前後，系統記憶體 free值從 200G左右降低至 80G，系統記憶體迅速減少，且對比發現系統的 buff/cache快取無明顯變化。為此引出了對應的問題，調大 hugepages大頁記憶體後，資料庫的可用記憶體為何會迅速降低。

分析 Alert日誌可以看出， vm.nr_hugepages設定為 138246，由於該資料庫的 SGA配置為 400G， hugepages大頁的記憶體頁不足，進行 sga分配時，記憶體會透過大頁記憶體（ 2048k）和普通頁（ 4k）記憶體構成，日誌資訊如下：

上述的啟動日誌可以看出，當前例項 SGA設定的記憶體為 400G，可用的記憶體分為兩個部分，分別為 4k頁記憶體和 2048k頁的記憶體。其中 4k也的記憶體頁分配了 34078751個，約為 130G， 2048k的記憶體頁分配了 138241個，約為 270G。資料庫進行 hugepage分配時，會預留至少 5個大頁記憶體，所以實際分配的大頁個數與設定的個數存在一定差異。透過作業系統層，也可以直接看出大頁的使用情況。

後續將 vm.nr_hugepages調整為 204810，即大頁的記憶體大小設定為 400G，然而由於資料庫 SGA採用的是預分配的方式，資料庫 SGA記憶體段已經安裝 130G的 4k頁和 270G的 2048k頁記憶體進行了分配，雖然調大了 2048k的記憶體頁分配，但資料庫並不能對 SGA的記憶體進行重新分配，導致增加的大頁記憶體並未被資料庫使用。透過系統可以看出，調整大頁記憶體後的使用情況，如下圖：

透過計算（ Total-Free=204810-66569=138241）的值，可以看出，雖然調大了大頁分配的值，但是實際上新增的大頁記憶體並未被使用，當前被使用的 2048k頁的個數依然為 138241個。有 66569個 hugepage的記憶體頁（ 66569*2048=130G）沒有被使用，從而造成了系統記憶體的浪費。

三、解決方案

透過上述的分析可以看出，由於資料庫的 SGA記憶體已經進行了預分配，直接調整 vm.nr_hugepages值，會造成大量的 HugePages_Free產生，而這些大頁記憶體只能被共享記憶體使用，如此會造成大量的記憶體浪費，導致系統剩餘記憶體迅速降低。

建議調整 vm.nr_hugepages值後，將資料庫進行重啟，如此才能啟動的時候 SGA全部使用大頁記憶體，將之前預分配的 4k頁記憶體進行釋放，從而保障了資料庫執行效能的同時，節省了系統記憶體的資源，實現資料庫系統的穩定執行。同時，也要注意 memory lock資源限制選項配置對大頁的影響。