12c的數據庫在安裝的時候，有一個檢查項目，叫做Maximum locked memory check。

這是要求設置/etc/security/limits.conf中的memlock的值，官方文檔在11g要求是設置比物理內存稍小的一個值，在12c中要求至少為90%的物理內存。

而memlock的設置，是啟用huge page的一部分。開啟hugepage在大內存大sga的環境下，可以提供系統的性能。

啟用hugepage需要設置/etc/security/limits.conf和vm.nr_hugepages(Doc ID 361468.1)

注1：

在asm中，當啟用hugepage時oracle建議asm的SGA增大到至少2G，設置hugepage至少1300個以上的大頁面(Doc ID 2111010.1)

在Exadata中，默認啟用了hugepage，且安裝Exadata的時候，就默認禁用了asm的AMM(PGA不使用hugepage，這也是為什么使用hugepage不能同時使用AMM，只能使用ASMM的原因。因為AMM是自動管理SGA+PGA。而hugepage不能被PGA使用。)，設置了SGA大小為2G。(Doc ID 1681467.1)。

上述的大小只是一個大概的估算值，如果需要計算大小，也是可以計算的。asm的shared pool的大小，在150M的基礎上，external冗余的disks，每增加100G的空間大小，需要額外的1M內存(Doc ID 437924.1)

注2：

在12c中grid中多了一個MGMTDB來記錄GI資源信息，這個DB的SGA使用，也要考慮看hugepage的配置中。不過由于mgmtdb不確定會跑在那個節點上，在Exadata的health check檢查項目中，是建議把mgmtdb使用hugepage屬性關閉的。(Doc ID 1274318.1)

注3：

還有一個參數pre_page_sga，在9i～11g中默認值是false，在12c中默認值是true。在12c之前，默認值false可以避免在進程啟動時，access sga中所有的page頁面加快進程的啟動速度(見connection management call elapsed time)。而在12.1之后，算法發生了改變，設置為true和false幾乎沒有差別。

注4：

上面說的hugepages，指的是regular hugepages，而對于transparent hugepages，我們是需要禁用的。見Disable Transparent HugePages on SLES11, RHEL6, RHEL7, OL6, OL7, and UEK2 and above (Doc ID 1557478.1)。

regular hugepages是提前分配，不是動態分配，transparent hugepages是通過khugepaged線程動態配置的，這可能會導致Oracle運行過程中出現一些奇怪的問題，Oracle建議關閉Transparent HugePages功能。

注5：

放在small pages上的sga，不會直接占用物理內存(這樣應該是在page fault時才會申請物理內存)。即ipcs -am看到占用的內存的是在vm中，不是在RSS中，實際物理內存中。

所以，

(1)oracle推薦在大內存大sga的情況下，使用hugepage。文檔上說是大于8G物理內存(Doc ID 361468.1)；在實際使用中，客戶如果超過64G內存，我們一般都推薦使用。

(2)對于asm我們可以設置sga至少2G，同時注意要求至少1300個以上的大頁面。

(3)對于mgmtdb，我們可以設置use_large_pages=false禁用mgmtdb使用hugepage。

(4)如果多個數據庫共享一個主機，但是如果我們提前把hugepage的配置能覆蓋到所有instance，那么就不存在什么問題。在11g中，有use_large_page參數，默認值為true。即默認嘗試配合OS使用hugepage。但是在11.2.0.2的時候，如果hugepage不夠cover sga，會導致數據庫啟動不了。在11.2.0.3以后，oracle會在hugepage不夠的情況下，將使用small page來彌補剩余的page，從而啟動數據庫(Doc ID 1392497.1)

(5)禁用transparent hugepages(Doc ID 1557478.1)

總結

以上是生活随笔為你收集整理的hugepage oracle 12c,Huge page使用的一些问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。