```
某日，資料庫告警最最最核心的一套資料庫1節點hang，立馬開啟連線視窗，檢視當前系統負載，
發現topas已經無法執行，過濾LOCAL=NO會話kill掉已經無法執行，
報錯無法分配記憶體，無法連線資料庫，重啟作業系統，恢復服務。
```

事後最終定位問題，發現在執行kill會話命令報錯無法分配記憶體，早已指明瞭故障原因，伺服器相關指標也早已指向記憶體不足，只是由於以下兩方面原因導致定位問題走了許多彎路，甚至一度只能猜測原因：
```
 1. AIX記憶體由於大部分情況下有很大一部分file cache，導致監控長期顯示記憶體使用率均在90%以上，
 所以並未真正注意AIX記憶體各個部分佔用比例指標，導致故障伺服器記憶體其實早已在危險邊緣試探，
 而我們並未及時調整。
 2. 對AIX記憶體各個部分佔比、管理方式、相關引數設定一知半解，
 導致未從監控資料相關資訊中發現這是由於記憶體不足-會話增長-記憶體耗盡導致。
```
下面就故障分析過程以及AIX記憶體管理分享，供大家參考。

# 1. 故障現象

- 監控系統告警資料庫hang，透過已連線ssh會話檢視CPU 100%，伺服器hang。
 - 除已經連線使用者外，無法再透過ssh、sqlplus連線伺服器。 
**環境概述**
資料庫版本11.2.0.4，作業系統AIX 7.1
# 2. 初步分析，是Oracle還是OS出了問題？
一般對於遠端連線無法執行命令，根據經驗一般為swap頻繁page in、page out，記憶體耗盡導致，那到底是哪兒出了問題呢？下面就需要結合下面兩部分進行分析：
 - 作業系統nmon、oswatcher資料
 - Oracle叢集日誌、資料庫日誌進行診斷。、
## 2.1 資料庫日誌以及ASH分析
資料庫以及叢集日誌
 1. 故障節點alert日誌
 - 在故障前alert日誌並無異常，故障期間，可以看到alert日誌如下，15:29分之前日誌並無異常，未擷取。
- 結合報錯Error 1013 during filling up usn avail cache，Oracle Mos有文件，但是與發生故障Oracle版本並不對應，現象也不匹配，所以可以作為參考。
```
Mon Jan 11 15:29:56 2021
AP01: warning -- apply server 20, sid 6085 waiting for event (since 731 seconds):
AP01: warning -- apply server 42, sid 6126 waiting for event (since 354 seconds):
AP01: warning -- apply server 45, sid 3788 waiting for event (since 342 seconds):
AP01: warning -- apply server 44, sid 3530 waiting for event (since 564 seconds):
AP01: warning -- apply server 40, sid 2419 waiting for event (since 343 seconds):
AP01: warning -- apply server 33, sid 4578 waiting for event (since 344 seconds):
Mon Jan 11 15:30:30 2021
AP01: warning -- apply server 31, sid 1049 waiting for event (since 435 seconds):
Mon Jan 11 15:32:07 2021
Mon Jan 11 15:32:07 2021
Mon Jan 11 15:32:07 2021
[27328748] Error 1013 during filling up usn avail cacheMon Jan 11 15:32:07 2021
[19595412] Error 1013 during filling up usn avail cache
***********************************************************************
***********************************************************************
Mon Jan 11 15:32:17 2021
[16058276] Error 1013 during filling up usn avail cache
Mon Jan 11 15:32:12 2021
[11799172] Error 1013 during filling up usn avail cache
Mon Jan 11 15:32:19 2021
[2886074] Error 1013 during filling up usn avail cache
Mon Jan 11 15:32:16 2021	
```

2. 叢集日誌
- 可以看到是在節點1告警hang之後，叢集監測到了異常。
- 叢集日誌並無相關報錯資訊，只是監測到1節點資源無法確定狀態，置為unknown，在其叢集其他crsd、cssd、agent日誌中均類似，並無相關資源或程式報錯。

