477
墨菲定律：一個參數Drop_caches導致集群數據庫實例崩潰
李真旭@killdb
Oracle ACE，雲和恩墨技術專家
個人博客：www.killdb.com
在墨菲定律裏，我們知道，有可能發生的故障就一定會發生，哪怕需要諸多因素的疊加才可能滿足那複雜的先決條件。在以下案例中，我們抽絲剝繭，細致入微的追溯最終確定了導致數據庫RAC實例崩潰的微小原因。
這是一個真實的客戶案例，可以概括為一條參數引發的血案。現象大致是某天淩晨某 RAC 節點實例被重啟了，通過如下是 alert log 我們可以發現 RAC 集群的節點2實例被強行終止掉了，如下是詳細的告警日誌信息：
從上麵的日誌來看，在2：03分就開始報錯 ORA-00600，一直持續到2:39分，lmd0 進程開始報同樣的錯誤；然後接著 LMD0 進程強行把數據庫實例終止掉了。。直接搜索 Oracle MOS，看上去有點類似這個 bug，不過很容易就可以排除。
Bug 14193240 : LMS SIGNALED ORA-600[KGHLKREM1] DURING BEEHIVE LOAD
從日誌看，2:03分就開始報錯，然而直到 lmd0 報錯時，實例才被終止掉，也就是說 lmd0 報錯才是問題的關鍵。那麼我們首先來分析下 lmd0 進程的 trace 文件內容，如下所示：
從上麵的信息來看，確實是內存 heap 存在錯誤的情況。根據 Oracle MOS 文檔：
ORA-600 [KGHLKREM1] On Linux Using Parameter drop_cache On hugepages Configuration (1070812.1) 的描述來看，此次故障跟文檔描述基本上一致，如下：
其中地址 [0x679000020] 後麵的內容也均為0，跟文檔描述一樣，其次，文章中提到使用了linux 內存釋放機製以及同時啟用了hugepage配置。
根據文檔描述，這應該是 Linux bug。通過檢查對比2個節點配置，發現節點2的配置確實不同：
當 drop_caches 設置為3，會觸發 linux 的內存清理回收機製，可能出現內存錯誤的情況；然而我們檢查配置發現並沒有修改：
因此，我認為是之前人為進行了 echo 3 > /proc/sys/vm/drop_caches 操作來強製釋放內存導致。 通過分析發現隻能查看到最近幾分鍾的操作記錄，如下：
看操作記錄確實發現了操作，那麼同時檢查操作係統日誌也發現了一些蛛絲馬跡，如下：
BUG: soft lockup - CPU#1 stuck for 10s! [rel_mem.sh:13887
可以看到也確實出現了 drop_cache 的相關操作。大家注意看上麵紅色的地方，提到了是執行了一個 shell 腳本，然後還導致一共 cpu stuck 了，而且也能看出該腳本是在執行回收 cache 的動作。
我堅持認為客戶環境上肯定進行了強製的內存回收，但是客戶說他們沒有進行任何人為操作，不過經過我檢查發現確實有一個 crontab 腳本。
那麼為什麼主機上會部署這樣的腳本呢？ 我猜想肯定是操作係統的內存使用率看起來很高，通過檢查發現確實如此：
我們可以看到128G的物理內存，cache 就占據了 88G 的樣子目前。linux 文件係統的 cache 分為2種：page cache 和 buffer cache, page cache 是用於文件，inode 等操作的 cache，而 buffer cache 是用於塊設備的操作。從上麵的數據來看，我們所看到的 free -m 命令中的 cached 88552 全是 page cache。而實際上該數據庫實例的內存分配一共也就40G，且使用的是 linux raw。
我們可以看到，整個主機物理內存為128G，而 Oracle SGA+pga 才40g，另外將近 90G 的內存都是 fs cache 所消耗。完全可以調整 linux 的參數去釋放 cache，而不需要使用 echo 這種比較暴力的方式；根據 Oracle mos 的幾個文檔的描述，推薦設置如下幾個參數：
sysctl -w vm.min_free_kbytes=4096000
sysctl -w vm.vfs_cache_pressure=200
sysctl -w vm.swappiness=40 （老版本的 linux 是設置 vm.pagecache 參數)
關於 linux cache 的一些知識請參考：
https://www.ibm.com/developerworks/cn/linux/l-cache/
File System’s Buffer Cache versus Direct I/O (文檔 ID 462072.1)
本文出自數據和雲公眾號，原文鏈接
最後更新：2017-07-17 18:03:56