苦惱的數(shù)據(jù)庫主機(jī)重啟問題排查與解決

　　情況是這樣的，有一套測試數(shù)據(jù)庫所在的主機(jī)在最近幾個月，每個月都會重啟一至兩次，由于數(shù)據(jù)庫配置了開機(jī)自啟動，且每次重啟時間都比較短暫，便沒有得到重視。最近由于測試人員的反饋，每當(dāng)主機(jī)重啟后呢會導(dǎo)致大片的測試應(yīng)用由于斷連導(dǎo)致無法使用，每次都需要重啟應(yīng)用才會好。那么我們就需要介入認(rèn)真排查一下問題所在了，恰巧最近一次的重啟時間為

　　11 月 10 日 18:29 左右，需要針對此問題分析 os 重啟原因。

　　測試數(shù)據(jù)庫所在的主機(jī)每個月都會重啟一至兩次，主機(jī)重啟時數(shù)據(jù)庫 alert 沒有任何日志，操作系統(tǒng)日志沒有異常信息，監(jiān)控平臺也是到每次重啟前就無法獲取到數(shù)據(jù)了，由于操作系統(tǒng)層參數(shù)配置，每次宕機(jī)都會生成 core dump。

　　cat /etc/sysctl.conf | grep core

　　kernel.core_pattern = /home/backup/crash/core-%e-円%s-%t

　　AWR 報告分析

　　因為數(shù)據(jù)庫因 os 重啟而重啟了，所以跨宕機(jī)時間點的 AWR 報告無法采集，只能采集宕機(jī)前的 AWR 報告，即 11 月 10 日

　　17:00—18：00，從這個時間段 AWR 報告來看，數(shù)據(jù)庫負(fù)載不算太高，且數(shù)據(jù)庫各指標(biāo)也都比較正常，因為這個 AWR

　　報告距離宕機(jī)時間還有半個小時，所以也無法準(zhǔn)確體現(xiàn)宕機(jī)時間點的數(shù)據(jù)庫狀態(tài)。ASH 報告分析

　　通過收集到的 ASH 信息，當(dāng)時數(shù)據(jù)庫基本上是忙于 CPU 的調(diào)度與等待，“CPU + Wait for CPU” 等待事件比較多，但想要查看進(jìn)一步的信息就沒有了。

　　數(shù)據(jù)庫日志分析

　　宕機(jī)時間點附近 alert 日志、數(shù)據(jù)庫監(jiān)聽日志均沒有異常信息打印。OSW 日志分析

　　OSWatcher 使用簡介

　　OSW 是用于采集 OS 性能指標(biāo)的工具，調(diào)用 OS 的命令，對 OS 資源的占用可以忽略不計。

　　OSW 包含兩個組件：

　　oswbb  : 一組 shell 腳本，采集 OS 的性能指標(biāo)數(shù)據(jù)。

　　oswbba : java 工具，分析 oswbb 采集的數(shù)據(jù)，提供一些建議，根據(jù)采集的數(shù)據(jù)繪制 CPU，內(nèi)存，網(wǎng)絡(luò)，I/O 的曲線圖。

　　因為在上一次宕機(jī)也就是 11 月 2 日之后我部署了 OSW 工具，現(xiàn)在就可以看看宕機(jī)前的幾分鐘 OSW 抓取到的數(shù)據(jù)，以此數(shù)據(jù)來分析宕機(jī)前 OS 狀態(tài)。

　　從宕機(jī)前收集到的 OSW 數(shù)據(jù)來看，IO 和 CPU 的使用率是比較正常的，但 free memory 只有 300M 多了，初步判斷可能和操作系統(tǒng)內(nèi)存有關(guān)。收集特定時間段的 OSW 數(shù)據(jù)

　　查看 OSW 的數(shù)據(jù)存儲位置

　　收集指定時間段的日志，例如：

　　使用 oswbba 分析 OSW

　　注意要打開圖形化

　　分析 archive 目錄下的所有 OSW 數(shù)據(jù)采集文件，并生成 HTML 報告。

　　指定時間段分析 archive 目錄下的 OSW 數(shù)據(jù)采集文件，并生成 HTML 報告。

　　打開圖形化界面然后執(zhí)行 oswbba.jar 便會生成類似于下面的 gif 圖形，通過此趨勢圖可以看到 18:28 分左右內(nèi)存和 Swap 出現(xiàn)峰值，也說明當(dāng)時內(nèi)存使用過多了。

