Oracle內(nèi)存過度消耗風(fēng)險提醒

前言

時間過的真快，技術(shù)人生系列·我和數(shù)據(jù)中心的故事已經(jīng)來到了第六期，小y又和大家見面了！

小y今天要和大家分享的是一個綜合型問題的的分析和解決過程。

解決該類問題，只懂?dāng)?shù)據(jù)庫是不夠的，還需要掌握比較扎實的操作系統(tǒng)技能。

同時引出了另外一種不太常見形式的優(yōu)化，內(nèi)存優(yōu)化。

由于今天要分享的問題具有普遍性，建議大家可以按照文中方法檢查自己的系統(tǒng)中有無類似問題。分享的最后將對該共性的風(fēng)險進行總結(jié)和提示。

如果覺得分享的案例還不錯，麻煩親們抬手轉(zhuǎn)發(fā)一下,希望可以提醒和幫助到更多的客戶。

更多Oracle數(shù)據(jù)庫實戰(zhàn)經(jīng)驗分享和風(fēng)險提醒的首發(fā)，盡在“中亦安圖”公眾號！歡迎關(guān)注。

另外，近期有不少朋友問，小y所在團隊是否可以做一些線下的分享？

確實，如果可以把大家組織起來，哪怕是一個會議室或者一個咖啡廳，除了面對面的技術(shù)分享，還可以聊聊人生，興致來了還可以一起燒烤啤酒，結(jié)識更多的朋友，也是人生幸事！

既然大家有興趣，那我們就開始第一期線下分享吧！

有興趣參加北京、上海、廣州、深圳等地線下分享的朋友，可以給小y發(fā)郵件，郵箱是51994106@qq.com,或者加小y的微信(shadow-huang-bj),提供城市、姓名、電話、單位、職位等信息即可，當(dāng)報名人數(shù)超過20人，我們就開始啟動北京、上海、廣州、深圳、杭州、南京等地的免費線下分享活動。另外，有興趣的可以加入QQ群227189100，我們以后會定期做一些線上的分享。

Part 1

問題來了

2015年12月28日，北京。

晚上8點，剛吃完晚飯，電話響起，是一位運營商客戶的電話。

“小y,出事了，今天下午17點到18點，xx數(shù)據(jù)庫監(jiān)聽和實例crash，不過現(xiàn)在庫已經(jīng)起來了。這個業(yè)務(wù)系統(tǒng)很重要，領(lǐng)導(dǎo)非常重視，務(wù)必要求查明原因。其他廠商都已經(jīng)到了，暫時沒有查到問題。你們能不能馬上派個工程師到現(xiàn)場分析一下？爭取今晚就有個結(jié)論！”

接到電話后，小y立刻安排兄弟趕往現(xiàn)場。之后還了解到，上周也出現(xiàn)過類似的問題。

環(huán)境介紹：

操作系統(tǒng) AIX 6.1 TL8, 64-bit

數(shù)據(jù)庫 ORACLE 11.2.0.3,2節(jié)點RAC

配置：16CPU 50G內(nèi)存

Part 2

分析過程

過一會兒，收到日志，一下子來了精神，我們先來看看日志，確認(rèn)下客戶提到的數(shù)據(jù)庫crash和監(jiān)聽crash的問題。

確認(rèn)監(jiān)聽和數(shù)據(jù)庫實例宕的問題

2.1.1

數(shù)據(jù)庫alert.log

可以看到：

>>17:42:39，數(shù)據(jù)庫alert日志有關(guān)鍵報錯信息，負(fù)責(zé)GCS的進程LMS的調(diào)用有89秒沒有得到響應(yīng)。意味著從17:41:10秒開始，數(shù)據(jù)庫就開始出現(xiàn)問題了。

>>接下來，就來到了18:02:48，直接轉(zhuǎn)到啟動數(shù)據(jù)庫的日志，沒有數(shù)據(jù)庫停止、被異常終止的日志，這20分鐘內(nèi)alert日志沒有任何輸出。期間操作系統(tǒng)并沒有發(fā)生重啟現(xiàn)象。