```
2021-01-11 15:30:48.975: [UiServer][11311]{1:44279:29645} Done for ctx=132437ab0
2021-01-11 15:32:27.616: [ COMMCRS][11568]clsc_auth_send: (1325a2470) Connection not active

2021-01-11 15:32:38.344: [ COMMCRS][11568]Authorization failed, network error

2021-01-11 15:32:38.344: [UiServer][11568] clscanswer returned error: 3
2021-01-11 15:32:55.936: [    AGFW][9769]{0:1071:37} Agfw Proxy Server received the message: RESOURCE_STATUS[Proxy] ID 20481:912859
2021-01-11 15:32:55.936: [    AGFW][9769]{0:1071:37} Verifying msg rid = ora.asm wbxtdb01 1
2021-01-11 15:32:55.936: [    AGFW][9769]{0:1071:37} Received state change for ora.asm wbxtdb01 1 [old state = ONLINE, new state = UNKNOWN]
2021-01-11 15:32:55.936: [    AGFW][9769]{0:1071:37} Received state LABEL change for ora.asm wbxtdb01 1 [old label  = Started, new label = ]
2021-01-11 15:32:55.936: [    AGFW][9769]{0:1071:37} Agfw Proxy Server sending message to PE, Contents = [MIDTo:2|OpID:3|FromA:{Invalid|Node:0|Process:0|Type:0}|ToA:{Invalid|Node:-1|Process:-1|Type:-1}|MIDFrom:0|Type:4|Pri2|Id:8026336:Ver:2]
2021-01-11 15:32:55.936: [    AGFW][9769]{0:1071:37} Agfw Proxy Server replying to the message: RESOURCE_STATUS[Proxy] ID 20481:912859
2021-01-11 15:33:20.391: [ COMMCRS][11568]clsc_auth_send: (13254d650) Connection not active

2021-01-11 15:33:22.407: [  OCRMSG][5912]prom_send: Failed to send [12]
2021-01-11 15:33:22.407: [  OCRMSG][5912]GIPC error [12] msg [gipcretConnectionLost]
2021-01-11 15:33:25.099: [    AGFW][9769]{0:1071:37} Agfw Proxy Server received the message: RESOURCE_PROBE[ora.asm wbxtdb01 1] ID 4097:17486001
2021-01-11 15:33:25.099: [    AGFW][9769]{0:1071:37} Agfw Proxy Server forwarding the message: RESOURCE_PROBE[ora.asm wbxtdb01 1] ID 4097:17486001 to the agent /u01/11.2.0/grid/bin/oraagent_grid
2021-01-11 15:33:26.200: [ COMMCRS][11568]Authorization failed, network error

2021-01-11 15:33:26.201: [UiServer][11568] clscanswer returned error: 3
2021-01-11 15:34:30.743: [    AGFW][9769]{0:1071:38} Agfw Proxy Server received the message: RESOURCE_STATUS[Proxy] ID 20481:912892
2021-01-11 15:34:30.743: [    AGFW][9769]{0:1071:38} Verifying msg rid = ora.asm wbxtdb01 1
2021-01-11 15:34:30.743: [    AGFW][9769]{0:1071:38} Received state LABEL change for ora.asm wbxtdb01 1 [old label  = , new label = CHECK TIMED OUT]
2021-01-11 15:34:30.743: [    AGFW][9769]{0:1071:38} Agfw Proxy Server sending message to PE, Contents = [MIDTo:2|OpID:3|FromA:{Invalid|Node:0|Process:0|Type:0}|ToA:{Invalid|Node:-1|Process:-1|Type:-1}|MIDFrom:0|Type:4|Pri2|Id:8026352:Ver:2]
2021-01-11 15:34:30.743: [    AGFW][9769]{0:1071:38} Agfw Proxy Server replying to the message: RESOURCE_STATUS[Proxy] ID 20481:912892
2021-01-11 15:34:53.907: [    AGFW][9769]{0:1071:38} Agfw Proxy Server received the message: CMD_COMPLETED[Proxy] ID 20482:17486028
2021-01-11 15:34:53.907: [    AGFW][9769]{0:1071:38} Agfw Proxy Server replying to the message: CMD_COMPLETED[Proxy] ID 20482:17486028
2021-01-11 15:34:53.907: [    AGFW][9769]{0:1071:38} Agfw received reply from PE for resource state change for ora.asm wbxtdb01 1
2021-01-11 15:35:41.347: [UiServer][11568] CS(1324f3910)set Properties ( grid,13241e050)
2021-01-11 15:35:59.223: [UiServer][11568] CS(1325501f0)set Properties ( grid,13254f990)
```
3. ASH資訊
- 可以看到在故障前並無異常等待事件，均為正常OGG整合投遞以及一些weblogic正常執行SQL會話。
- 由於此時作業系統已無法響應，所以15:30~15:36相關資訊ASH中未取樣到。
 
