Oracle Memory Management and HugePage （連載三）

作者：沃趣科技高階資料庫工程師  魏興華 

---

Transparent Hugepage

從RedHat6, RedHat7, OL6, OL7 SLES11 和 UEK2 kernels開始transparent hugepage被預設開啟，它允許大頁做動態的分配，而不是系統啟動後就分配好，根據Oracle MOS DOC：1557478.1，transparent hugepage導致了很多的問題，建議將其關閉 檢視是否啟用了transparent hugepage cat /sys/kernel/mm/transparent_hugepage/enabled [always] never []內的值是當前啟用的值，上面的輸出說明啟用了transparent hugepage。 可以通過 /etc/grub.conf 檔案來關閉transparent hugepage。

通過增加關鍵字transparent_hugepage=never來講transparent hugepage關閉。 也可以通過開機啟動後，echo相應的值到對應的檔案來動態關閉transparent hugepage。

OS層面檢視大頁使用情況

HugePages_Total為所分配的頁面數目，和Hugepagesize相乘後得到所分配的記憶體大小。43000*2/1024大約為84GB。

HugePages_Free為從來沒有被使用過的Hugepages數目。即使Oracle sga已經分配了這部分記憶體，但是如果沒有實際寫入，那麼看到的還是Free的。這是很容易誤解的地方。

HugePages_Rsvd為已經被分配預留但是還沒有使用的page數目。在Oracle剛剛啟動時，大部分記憶體應該都是Reserved並且Free的，隨著Oracle SGA的使用，Reserved和Free都會不斷的降低。

HugePages_Free – HugePages_Rsvd 這部分是沒有被使用到的記憶體，如果沒有其他的Oracle instance，這部分記憶體也許永遠都不會被使用到，也就是被浪費了。在該系統上有11.5GB的記憶體被浪費了。

最佳實踐

對於Oracle來說，這是一個最佳實踐氾濫的時代，所有的最佳實踐其實都有特定的應用場景，而不是放之四海皆準，但是當今資訊爆炸時代（資料庫種類爆炸時代），很多DBA沒有那麼多的耐心去專注學習一門資料庫，只是拿來主義從網上找出一些最佳實踐來，不管三七二十一就用到自己的環境中（甚至是生產環境中），一定程度上來說，崇拜最佳實踐是懶惰的結果。

針對於Oracle的記憶體分配方式，肉絲給大家推薦在核心繫統上： 1.使用手工的SGA管理，這種管理方式已經非常的成熟，但是這種方式對DBA要求較高，一定程度上需要了解業務特點。 2.如果第一種方法你感覺到比較難，那麼使用ASMM，但是為buffer cache,shared pool設定最小值的方式，這種方式是我非常推薦的方式。

至於AMM這種記憶體分配方式，由於不能使用大頁，建議不要去用。

具體到記憶體如何分配，針對是OLTP場景，還是OLAP場景，有著不同的記憶體分配原則，即使是OLTP場景，針對程式數的多少，併發數的多少，SQL語句的特點，都會導致產生不同的記憶體分配方法。作為DBA要掌握基本的Oracle記憶體使用原理，然後根據實際情況去根據業務自身特點分配記憶體。

不管是OLTP系統或者OLAP系統，一般都建議至少為作業系統預留出20%的記憶體空間，這些記憶體空間用於kernal、page table以及一些其他的程式需要，例如rman備份，檔案系統快取。這個也是Oracle官方的建議。

把這一部分的記憶體刨去後，針對OLTP系統，可以考慮先嚐試預留出20%的記憶體給PGA使用，80%的記憶體給SGA使用。如果系統上程式數比較多，特別是同時活躍的程式數比較多，需要給PGA預留出更多的記憶體，可以按照每個程式12M的PGA佔用進行計算。

針對OLAP系統，刨去作業系統的預留記憶體後，可以考慮預留出50%的記憶體給PGA使用，50%的記憶體給SGA使用。畢竟在純OLAP下，buffer cache其實不需要那麼大的記憶體空間。

SGA、PGA分配好後，要考慮到是否需要為buffer cache、shared pool來手工設定一個值，就像上文已經提到過的，可以參考buffer cache 的命中率，Library Hit的命中率作為一個輔助參考.如果命中率較低，有可能是記憶體分配的不夠合理。當然你還需要藉助於像AWR報告這樣的工具，根據SQL的執行計劃等內容來進一步的做診斷，比如命中率低的原因可能不是分配的buffer cache小，而是存在大量的低效的全表掃描，進而導致命中率低，這樣的話，需要優化的就是SQL，而不是繼續加大buffer cache。再比如，如果你發現Library cache Hit比較低，可能並不是shared pool比較小，還可能是系統的SQL存在大量未使用繫結變數的情況，導致硬解析過重。

優化經常是個系統工程，不能一蹴而就，特別像Oracle是一個很龐大的複雜系統，對於問題的出現，更是要仔細推敲，不能輕易的下結論。隨著做DBA時間越來越長，你也會越來越懂TOM的一句話：It depends。

關於作者

魏興華，沃趣科技高階技術專家，主要參與公司一體機產品、監控產品、容災產品、DBaaS平臺的研發和設計。曾就職於東軟集團，阿里巴巴集團，Oracle ACE組成員，DBGEEK 使用者組發起人，ITPUB認證部落格專家，ACOUG、SHOUG核心成員。曾在Oracle技術嘉年華、ORCL-CON、YY分享平臺等公開場合 多次做過資料庫技術專題分享。對Oracle 並行機制、資料庫異常恢復方法、ASM等有深入的研究，人稱”Oracle Internal達人”，對企業資料庫架構設計、故障恢復、高併發下資料庫效能調優有豐富的經驗，擅長從等待時間角度分析解決資料庫效能問題，是OWI方法論的提倡者和踐行者。

個人郵箱: xinghua.wei@woqutech.com

DB GEEK QQ 群:516293316

公司主頁:www.woqutech.com

其它白皮書

SQL MONITOR: http://pan.baidu.com/s/1gfO2DtL

Parallel原理實現： http://pan.baidu.com/s/1i5xun9F

12C IN-MEMORY： http://pan.baidu.com/s/1ge7r1oZ

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28218939/viewspace-2083183/，如需轉載，請註明出處，否則將追究法律責任。