原因初步分析：

導(dǎo)致LMS的調(diào)用沒有響應(yīng)的最常見的原因是數(shù)據(jù)庫所在的Lpar的系統(tǒng)資源如內(nèi)存/CPU出現(xiàn)瓶頸。而通常在操作系統(tǒng)資源緊張的情況下，會伴隨著以下表現(xiàn)：

>> CRS作為集群資源管理的進程，在檢測資源時可能也會出現(xiàn)超時的情況，從而啟動異常處理，例如將資源自動重啟

>> RAC節(jié)點之間的某些心跳檢測得不到響應(yīng)的情況下，為了恢復(fù)整個RAC集群的對外服務(wù)能力，11g后將優(yōu)先啟動MemberKill,即終止數(shù)據(jù)庫實例的方式嘗試恢復(fù)，如果memberKill無法解決問題，則升級為NodeKill,即重啟OS的方式來恢復(fù)整個集群的對外服務(wù)能力

接下來檢查CRSD進程的日志

從中可以看到，包括VIP/監(jiān)聽等在內(nèi)的資源，由于OS資源緊張的問題，檢測超時，繼而啟動了異常處理。

2.1.2

節(jié)點1 CRSD.LOG

從下圖可以看到：

17:42:30,CRSD檢測VIP的健康情況，10秒后，檢測超時，于是狀態(tài)變UNKNOWN（然后被CRSD嘗試重啟）

從下圖可以看到：

17:51:18秒，由于VIP宕，而監(jiān)聽依賴于VIP，因此監(jiān)聽被請求停止。

從下圖可以看到：

17:54:34,檢測到數(shù)據(jù)庫資源ora.XXDB.db被異常終止

2.1.3

ocssd.log

從上圖可以看到：

其實在2015-12-28 17:47:17，OCSSD進程就收到了節(jié)點2的Member kill request的請求，需要殺掉數(shù)據(jù)庫實例。實際上，到了18:02:48，數(shù)據(jù)庫才開始啟動。

這期間經(jīng)過了長達(dá)15分鐘，說明數(shù)據(jù)庫服務(wù)器資源已經(jīng)很緊張，能導(dǎo)致性能如此緩慢的，通常只有內(nèi)存出現(xiàn)大量換頁。

2.2 操作系統(tǒng)性能-隱患早已埋下

從上述分析可以知道，事實上從17:41:10到17:42:39，數(shù)據(jù)庫節(jié)點1系統(tǒng)資源就開始出現(xiàn)了緊張，開始變得緩慢了！

2.2.1

查看CPU使用情況

可以看到：

CPU資源不是問題，CPU峰值并不高

2.2.2

查看內(nèi)存換頁情況（pi/po）

可以看到:

NMON每5分鐘采樣一次，

17點39分的下一次采樣是17點44分，但是這次采樣根本沒有被采集出來！

這說明系統(tǒng)資源已經(jīng)非常緊張！這是最重要的一個證據(jù)！

問題出在17點42分，由于采集間隔的緣故，沒有被采集到，也比較正常。

但不影響本次分析的總體判斷。

另外，不難發(fā)現(xiàn)，在出問題以前，pageSpace的利用率達(dá)到12.44！說明以前就出現(xiàn)了內(nèi)存不足！小y建議大家，如果發(fā)現(xiàn)自家AIX平臺上出現(xiàn)pageSpace被使用的情況時，務(wù)必好好分析下內(nèi)存的使用情況，否則將是一個大雷。

2.2.2

為什么會出現(xiàn)內(nèi)存換頁？

小y看到該數(shù)據(jù)的時候，嚇了一跳！

出問題前，如16:24到17:29之間，數(shù)據(jù)庫服務(wù)器的計算內(nèi)存（%comp）就已經(jīng)長時間處于90%的高位了！這對于AIX來說，是非常危險的！對于計算內(nèi)存，我們要盡量控制在80%以下，這樣的系統(tǒng)才是出于健康狀態(tài)的系統(tǒng)！

90%的計算內(nèi)存已經(jīng)接近內(nèi)存換頁的臨界點！