## 2.2 作業系統監控資料分析
    遇到資料庫嚴重故障，作業系統的CPU、memory、I/O等資訊對定位問題就變得非常重要，
    不結合作業系統監控資料往往只能根據資料庫殘留的一些資訊對故障原因進行猜測。
1. oswatcher資料
oracle 11.2.0.4 RAC會自帶oswatcher，可透過下面命令檢視oswatcher資料存放目錄，預設30秒取樣一次，保留48小時。
```
# ps -ef|grep OSW
oracle    2087 27820  0 10:01 pts/3    00:00:00 grep --color=auto OSW
grid      3638     1  0 Jan21 ?        00:22:47 /bin/sh ./OSWatcher.sh 30 48 NONE /u01/app/grid/tfa/repository/suptools/db-oracle-node1/oswbb/grid/archive
grid      4224  3638  0 Jan21 ?        00:01:03 /bin/sh ./OSWatcherFM.sh 48 /u01/app/grid/tfa/repository/suptools/db-oracle-node1/oswbb/grid/archive
```
拿到oswatcher archive目錄所有資料之後，可將資料複製至任意安裝java機器或windows機器使用如下命令解析：
```
 如果解析報錯[10:02:01]An exception occured in insertVmstatLists on line 0，則需要設定相應時間格式如下：
 # Linux
export LANG=zh_US
需要英文格式時間戳，重新設定LANG變數，重新執行java -jar即可
# windows
如果是想在windows機器上解析osw檔案，需要在控制皮膚-區域-中設定為英語(美國)即可。
 命令：
  java -jar -Xmx512M OSWbba.jar -i /mnt/hgfs/database/oswbb/archive
  OSWbba.jar可以透過複製伺服器端，也可以單獨下載oswatcher使用解壓後的oswbba。jar
```
- 可以看到在故障時間段15:30~15:45期間，CPU到最後15:45左右伺服器hang都沒有達到100%。
- 在故障期間，發生了記憶體交換，這說明故障期間，可用記憶體不足，記憶體耗盡。
- oswatcher還會生成每隔30秒的ps命令生成的程式資訊，我們透過分析ps相關資訊發現LOCAL=NO會話在故障前後如下：
在15:00到15:15分左右，LOCAL=NO會話由2800增長至3500,15:15到15:30左右，會話數維持在3500左右略有下降，在15:30到15:45伺服器hang期間，會話由於得不到響應，暴漲至最高4500直到重啟伺服器。
**~注：所以oswatcher的ps統計資訊也是非常重要的資訊，可以真實判斷會話總數趨勢。~**
2. nmon資料
- 如果說oswatcher圖粒度不夠細，那麼nmon資料展示則更為容易分辨趨勢。
- 下面就從摘取最為重要的三個維度CPU、磁碟I/O、記憶體趨勢圖：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20210131195953525.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p3b2NuaW1hYmk=,size_16,color_FFFFFF,t_70)
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20210131200022135.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p3b2NuaW1hYmk=,size_16,color_FFFFFF,t_70)
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20210131200046720.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p3b2NuaW1hYmk=,size_16,color_FFFFFF,t_70)
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20210131200104605.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p3b2NuaW1hYmk=,size_16,color_FFFFFF,t_70)