　　參考文檔：

　　OSWatcher (Includes: [Video]) (文檔 ID 301137.1)

　　OS Watcher User’s Guide (文檔 ID 1531223.1)

　　OSWatcher Analyzer User Guide (文檔 ID 461053.1)操作系統(tǒng)日志分析

　　宕機(jī)時間點附近 /var/log/messages 中也沒有異常信息打印。

　　那么基于上面的這些信息基本上排查不到什么有用的信息了，唯一能有突破的就是前面說的每次重啟都生成的 core 文件了。我們知道在 Linux

　　系統(tǒng)中，如果進(jìn)程崩潰了，系統(tǒng)內(nèi)核會捕獲到進(jìn)程崩潰信息，然后將進(jìn)程的 coredump 信息寫入到文件中，這個文件名默認(rèn)是 core

　　。存儲位置與對應(yīng)的可執(zhí)行程序在同一目錄下，文件名是core，大家可以通過下面的命令看到 core 文件的存在位置，如下我的配置是在

　　/home/backup/crash/ 目錄下。

　　cat /proc/sys/kernel/core_pattern

　　/home/backup/crash/core-%e-円%s-%t

　　core 文件需要 gdb 命令打開分析，這里就不班門弄斧了，專業(yè)的事交給專業(yè)的人去干，通過系統(tǒng)工程師的分析，OS 所在主機(jī)的安全狗

　　watchdog 進(jìn)程夯 120 秒導(dǎo)致主機(jī)重啟。這里就要說明下為何夯 120 秒主機(jī)就會重啟，因為配置了操作系統(tǒng)參數(shù)

　　kernel.hung_task_panic = 1 導(dǎo)致主機(jī)重啟了。

　　kernel.hung_task_panic

　　操作系統(tǒng)工程師配置了這個內(nèi)核參數(shù) kernel.hung_task_panic=1 ，官方意思是如果內(nèi)核有進(jìn)程處于 D 狀態(tài)在 120s

　　內(nèi)都沒有被調(diào)度，則默認(rèn)會觸發(fā) panic，說的通俗易懂點就是配置這個參數(shù)時當(dāng)主機(jī)有進(jìn)程夯 120

　　秒時就會觸發(fā)主機(jī)重啟機(jī)制。那么問題就很明白了，每次的重啟都是由于有進(jìn)程夯了 120 秒觸發(fā)了這個參數(shù)的設(shè)置導(dǎo)致主機(jī)重啟。如果要關(guān)閉 hung

　　task panic，則可以設(shè)置內(nèi)核參數(shù) kernel.hung_task_panic=0

　　進(jìn)行關(guān)閉。所以這里呢我也就將這個參數(shù)注釋掉，默認(rèn)值就是 0。

　　系統(tǒng)工程師通過 crash 工具分析 core dump 可以看到宕機(jī)時的 os 內(nèi)存使用已經(jīng)達(dá)到了 98%，并且 swap 也已經(jīng)使用了 68%。

　　由此基本上可以看到是由于內(nèi)存耗盡導(dǎo)致重啟了。然后進(jìn)一步檢查數(shù)據(jù)庫內(nèi)存參數(shù)配置，目前此虛擬機(jī)的物理內(nèi)存為 32G，sga

　　16G，pga  4G ，沒有配置內(nèi)存大頁，數(shù)據(jù)庫參數(shù) processes 設(shè)置為 2000，pga_aggregate_limit

　　沒有值。那么在這種配置下數(shù)據(jù)庫連接數(shù)比較多的情況下，每個數(shù)據(jù)庫連接占用 3-5m 內(nèi)存多達(dá) 1000 多個鏈接的情況下在出現(xiàn)幾個排序的大

　　SQL，很容易把內(nèi)存占完。

　　通過以上的分析，基本可以確定，數(shù)據(jù)庫主機(jī)宕機(jī)的原因是內(nèi)存不足導(dǎo)致，一來操作系統(tǒng)內(nèi)存 32G 對數(shù)據(jù)庫而言沒有限制，二來數(shù)據(jù)庫存在大量連接會話，大量低效 SQL 占用大量內(nèi)存空間導(dǎo)致內(nèi)存資源不足。

　　建議：

　　1、增加主機(jī)物理內(nèi)存，從現(xiàn)在的 32G，增加至 64G；

　　2、調(diào)整 SGA 和 PGA 大小并設(shè)置 pga_aggregate_limit；

