第一章 技術人生系列 · 我和資料中心的故事（第六期）-Oracle記憶體過度消耗風險提醒

中亦安圖 | 2016-02-26 13:11

前言

時間過的真快，技術人生系列·我和資料中心的故事已經來到了第六期，小y又和大家見面了！

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

解決該類問題，只懂資料庫是不夠的，還需要掌握比較紮實的作業系統技能。

同時引出了另外一種不太常見形式的最佳化，記憶體最佳化。

由於今天要分享的問題具有普遍性，建議大家可以按照文中方法檢查自己的系統中有無類似問題。分享的最後將對該共性的風險進行總結和提示。

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

更多Oracle資料庫實戰經驗分享和風險提醒的首發，盡在“中亦安圖”公眾號！歡迎關注。

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

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

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

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

Part 1

問題來了

2015年12月28日，北京。

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

“小y,出事了，今天下午17點到18點，xx資料庫監聽和例項crash，不過現在庫已經起來了。這個業務系統很重要，領導非常重視，務必要求查明原因。其他廠商都已經到了，暫時沒有查到問題。你們能不能馬上派個工程師到現場分析一下？爭取今晚就有個結論！”

接到電話後，小y立刻安排兄弟趕往現場。之後還了解到，上週也出現過類似的問題。

環境介紹：

作業系統 AIX 6.1 TL8, 64-bit

資料庫 ORACLE 11.2.0.3,2節點RAC

配置：16CPU 50G記憶體

Part 2

分析過程

過一會兒，收到日誌，一下子來了精神，我們先來看看日誌，確認下客戶提到的資料庫crash和監聽crash的問題。

確認監聽和資料庫例項宕的問題

2.1.1

資料庫alert.log

可以看到：

>>17:42:39，資料庫alert日誌有關鍵報錯資訊，負責GCS的程式LMS的呼叫有89秒沒有得到響應。意味著從17:41:10秒開始，資料庫就開始出現問題了。

>>接下來，就來到了18:02:48，直接轉到啟動資料庫的日誌，沒有資料庫停止、被異常終止的日誌，這20分鐘內alert日誌沒有任何輸出。期間作業系統並沒有發生重啟現象。

原因初步分析：

導致LMS的呼叫沒有響應的最常見的原因是資料庫所在的Lpar的系統資源如記憶體/CPU出現瓶頸。而通常在作業系統資源緊張的情況下，會伴隨著以下表現：

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

>> RAC節點之間的某些心跳檢測得不到響應的情況下，為了恢復整個RAC叢集的對外服務能力，11g後將優先啟動MemberKill,即終止資料庫例項的方式嘗試恢復，如果memberKill無法解決問題，則升級為NodeKill,即重啟OS的方式來恢復整個叢集的對外服務能力

接下來檢查CRSD程式的日誌

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

2.1.2

節點1 CRSD.LOG

從下圖可以看到：

17:42:30,CRSD檢測VIP的健康情況，10秒後，檢測超時，於是狀態變UNKNOWN（然後被CRSD嘗試重啟）

從下圖可以看到：

17:51:18秒，由於VIP宕，而監聽依賴於VIP，因此監聽被請求停止。

從下圖可以看到：

17:54:34,檢測到資料庫資源ora.XXDB.db被異常終止

2.1.3ocssd.log

從上圖可以看到：

其實在2015-12-28 17:47:17，OCSSD程式就收到了節點2的Member kill request的請求，需要殺掉資料庫例項。實際上，到了18:02:48，資料庫才開始啟動。

這期間經過了長達15分鐘，說明資料庫伺服器資源已經很緊張，能導致效能如此緩慢的，通常只有記憶體出現大量換頁。

2.2 作業系統效能-隱患早已埋下

從上述分析可以知道，事實上從17:41:10到17:42:39，資料庫節點1系統資源就開始出現了緊張，開始變得緩慢了！

2.2.1

檢視CPU使用情況

可以看到：

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

2.2.2

檢視記憶體換頁情況（pi/po）

可以看到:

NMON每5分鐘取樣一次，

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

這說明系統資源已經非常緊張！這是最重要的一個證據！

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

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

另外，不難發現，在出問題以前，pageSpace的利用率達到12.44！說明以前就出現了記憶體不足！小y建議大家，如果發現自家AIX平臺上出現pageSpace被使用的情況時，務必好好分析下記憶體的使用情況，否則將是一個大雷。

2.2.2