## 2.3 初步分析結果
- 結合OS監控、資料庫日誌，我們可以初步推斷為作業系統記憶體耗盡，引發swap使用，從I/O hdisk0達到busy 100%也可印證，導致伺服器hang，進而導致資料庫hang。
- 以前沒注意過AIX記憶體管理機制，所以未對相關重要指標進行監控以及管理，導致伺服器記憶體其實早就已經開始在危險邊緣試探而我們卻並未在意，最終導致業務期間會話突增700連線壓垮伺服器，引發故障。
- 至於應用為何突然增加700會話由於某些原因並未深究，但是這次故障也提醒了我們需要在一些伺服器細化重點指標監控上注意，防患未然。
# 3. 進一步分析，伺服器記憶體早已岌岌可危
- 為什麼說伺服器記憶體早已岌岌可危，我們從下面兩張圖開始分析(第二張圖為第一張圖的數值)：
 ![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20210131200228863.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p3b2NuaW1hYmk=,size_16,color_FFFFFF,t_70)
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20210131200258253.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p3b2NuaW1hYmk=,size_16,color_FFFFFF,t_70)
- 看到這裡，其實對AIX記憶體有所瞭解即可一眼判斷，伺服器記憶體是真的已經不足了這是因為：
- 	%comp計算記憶體在故障前已經達到95%以上，記憶體即將耗盡。
# 4. 透過故障，瞭解AIX記憶體管理
俗話說，吃一塹長一智，其實瞭解清楚AIX記憶體管理方式以及各個指標含義，定位問題之後，發現故障很嚴重，但是原因遠比想象簡單，我們也從故障中吸取教訓，下面就詳細講述AIX記憶體管理。
## 4.1 AIX記憶體分類
AIX記憶體可透過用途分為兩大類：

```
1. Computational memory, also known as computational pages, consists of the pages 
that belong to working-storage segments or program text (executable files) segments.
2. File memory (or file pages) consists of the remaining pages. These are usually pages
from permanent data files in persistent storage.
```
上述AIX官方文件描述，引用http://blog.itpub.net/29455589/viewspace-1075369/敘述：

```
~計算記憶體： 凡是程式/程式執行中用程式程式碼向作業系統申請的記憶體，全部是計算記憶體，
也就是說除非這個程式執行起來，除了自身程式碼佔用的記憶體，一點額外的記憶體也不用， 
否則它幾乎必然會造成計算記憶體佔用的。說“幾乎”，是因為計算記憶體、非計算記憶體都是
指實體記憶體，如果一個程式申請了1MB記憶體，但一段時間沒有用這部分記憶體， 很可能
在其他程式需要記憶體，且實體記憶體比較緊張時，按照LRU演算法（Latest Recently Unused），
被作業系統部分或全部page out到paging space中， 如果全部被page out了，可以說這個
時刻，此程式沒有使用計算記憶體。換句話說，就是程式申請了1MB記憶體，那麼它在某一時
刻佔用的計算記憶體從0位元組～1MB都有可能。 當程式退出，或者意外崩潰，對於作業系統
來說，它知道程式不在了，而程式申請的記憶體，作業系統明確知道是哪些的，在資源回收
的過程中， 會自動把這個程式申請的記憶體釋放掉，這個過程是很快的。所以我們可以看
到：如果計算記憶體高企，我們把應用一停，也就是把使用計算記憶體最多的程式停止，計
算記憶體佔用率立刻就下來了。~
```
```
~非計算記憶體： 作業系統明確知道這部分記憶體的用途是放硬碟對應資料的，所以，顯然
這部分記憶體不是任何程式可以控制，也就是說不可能一個程式主動要求分配多少非計算
記憶體或者釋放多少。 這部分完全是作業系統在直接管理：分配、記錄狀態、使用、釋
放，其他程式只可能用間接手段影響非計算記憶體，例如讀寫檔案。~
```
- 可以看到主要兩部分%comp %ncomp記憶體組成，這兩個指標可以透過topas或nmon獲得。
- 從解釋中可以看出，SGA與PGA所佔用記憶體均為%comp，均需要程式自己去釋放，不屬於AIX VM管理範疇，所以這也就是上述案例中計算記憶體達到95%以上繼續申請計算記憶體，由於記憶體耗盡系統使用page space導致系統hang。
## 4.2 AIX記憶體控制引數
AIX記憶體控制引數主要為如下：

