由重啟引起的Oracle RAC節(jié)點宕機分析及追根溯源

1、 由重啟引起的Oracle RAC節(jié)點宕機分析及追根溯源 1背景說明某省份的電信業(yè)務(wù)系統(tǒng)由于業(yè)務(wù)量較大，按地市劃分部署在4套配置相同的RAC上，相同主機版本，相同的CRS和數(shù)據(jù)庫版本。該系統(tǒng)已正常運行3年多，其間也有重啟主機等正常維護操作。從4月24日 開始，這個系統(tǒng)的4套RAC的節(jié)點，一個接一個地宕機重啟，但每次都不是同一個節(jié)點。整理的宕機情況列表如下：系統(tǒng) 宕機時間-xx1db01 04-24xx1db02xx2db01 07-30 xx2db02 07-23xx3db01 08-19xx3db02 07-27xx4db01xx4db02這4套RAC是3年前安裝的，平時運行非常穩(wěn)定，基本沒

2、有問題，從4月份開始有節(jié)點宕機，并且在7，8月份宕機頻率非常高。但有點比較奇怪，每次宕機都是不同的節(jié)點，沒有相同的節(jié)點發(fā)生宕機。由于配置了業(yè)務(wù)隔離，所以RAC宕一個節(jié)點，對業(yè)務(wù)影響不大，但是如此大規(guī)模的節(jié)點宕機，肯定有一些共性的問題。每次宕機基本為ocssd.bin進程出錯，直接重啟節(jié)點。ocssd.bin報錯的日志基本為：clssscExit: CSSD signal 11 in thread GMClientListener這4套RAC的配置如下：主機版本：HP-UX B.11.31 U ia64數(shù)據(jù)庫CRS版本為：10.2.0.5.0（未打PSU）數(shù)據(jù)庫版本為：10.2.0.5.8（PS

3、U號：13923855）安裝了Veritas Storage Foundataion，使用VCS集群文件系統(tǒng)。24月24日宕機分析過程4月24日，xx1db01節(jié)點宕機，這是這套業(yè)務(wù)系統(tǒng)的第一次節(jié)點宕機。由于沒有安裝OSWatch工具，無法得知宕機時操作系統(tǒng)資源情況。檢查操作系統(tǒng)日志，沒有發(fā)現(xiàn)報錯信息。這可能是系統(tǒng)直接重啟時，還沒有來得及把內(nèi)存中的信息刷到磁盤。檢查數(shù)據(jù)庫的alert日志，宕機重啟時數(shù)據(jù)庫實例沒有異常信息。檢查ocssd.log，發(fā)現(xiàn)如下報錯：clssscExit：CSSD signal 11 in thread這個報錯以前沒有碰見過。對這個報錯的相關(guān)解釋：當RAC GM cl

4、ient監(jiān)聽線程在處理clsc_disc_orphans時，CSSD.LOG中會出現(xiàn)clsc_disc_orphans的信息，該函數(shù)在處理clsc_disc嘗試斷開連接時，負責獲得和持有線程信息。存在BUG(Bug 9132429: LNX64-10205-CRS:NODE CRASH AFTER 5 MINUTES OF HANG/RESUME OCSSD.BIN。)可能導致多個session形成死鎖，最終導致節(jié)點HANG住或被驅(qū)逐宕機。MOS上的這個Bug 9132429是在Linux平臺上，當前主機是HP-UX。請網(wǎng)絡(luò)組檢查心跳交換機，沒有發(fā)現(xiàn)閃斷或者其它異常。由于沒有檢查到有用的信息，

5、認為這可能是ocssd.bin進程的偶然報錯現(xiàn)象，暫時沒法解釋這個問題。37月23日宕機分析過程07月23日，xx2db02發(fā)生宕機，檢查結(jié)果和4月23日一樣，其它全部沒有信息，只有ocssd.log日志信息如下：經(jīng)過確認，主機重啟是由于ocssd的GMClientListener問題導致。由于未在主機上安裝系統(tǒng)資源監(jiān)控工具，沒有有效的主機資源使用情況。在MOS上了開SR，SR回復可能是主機資源使用存在問題，但沒有OSW的信息，他們給不出解釋。47月27日宕機分析過程7月27日，xx3db02宕機，Oracle Support認為在ocssd.log中存在Authentication OSD