　　3、開啟內(nèi)存大頁；

　　4、在操作系統(tǒng)層面對數(shù)據(jù)庫內(nèi)存使用進(jìn)行限制；

　　5、取消內(nèi)核參數(shù) kernel.hung_task_panic

　　先調(diào)整數(shù)據(jù)庫 SGA 和 PGA 大小。參數(shù) PGA_AGGREGATE_TARGET 起到的是目標(biāo)的作用，而非限制實際 PGA

　　大小，參數(shù) PGA_AGGREGATE_LIMIT 是 12c 以后開始的新參數(shù)，可以對 PGA 的內(nèi)存使用量作“硬性規(guī)定”。如果 PGA

　　超過了 PGA_AGGREGATE_LIMIT 值，那么 Oracle 內(nèi)部按照以下順序，中斷或者終止使用了最多不可優(yōu)化的 PGA 內(nèi)存（the

　　most untunable PGA）的會話或進(jìn)程：

　　CKPT 進(jìn)程會檢查（每三秒檢查一次）并停掉使用了最多不可優(yōu)化 PGA 內(nèi)存的會話調(diào)用;

　　如果 PGA 內(nèi)存使用量仍超過 PGA_AGGREGATE_LIMIT，則 CKPT 進(jìn)程會終止使用了最多不可優(yōu)化 PGA 內(nèi)存的會話和進(jìn)程.

　　在 Oracle 12.1 的版本中會選擇以下三種情況中最大的值作為PGA_AGGREGATE_LIMIT 的值：

　　1）2 GB

　　2）PGA_AGGREGATE_TARGET 值的 2 倍

　　3）參數(shù) PROCESSES 的值 * 3MB

　　另外需要注意的是：該參數(shù)不會超過物理內(nèi)存大小減去總 SGA 大小的 120%。

　　在 18c 以后的版本中，PGA_AGGREGATE_LIMIT 的值計算方法大概是如下的公式：

　　PGA_AGGREGATE_LIMIT = (原始 PGA_AGGREGATE_LIMIT 值) + ((最大連接進(jìn)程數(shù)) * 4M)

　　所以本次調(diào)整虛擬機(jī)內(nèi)存為 64G 后，設(shè)置 SGA、PGA 參數(shù)如下：

　　然后需要開啟內(nèi)存大頁

　　vm.min_free_kbytes 這個參數(shù)可以控制預(yù)留給虛擬機(jī)多少內(nèi)存，設(shè)置的太小會出現(xiàn)死鎖，設(shè)置的過大會出現(xiàn) OOM。為了滿足

　　PF_MEMALLOC，需要一些最小的內(nèi)存分配;如果您將其設(shè)置為低于1024KB，系統(tǒng)將會變得微妙地破碎，并且在高負(fù)載下容易死鎖，設(shè)置過高會使你的機(jī)器立即

　　OOM；通常經(jīng)驗值是設(shè)置物理內(nèi)存的 2%-5% 以內(nèi)，單位是 KB，通常情況下 32G 內(nèi)存配置 2G，64G 內(nèi)存配置 5G 即

　　5242880 ，128G 內(nèi)存 10G 即可。

　　參考鏈接：https://www.kernel.org/doc/Documentation/sysctl/vm.txt

　　內(nèi)存大頁，大內(nèi)存頁，標(biāo)準(zhǔn)大頁等均是同一個東西，之前寫的《Linux 透明大頁 THP 和標(biāo)準(zhǔn)大頁 HP》一文有過詳細(xì)介紹，這里就不再介紹了。

　　memlock 參數(shù)指定用戶可以鎖定其地址空間的內(nèi)存量。在 /etc/security/limits.conf 文件中添加 memlock 的限制，一般情況下該值略微小于實際物理內(nèi)存的大小（單位為 KB）,我的物理內(nèi)存是 64GB，可以設(shè)置為如下：

　　通過以上設(shè)置后就可以關(guān)機(jī)修改內(nèi)存至 64G 然后開機(jī)檢查數(shù)據(jù)庫狀態(tài)了。

　　經(jīng)過以上設(shè)置，觀察了一個多月的時間沒有出現(xiàn)過重啟或者資源不足的情況，在此簡單記錄一下排查過程以及用到的知識點，希望以后遇到類似的問題可以參考參考，如果小伙伴們有不同意見或建議，歡迎一起交流。