為什麼會出現記憶體換頁？

小y看到該資料的時候，嚇了一跳！

出問題前，如16:24到17:29之間，資料庫伺服器的計算記憶體（%comp）就已經長時間處於90%的高位了！這對於AIX來說，是非常危險的！對於計算記憶體，我們要儘量控制在80%以下，這樣的系統才是出於健康狀態的系統！

90%的計算記憶體已經接近記憶體換頁的臨界點！

當出現一些稍微大的記憶體的使用需求，則會使得系統出現記憶體換頁。

那麼到底是誰觸發了換頁呢？

在小y看來，如果一面牆快倒了，那麼誰碰倒了這面牆不重要了！所以這不是問題的關鍵。

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

說明17點44分左右系統確實處於記憶體緊張狀態。

17點49分時，計算記憶體更是達到了97%！（44分已經異常，必定導致程式堆積，繼而加大記憶體的使用）

2.3 記憶體規劃-客戶的如意算盤

資料庫伺服器記憶體大小為50G，客戶最開始的記憶體規劃如下

>> SGA配置25G

>> PGA配置為5G

>> 資料庫引數processes為2000，日常執行在1000個程式

資料庫對記憶體的佔用可以使用下面的簡單公式來計算：

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

正常情況下，11G版本資料庫，單個ORACLE服務程式的記憶體佔用在3M，

因此平時記憶體的使用為25G+5G+1000*3M=33G，佔Lpar記憶體的66%。

如果按照出現異常等待，2000個程式被調起來的情況，則記憶體的使用為25G+5G+2000*3M=36G，規劃偏大。

2.4 分析記憶體使用到底去哪了-現實很殘酷

由於資料庫對記憶體的佔用可以使用下面的簡單公式來計算：

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

這裡，SGA是個硬限制,PGA不是硬限制（無論工作區或非工作區都不是硬限制）

小y透過dba_hist_pgastat獲得pga的峰值，發現也就是5個G，沒有突破PGA的引數限制，那麼最有可能的就是“程式在OS級的消耗”佔的記憶體比較多了。

因此，小y馬上透過 procmap命令檢查單個程式的記憶體消耗:

發現ORACLE單個記憶體佔用到了10M（將第二列加起來）

到了這裡，小y已經知道答案了！

讀者朋友們，也可以停一下，把上述現象總結一下，再思考個幾分鐘，如果是你來接這個CASE，你會怎麼繼續往下查呢？

↓

↓

↓

↓

↓

↓

↓

↓

↓

↓

↓

↓

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

那麼記憶體用到了哪裡呢？小y的做法很簡單，透過svmon –P命令可以看到記憶體佔用的細節。

可以看到：

每個ORACLE服務程式work型別的獨佔記憶體中， USLA heap部分佔了1642個記憶體頁，而每頁4K，即多佔6-7M。

事實上這是一個作業系統和資料庫的已知BUG。

中亦科技在其他資料中心已經遇到過好幾次該問題。

2.5 不可小看的7M記憶體

資料庫伺服器記憶體大小為50G，客戶最開始的記憶體規劃如下

>> SGA配置25G

>> PGA配置為5G

>> 資料庫引數processes為2000，日常執行在1000個程式

我們現在再來看一下：

正常情況下：

11G版本資料庫，單個ORACLE服務程式的記憶體佔用是10M而非3M！

因此平時記憶體的使用為25G+5G+1000*10M=40G，光資料庫就佔了記憶體的80%！這是比較危險的！對於AIX平臺，資料庫佔記憶體建議在50%-60%之間，因為作業系統kernel等還會使用記憶體，最多可使用到40%，比較常見的是kernel inode cache的使用。

如果按照出現異常等待，2000個程式被調起來的情況，則記憶體的使用為25G+5G+2000*10M=50G

2.6 確認作業系統和資料庫BUG

到這裡後，就簡單了。

小y在mos上以USLA做關鍵字搜尋，以下就找到了對應的BUG.

下面的這篇note,是ORACLE官網上對於USLA heap導致單個程式多佔7M記憶體，

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

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

2.7 如何解決呢？

這個問題是作業系統的一個缺陷，需要作業系統和資料庫同時安裝補丁才可以解決:

>> 對於AIX 6.1 TL07 or AIX 7.1 TL01需要作業系統和資料庫同時安裝補丁才可以解決。

>> 對於AIX 6.1 TL07 SP02/AIX 7.1 TL01 SP02 or later,由於作業系統已經修復，只需在資料庫端安裝補丁13443029。