當(dāng)出現(xiàn)一些稍微大的內(nèi)存的使用需求，則會使得系統(tǒng)出現(xiàn)內(nèi)存換頁。

那么到底是誰觸發(fā)了換頁呢？

在小y看來，如果一面墻快倒了，那么誰碰倒了這面墻不重要了！所以這不是問題的關(guān)鍵。

同樣的17點44分本該顯示有一條記錄，卻沒打出來！

說明17點44分左右系統(tǒng)確實處于內(nèi)存緊張狀態(tài)。

17點49分時，計算內(nèi)存更是達(dá)到了97%！（44分已經(jīng)異常，必定導(dǎo)致進程堆積，繼而加大內(nèi)存的使用）

2.3 內(nèi)存規(guī)劃-客戶的如意算盤

數(shù)據(jù)庫服務(wù)器內(nèi)存大小為50G，客戶最開始的內(nèi)存規(guī)劃如下

>> SGA配置25G

>> PGA配置為5G

>> 數(shù)據(jù)庫參數(shù)processes為2000，日常運行在1000個進程

數(shù)據(jù)庫對內(nèi)存的占用可以使用下面的簡單公式來計算：

SGA + PGA+進程在OS級的消耗

正常情況下，11G版本數(shù)據(jù)庫，單個ORACLE服務(wù)進程的內(nèi)存占用在3M，

因此平時內(nèi)存的使用為25G+5G+1000*3M=33G，占Lpar內(nèi)存的66%。

如果按照出現(xiàn)異常等待，2000個進程被調(diào)起來的情況，則內(nèi)存的使用為25G+5G+2000*3M=36G，規(guī)劃偏大。

2.4 分析內(nèi)存使用到底去哪了-現(xiàn)實很殘酷

由于數(shù)據(jù)庫對內(nèi)存的占用可以使用下面的簡單公式來計算：

SGA + PGA+進程在OS級的消耗

這里，SGA是個硬限制,PGA不是硬限制（無論工作區(qū)或非工作區(qū)都不是硬限制）

小y通過dba_hist_pgastat獲得pga的峰值，發(fā)現(xiàn)也就是5個G，沒有突破PGA的參數(shù)限制，那么最有可能的就是“進程在OS級的消耗”占的內(nèi)存比較多了。

因此，小y馬上通過 procmap命令檢查單個進程的內(nèi)存消耗:

發(fā)現(xiàn)ORACLE單個內(nèi)存占用到了10M（將第二列加起來）

到了這里，小y已經(jīng)知道答案了！

讀者朋友們，也可以停一下，把上述現(xiàn)象總結(jié)一下，再思考個幾分鐘，如果是你來接這個CASE，你會怎么繼續(xù)往下查呢？

↓

↓

↓

↓

↓

↓

↓

↓

↓

↓

↓

↓

不要走開后邊還有.....

那么內(nèi)存用到了哪里呢？小y的做法很簡單，通過svmon –P命令可以看到內(nèi)存占用的細(xì)節(jié)。

可以看到：

每個ORACLE服務(wù)進程work類型的獨占內(nèi)存中， USLA heap部分占了1642個內(nèi)存頁，而每頁4K，即多占6-7M。

事實上這是一個操作系統(tǒng)和數(shù)據(jù)庫的已知BUG。

中亦科技在其他數(shù)據(jù)中心已經(jīng)遇到過好幾次該問題。

2.5 不可小看的7M內(nèi)存

數(shù)據(jù)庫服務(wù)器內(nèi)存大小為50G，客戶最開始的內(nèi)存規(guī)劃如下

>> SGA配置25G

>> PGA配置為5G

>> 數(shù)據(jù)庫參數(shù)processes為2000，日常運行在1000個進程

我們現(xiàn)在再來看一下：

正常情況下：

11G版本數(shù)據(jù)庫，單個ORACLE服務(wù)進程的內(nèi)存占用是10M而非3M！