6、error信息，可能是認證失敗導致GMClientListener發(fā)生問題，進而cssd.bin進程宕掉。相關(guān)日志信息如下：認證信息失敗的原因，可能有以下幾點：1、節(jié)點間有防火墻 【沒有配置】2、節(jié)點間有authentication tools 【未配置】3、$ORA_CRS_HOME/crs/css目錄權(quán)限發(fā)生改變 【未發(fā)生】4、/oracle文件系統(tǒng)滿 【未滿】5、/tmp目錄下的.oracle目錄被刪除 【未刪除】6、節(jié)點間認證信息網(wǎng)絡(luò)包發(fā)生問題 【無證據(jù)】而前兩次宕機，沒有Authentication OSD error的信息，所以沒有直接證據(jù)表明Authentication OSD

7、error造成了CSSD signal 11 in thread GMClientListener，Authentication OSD error錯誤信息也可能是結(jié)果，不是根本原因。監(jiān)控系統(tǒng)上主機資源使用情況如下，CPU使用率：IO使用率：SR認為監(jiān)控粒度太粗。給這4套RAC、8個節(jié)點全部安裝了OSWatch，下次如果有其它節(jié)點宕機就有詳細的操作系統(tǒng)資源使用信息。57月30日宕機分析過程7月30日，xx2db01宕機，日志信息如下：發(fā)生“clsc_event_hndlr: (6000000000ae51b0) answer error, rc 15”，Oracle認為是操作系統(tǒng)發(fā)生了問題。檢

8、查ulimit信息：rootxx2db01:/#ulimit -atime(seconds) unlimitedfile(blocks) unlimiteddata(kbytes) 4194300stack(kbytes) 392192memory(kbytes) unlimitedcoredump(blocks) 4194303nofiles(descriptors) 20480rootxx2db01:/#su - oracleoraclexx2db01:/oracle#ulimit -atime(seconds) unlimitedfile(blocks) unlimiteddata(kb

9、ytes) 4194300stack(kbytes) 392192memory(kbytes) unlimitedcoredump(blocks) 4194303nofiles(descriptors) 20480檢查file相關(guān)的內(nèi)核參數(shù)：oraclexx2db01:/oracle#/usr/sbin/kctune |grep filefcache_seqlimit_file 100 Default Immedfilecache_max 130470211584 Default Autofilecache_minDefault Automax_acct_file_s

10、ize 2560000 Default Immedmaxfiles 20480 20480maxfiles_lim 20480 20480 Immed檢查nproc內(nèi)核參數(shù)：oraclexx2db01:/oracle#/usr/sbin/kctune |grep nprocnproc 30000 30000 Immedoraclexx2db01:/oracle#/usr/sbin/kctune nfileTunable Value Expression Changesnfile 0 Default ImmedSR認為這些參數(shù)都正常。上次故障時，在所有節(jié)點上都安裝了OSW工具，這次有了相關(guān)主機資

11、源信息。經(jīng)過檢查，vmstat中顯示：從7月30號的08:42到宕機時的09:34，一直存在pi的情況，而空閑內(nèi)存為11g左右。xx2db01主機是256G內(nèi)存，sga_max_size=100g，pga_aggregate_target=40g。宕機時vmstat信息如下，空閑內(nèi)存為11g，有一些內(nèi)存頁交換。而正常情況下xx2db01主機的空閑內(nèi)存是100g，pi基本為0。經(jīng)過檢查，內(nèi)核參數(shù)filecache_max 130470211584 Default Auto這個參數(shù)表明主機允許文件緩存最大為130g左右，該參數(shù)設(shè)置較高，有可能占用大部分內(nèi)存，但是OSWatch沒有監(jiān)控這個參數(shù)，所以

12、宕機時無文件系統(tǒng)緩存的相關(guān)信息。當前使用了Veritas ODM，基本用不到操作系統(tǒng)緩存，建議把該參數(shù)調(diào)整到10g。在宕機時的ps輸出文件中存在大量的sendmail和rmail進程，但具體不清楚是什么作用。這次故障的原因，猜測是主機swap造成，但從vmstat中監(jiān)控到主機空閑內(nèi)存還有11g左右（主機內(nèi)存是256g），不怎么確認一定是主機內(nèi)存耗盡導致ocssd.bin出現(xiàn)故障。暫時建議：filecache_max調(diào)整到10g左右，減小文件系統(tǒng)占用內(nèi)存導致宕機的概率。調(diào)整CSSD的日志級別為4，讓cssd出故障時，輸出更多的日志信息。crsctl debug log css CSSD:468月

