Oracle Memory Management and HugePage (連載三)

沃趣科技發表於2016-04-18

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



Transparent Hugepage

RedHat6, RedHat7, OL6, OL7 SLES11 UEK2 kernels開始transparent hugepage被預設開啟,它允許大頁做動態的分配,而不是系統啟動後就分配好,根據Oracle MOS DOC1557478.1transparent 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的使用,ReservedFree都會不斷的降低。

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%的記憶體空間,這些記憶體空間用於kernalpage table以及一些其他的程式需要,例如rman備份,檔案系統快取。這個也是Oracle官方的建議。

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

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

SGAPGA分配好後,要考慮到是否需要為buffer cacheshared 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認證部落格專家,ACOUGSHOUG核心成員。曾在Oracle技術嘉年華、ORCL-CONYY分享平臺等公開場合 多次做過資料庫技術專題分享。對Oracle 並行機制、資料庫異常恢復方法、ASM等有深入的研究,人稱”Oracle Internal達人,對企業資料庫架構設計、故障恢復、高併發下資料庫效能調優有豐富的經驗,擅長從等待時間角度分析解決資料庫效能問題,是OWI方法論的提倡者和踐行者。

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

DB GEEK QQ :516293316

公司主頁:

其它白皮書

SQL MONITOR:

Parallel原理實現:

12C IN-MEMORY

(全文完結



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

相關文章