資料庫補丁13443029在11.2.0.3下不包含在任何PSU中，11.2.0.4中才包含了該問題的修復。

Part 3

原因總結和建議

3.1 原因總結

資料庫伺服器記憶體大小為50G，記憶體規劃如下

? SGA配置25G

? PGA配置為5G

? 資料庫引數processes為2000

28日平均資料庫服務程式數為1000個左右

由於作業系統和資料庫的一個已知缺陷--11gR2Aix - Dedicated Server Processes Have Large Usla Heap Segment Compared To Older Versions (Doc ID 1260095.1)，導致一個空閒的資料庫服務程式在USLA部分多佔了7M左右的私有記憶體。

因此資料庫整體佔到了 25 G + 5G + 1000*10M=40G，即40G左右的計算記憶體，資料庫已經佔到80%以上的記憶體（通常要控制在60%），加上kernel等記憶體的使用，資料庫平時執行在接近90%的計算記憶體的狀態。這使得資料庫伺服器執行在記憶體高位下，當出現程式數增多、排序雜湊等記憶體需求的時候，繼而出現記憶體換頁情況，將整體系統拖的異常緩慢。

記憶體緊張時本次故障的原因，最直接的證據如下：

NMON每5分鐘取樣一次，

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

這說明系統資源已經非常緊張！這是最重要的一個證據！

資料庫叢集自身檢測到VIP/資料庫資源無響應的情況下，進行了異常處理，繼而導致監聽、VIP、資料庫例項宕的故障。

3.2 建議

透過解決“作業系統和資料庫關於USLA的缺陷“以及對資料庫記憶體引數進行規劃，可減少記憶體的使用，使得系統執行在更健康的記憶體狀況下，從而從根本上解決該問題。

1） 安裝資料庫補丁13443029，使資料庫重新以shrsymtab這個選項來編譯，將USLA部分的7M記憶體減至幾十K，從而多騰出來7G左右的記憶體（如果以2000個程式算，則騰出來14G記憶體）

2） 將資料庫SGA記憶體sga_target引數從25G調小到20G。

調整說明：

經過兩個調整後，在沒有為lpar新增記憶體的情況下，

資料庫的記憶體規劃是 20G+5G+1000*3M=28G，如果算2000個程式跑滿的情況下，資料庫的記憶體規劃是 20G+5G+2000*3M=31G

從而使得系統記憶體資源更富餘，不會因為一些私有記憶體的需求而出現換頁的情況。

Part 4

共性風險提醒

小y透過該案例，做出一些共性的風險提示：

不要低估一個空閒的Oracle服務程式所佔用的記憶體帶來的影響！

大家再做記憶體規劃時，往往忽略了這一點！

如果您的資料庫版本是11GR2，並且執行在AIX6/7的版本上，那麼您的系統中很可能存在過度消耗記憶體的問題，即一個Oracle服務程式比10G版本的時候要多出7M左右的記憶體，從而使得單個ORACLE程式從3M變到10M。這對於Oracle服務程式數較多的資料庫來說，是致命的。

例如，對於一個執行著2000個Oracle服務程式的資料庫而言，所佔用的記憶體不是2000*3=6G，而是2000*10=20G，多出14G。多出的14G將會超出你的記憶體規劃，使資料庫執行在危險狀態下。是否命中該問題，可以參考文中分享的案例！

以下是ORACLE官網上對於USLA heap導致單個程式多佔7M記憶體，

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

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

這個問題是作業系統的一個缺陷，需要作業系統和資料庫同時安裝補丁才可以解決:

>> 對於AIX 6.1 TL07 or AIX 7.1 TL01需要作業系統和資料庫同時安裝補丁才可以解決。

>> 對於AIX 6.1 TL07 SP02/AIX 7.1 TL01 SP02 or later,由於作業系統已經修復，只需在資料庫端安裝補丁13443029。

資料庫補丁13443029在11.2.0.3下不包含在任何PSU中，11.2.0.4中才包含了該問題的修復。

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.

About Me

....................................................................................................................................................

本文來自於微信公眾號轉載文章，若有侵權，請聯絡小麥苗及時刪除

ITPUB BLOG：http://blog.itpub.net/26736162

QQ：642808185 若加QQ請註明您所正在讀的文章標題

【版權所有，文章允許轉載，但須以連結方式註明源地址，否則追究法律責任】

....................................................................................................................................................