```
- minfree     最小保留記憶體，當記憶體總頁數少於該值，則AIX開始steal頁面，steal頁面來源方式由於記憶體使用不同而不同，AIX 7.1 預設960
- maxfree     當記憶體free list不足minfree時steal頁面，當free達到maxfree時停止steal，AIX 7.1 預設1088
- minperm/minperm%   最小file page數量或比例，AIX 7.1 預設3%
- maxperm/maxperm%   最大file page數量或比例，AIX 7.1 預設90%
- maxpin%             最大可以pin住的記憶體比例，預設90%
- maxclient%         jfs2 檔案系統快取使用client page，不能超過%maxperm，AIX 7.1 預設90%
- lru_file_repage    控制當file page佔用比例在%minperm與%maxperm之間時，記憶體管理repaging時是否steal計算記憶體與file page，AIX 5L預設為1，AIX 6.1預設為0,一般設定為0，AIX 7.1之後vmo命令已經無法設定該命令。
```

相關概念：
- 當file page佔用在%minperm與%maxperm之間時，當根據lru演算法需要repage記憶體或記憶體不足需要steal page時，AIX 7.1會預設只steal file page，也就是不會偷計算記憶體。
- 當file page佔用在%minperm之下時，一般來說，低於%minperm除了個別非常空閒系統以外，基本發生在計算記憶體佔用非常大，導致file page無法獲得更多記憶體，即實體記憶體緊張時，所以此時需要repage時，會同時根據lru演算法steal計算記憶體與file page。上文例子即發生了這種情況，如果當實體記憶體不足，所有記憶體均在使用，無法repage完成記憶體申請，則會發生page space使用，記憶體耗盡，伺服器hang。
## 4.3 AIX記憶體配置與檢視
```
# vmo -a      檢視所有vm相關設定
# vmo -a      檢視虛擬記憶體機制相關設定 　　
# vmo -r -o minfree=1000 -o maxfree=1008 
# vmo -p -o maxclient% = 90 
# vmo -p -o maxperm%=90 可以指定百分比也可以指定絕對值maxperm引數 
# vmo -p -o minperm%=5  可以指定百分比也可以指定絕對值minperm引數
```
 ~注：-r與-o結合，設定reboot values,-p對當前與reboot都生效，但是隻能用於可動態調整引數，預設AIX page為4k，不帶%為page數量。有個別引數不可動態調整，不可使用-p選項設定。~
```
# svmon -G            檢視記憶體使用概覽 
# svmon -U oracle    檢視某個使用者使用記憶體概覽
```
## 4.4 AIX的大頁