13、19日宕機分析過程8月19日，xx3db01節(jié)點也是因為“CSSD signal 11 in thread GMClientListener”發(fā)生宕機重啟。vmstat查看宕機時內(nèi)存使用情況，發(fā)現(xiàn)宕機時空閑內(nèi)存有將近80g，這又排除了內(nèi)存緊張，主機swap導致的問題。通過詳細檢查OSWatch日志，發(fā)現(xiàn)了宕機時ocssd.bin內(nèi)存占用達到8g。跟SR交流，SR建議以下ulimit設(shè)置為unlimited，如下：data(kbytes) unlimitedstack(kbytes) unlimited我檢查了7月30日宕機時，ocssd.bin的大小，發(fā)現(xiàn)也是8g左右。懷疑是不是進程所使用的內(nèi)

14、存達到限制導致，這時侯我咨詢了主機工程師，是否有內(nèi)核參數(shù)，限制一個進程能夠使用的內(nèi)存大小，查到如下參數(shù)：rootxx3db01:/ # kctune | grep maxdsizmaxdsiz 4294963200 4294963200 Immedmaxdsiz_64bit 8589934592 8589934592 Immed這兩個參數(shù)解釋如下：maxdsiz、maxdsiz_64bit，是指任何用戶進程的數(shù)據(jù)段的最大大?。ㄒ宰止?jié)為單位）。HP-UX 系統(tǒng)上的用戶程序由五個不連續(xù)的虛擬內(nèi)存段組成：文本（或代碼）、數(shù)據(jù)、堆棧、共享的和 I/O。每個段都占用一段已設(shè)定大小上限的結(jié)構(gòu)化定義的虛擬地

15、址空間范圍，但由于 maxtsiz、maxdsiz 和 maxssiz 可調(diào)參數(shù)的強制約束，文本、數(shù)據(jù)段和堆棧段的最大值可能會略小。此可調(diào)參數(shù)定義了 32 位和 64 位進程的靜態(tài)數(shù)據(jù)存儲段的最大大小。數(shù)據(jù)存儲段包含了固定的數(shù)據(jù)存儲，例如使用 sbrk() 和 malloc() 在main()、字符串和空間中分配的全局變量、數(shù)組變量、靜態(tài)變量和局部變量。檢查其它HP-UX上的10g庫，發(fā)現(xiàn)10.2.0.4的RAC，ocssd.bin內(nèi)存占用正常，而所有10.2.0.5版本的ocssd.bin內(nèi)存占用在緩慢增加。檢查未發(fā)生過宕機的xx4db02節(jié)點上ocssd.bin進程一段時間的內(nèi)存使用情況，

16、確認存在內(nèi)存泄露問題。猜想可能是內(nèi)存泄露導致了ocssd.bin內(nèi)存占用過高，達到操作系統(tǒng)限制，造成ocssd.bin出現(xiàn)問題，進而宕機重啟。經(jīng)過到MOS上檢查，發(fā)現(xiàn)如下Bug：Memory usage of crsd.bin and ocssd.bin keeps growing after upgrade to 10.2.0.5 (文檔 ID 1633236.1)Bug 11704113 - OVER TIME THE MEMORY USAGE OF THE CRSD.BIN PROCESS GROWS TO VERY LARGE VALUESSR也確認是由于crsd.bin的nsdo()

17、函數(shù)發(fā)生內(nèi)存泄露，導致ocssd.bin受影響。當前情況與MOS文檔上描述一致。7總結(jié)問題的根本原因是，由于存在如下Bug：Memory usage of crsd.bin and ocssd.bin keeps growing after upgrade to 10.2.0.5 (文檔 ID 1633236.1)Bug 11704113 - OVER TIME THE MEMORY USAGE OF THE CRSD.BIN PROCESS GROWS TO VERY LARGE VALUES導致ocssd.bin進程的內(nèi)存使用率持續(xù)上升，達到了maxdsiz_64bit內(nèi)核參數(shù)的限制，進而造成ocssd.bin進程故障，ocssd.log日志中的“clssscExit: CSSD signal 11 in thread GMClientListener”信息，signal 11代表內(nèi)存申請失敗。