因此平時內(nèi)存的使用為25G+5G+1000*10M=40G，光數(shù)據(jù)庫就占了內(nèi)存的80%！這是比較危險的！對于AIX平臺，數(shù)據(jù)庫占內(nèi)存建議在50%-60%之間，因為操作系統(tǒng)kernel等還會使用內(nèi)存，最多可使用到40%，比較常見的是kernel inode cache的使用。

如果按照出現(xiàn)異常等待，2000個進程被調(diào)起來的情況，則內(nèi)存的使用為25G+5G+2000*10M=50G

2.6 確認(rèn)操作系統(tǒng)和數(shù)據(jù)庫BUG

到這里后，就簡單了。

小y在mos上以USLA做關(guān)鍵字搜索，以下就找到了對應(yīng)的BUG.

下面的這篇note,是ORACLE官網(wǎng)上對于USLA heap導(dǎo)致單個進程多占7M內(nèi)存，

從3M變成10M的BUG 13443029的描述。

11gR2Aix - Dedicated Server Processes Have Large Usla Heap Segment Compared To Older Versions (Doc ID 1260095.1)

2.7 如何解決呢？

這個問題是操作系統(tǒng)的一個缺陷，需要操作系統(tǒng)和數(shù)據(jù)庫同時安裝補丁才可以解決:

>> 對于AIX 6.1 TL07 or AIX 7.1 TL01需要操作系統(tǒng)和數(shù)據(jù)庫同時安裝補丁才可以解決。

>> 對于AIX 6.1 TL07 SP02/AIX 7.1 TL01 SP02 or later,由于操作系統(tǒng)已經(jīng)修復(fù)，只需在數(shù)據(jù)庫端安裝補丁13443029。

數(shù)據(jù)庫補丁13443029在11.2.0.3下不包含在任何PSU中，11.2.0.4中才包含了該問題的修復(fù)。

Part 3

原因總結(jié)和建議

3.1 原因總結(jié)

數(shù)據(jù)庫服務(wù)器內(nèi)存大小為50G，內(nèi)存規(guī)劃如下

  SGA配置25G

  PGA配置為5G

  數(shù)據(jù)庫參數(shù)processes為2000

28日平均數(shù)據(jù)庫服務(wù)進程數(shù)為1000個左右

由于操作系統(tǒng)和數(shù)據(jù)庫的一個已知缺陷-- 11gR2Aix - Dedicated Server Processes Have Large Usla Heap Segment Compared To Older Versions (Doc ID 1260095.1)，導(dǎo)致一個空閑的數(shù)據(jù)庫服務(wù)進程在USLA部分多占了7M左右的私有內(nèi)存。

因此數(shù)據(jù)庫整體占到了 25 G + 5G + 1000*10M=40G，即40G左右的計算內(nèi)存，數(shù)據(jù)庫已經(jīng)占到80%以上的內(nèi)存（通常要控制在60%），加上kernel等內(nèi)存的使用，數(shù)據(jù)庫平時運行在接近90%的計算內(nèi)存的狀態(tài)。這使得數(shù)據(jù)庫服務(wù)器運行在內(nèi)存高位下，當(dāng)出現(xiàn)進程數(shù)增多、排序哈希等內(nèi)存需求的時候，繼而出現(xiàn)內(nèi)存換頁情況，將整體系統(tǒng)拖的異常緩慢。

內(nèi)存緊張時本次故障的原因，最直接的證據(jù)如下：

NMON每5分鐘采樣一次，

17點39分的下一次采樣是17點44分，但是這次采樣沒有被采集出來！

這說明系統(tǒng)資源已經(jīng)非常緊張！這是最重要的一個證據(jù)！

數(shù)據(jù)庫集群自身檢測到VIP/數(shù)據(jù)庫資源無響應(yīng)的情況下，進行了異常處理，繼而導(dǎo)致監(jiān)聽、VIP、數(shù)據(jù)庫實例宕的故障。

3.2 建議

通過解決“操作系統(tǒng)和數(shù)據(jù)庫關(guān)于USLA的缺陷“以及對數(shù)據(jù)庫內(nèi)存參數(shù)進行規(guī)劃，可減少內(nèi)存的使用，使得系統(tǒng)運行在更健康的內(nèi)存狀況下，從而從根本上解決該問題。