```
# vmo -r -o lgpg_size=16777216 -o lgpg_regions=256 配置256個16M頁面。 
如果要為共享記憶體使用大頁面，還需要將AIX的v_pinshm引數設定為1（預設為0），
使VMM可以固定記憶體池中的頁，以避免發生頁面交換 
# vmo -r -o maxpin%=50     最大可以pin住記憶體比例 
# vmo -r -o v_pinshm=1 允許共享記憶體pin住 
SQL> alter system set lock_sga=true scope=spfile sid='*';   配置Oracle可以鎖定共享記憶體SGA釘在記憶體中
```
# 5. 需要調整AIX VM相關引數嗎？
```
AIX UNIX系統的配置策略，在預設情況下是為檔案系統類應用預設的最佳化。
如果應用是AIX上執行的資料庫類應用，則預設的AIX配置並不適用。
```
所以如果是作為資料庫伺服器，則預設的記憶體相關引數還是需要進行調整，可以適當調整minfree與maxfree，降低%maxperm，同樣也適用於Linux，在Redhat Linux中，對應引數為vm.min_free_kbytes，但是也不建議將這些引數調整過大，調整過大將導致記憶體無法充分利用，會適得其反。
# 總結
```
1. 當故障原因定位方向正確時，會發現處處留存的線索都對的上，當方向不正確時，總會有很匪夷所思的地方。
2. 對於AIX、Linux執行不同型別服務需要設定合理引數，雖然本次故障並不是由於引數設定導致。
3. 對於監控系統，要監控一些重點指標，本次案例就是由於監控一直報各個系統記憶體使用率過高(大部分為
非計算記憶體佔用)將真正計算記憶體佔比很高的伺服器的告警淹沒在了平時認為可忽略的告警訊息中。
```
下面為AIX引數官方文件解釋：

```
1. lru_file_repage AIX 7.1 vmo已經無法查詢該引數
when the number of permanent memory pages (numperm) falls 
between minperm and maxperm (or the number of client memory pages falls between minperm and maxclient), 
this setting indicates whether repaging rates are considered when deciding to evict permanent memory pages or computational memory pages. 
Setting this to 0 tells AIX to ignore repaging rates and favor evicting permament memory pages, keeping more computational memory in RAM. 
The AIX 5L default is 1/true (consider the repaging rate), The AIX 6.1 default is 0/false (now a restricted setting).

2. maxpin% 
tunable can be used to adjust the amount of memory that can be pinned. 
The maxpin% tunable specifies the maximum percentage of real memory that can be pinned.

3. minperm%   maxperm%
If percentage of RAM occupied by file pages falls below minperm, page-replacement steals both file and computational pages.
If percentage of RAM occupied by file pages is between minperm and maxperm, page-replacement steals only file pages.

4. maxclient%
The maxclient parameter controls the maximum percentage of memory occupied by client-segment pages which is where Enhanced JFS file data is cached. 
Note that the maxclient value cannot exceed the maxperm value.
Maxclient represents the maximum number of client pages that can be used for buffer cache.
The enhanced JFS file system uses client pages for its buffer cache. The limit on client pages in real memory is enforced using maxclient.
The LRU daemon begins to run when the number of client pages is within the number of minfree pages of maxclient 's threshold. 
The LRU daemon attempts to steal client pages that have not been referenced recently. 
If the number of file pages is lower than the value of the minperm parameter, any page that has not been referenced can be selected for replacement.
Maxclient also affects NFS clients and compressed pages. 
Also note that maxclient is generally set to a value that is less than or equal to the maxperm parameter.

5. minfree
Minimum acceptable number of real-memory page frames in the free list. When the size of the free list falls below this number, the VMM begins stealing pages. It continues stealing pages until the size of the free list reaches maxfree.

6.  maxfree
Maximum size to which the free list will grow by VMM page-stealing. 
The size of the free list may exceed this number as a result of processes terminating and freeing their working-segment pages or 
the deletion of files that have pages in memory.
The VMM attempts to keep the size of the free list greater than or equal to minfree. 
When page faults or system demands cause the free list size to fall below minfree, 
the page-replacement algorithm runs. The size of the free list must be kept above a certain level (the default value of minfree) for several reasons. 
For example, the operating system's sequential-prefetch algorithm requires several frames at a time for each process that is doing sequential reads. 
Also, the VMM must avoid deadlocks within the operating system itself, 
which could occur if there were not enough space to read in a page that was required to free a page frame.

```

從Oracle資料庫故障到AIX記憶體管理

相關文章