1）  安裝數(shù)據(jù)庫補丁13443029，使數(shù)據(jù)庫重新以shrsymtab這個選項來編譯，將USLA部分的7M內(nèi)存減至幾十K，從而多騰出來7G左右的內(nèi)存（如果以2000個進程算，則騰出來14G內(nèi)存） 

2）  將數(shù)據(jù)庫SGA內(nèi)存sga_target參數(shù)從25G調(diào)小到20G。

調(diào)整說明：

經(jīng)過兩個調(diào)整后，在沒有為lpar添加內(nèi)存的情況下，

數(shù)據(jù)庫的內(nèi)存規(guī)劃是 20G+5G+1000*3M=28G，如果算2000個進程跑滿的情況下，數(shù)據(jù)庫的內(nèi)存規(guī)劃是 20G+5G+2000*3M=31G

從而使得系統(tǒng)內(nèi)存資源更富余，不會因為一些私有內(nèi)存的需求而出現(xiàn)換頁的情況。

Part 4

共性風(fēng)險提醒

小y通過該案例，做出一些共性的風(fēng)險提示：

不要低估一個空閑的Oracle服務(wù)進程所占用的內(nèi)存帶來的影響！

大家再做內(nèi)存規(guī)劃時，往往忽略了這一點！

如果您的數(shù)據(jù)庫版本是11GR2，并且運行在AIX6/7的版本上，那么您的系統(tǒng)中很可能存在過度消耗內(nèi)存的問題，即一個Oracle服務(wù)進程比10G版本的時候要多出7M左右的內(nèi)存，從而使得單個ORACLE進程從3M變到10M。這對于Oracle服務(wù)進程數(shù)較多的數(shù)據(jù)庫來說，是致命的。

例如，對于一個運行著2000個Oracle服務(wù)進程的數(shù)據(jù)庫而言，所占用的內(nèi)存不是2000*3=6G，而是2000*10=20G，多出14G。多出的14G將會超出你的內(nèi)存規(guī)劃，使數(shù)據(jù)庫運行在危險狀態(tài)下。是否命中該問題，可以參考文中分享的案例！

以下是ORACLE官網(wǎng)上對于USLA heap導(dǎo)致單個進程多占7M內(nèi)存，

從3M變成10M的BUG 13443029的描述。

11gR2Aix - Dedicated Server Processes Have Large Usla Heap Segment Compared To Older Versions (Doc ID 1260095.1)

這個問題是操作系統(tǒng)的一個缺陷，需要操作系統(tǒng)和數(shù)據(jù)庫同時安裝補丁才可以解決:

>> 對于AIX 6.1 TL07 or AIX 7.1 TL01需要操作系統(tǒng)和數(shù)據(jù)庫同時安裝補丁才可以解決。

>> 對于AIX 6.1 TL07 SP02/AIX 7.1 TL01 SP02 or later,由于操作系統(tǒng)已經(jīng)修復(fù)，只需在數(shù)據(jù)庫端安裝補丁13443029。

數(shù)據(jù)庫補丁13443029在11.2.0.3下不包含在任何PSU中，11.2.0.4中才包含了該問題的修復(fù)。

For AIX 6.1 TL07 SP02/AIX 7.1 TL01 SP02 or later, apply patch 13443029

For AIX 6.1 TL07 or AIX 7.1 TL01, install AIX 6.1 TL-07 APAR 

IV09580, AIX 7.1 TL-01 APAR IV09541, and apply patch 13443029

For other AIX level, apply patch 10190759, this will disable Oracle's online patching mechanism

Note: as of 06/21/2012, fix for bug 13443029 or bug 10190759 are not included in any PSU and the interim patch is needed. Interim patch 10190759 exists on top of most PSU, and patch 13443029 on top of 11.2.0.3 does not conflict with 11.2.0.3.1 PSU and can be applied on top of both 11.2.0.3 base and 11.2.0.3.1 PSU.