苦惱的數據庫主機重啟問題排查與解決

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

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

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

　　cat /etc/sysctl.conf | grep core

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

　　AWR 報告分析

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

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

　　報告距離宕機時間還有半個小時，所以也無法準確體現宕機時間點的數據庫狀態。ASH 報告分析

　　通過收集到的 ASH 信息，當時數據庫基本上是忙于 CPU 的調度與等待，“CPU + Wait for CPU” 等待事件比較多，但想要查看進一步的信息就沒有了。

　　數據庫日志分析

　　宕機時間點附近 alert 日志、數據庫監聽日志均沒有異常信息打印。OSW 日志分析

　　OSWatcher 使用簡介

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

　　OSW 包含兩個組件：

　　oswbb  : 一組 shell 腳本，采集 OS 的性能指標數據。

　　oswbba : java 工具，分析 oswbb 采集的數據，提供一些建議，根據采集的數據繪制 CPU，內存，網絡，I/O 的曲線圖。

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

　　從宕機前收集到的 OSW 數據來看，IO 和 CPU 的使用率是比較正常的，但 free memory 只有 300M 多了，初步判斷可能和操作系統內存有關。收集特定時間段的 OSW 數據

　　查看 OSW 的數據存儲位置

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

　　使用 oswbba 分析 OSW

　　注意要打開圖形化

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

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

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

　　參考文檔：

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

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

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

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

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

　　系統中，如果進程崩潰了，系統內核會捕獲到進程崩潰信息，然后將進程的 coredump 信息寫入到文件中，這個文件名默認是 core

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

　　/home/backup/crash/ 目錄下。

　　cat /proc/sys/kernel/core_pattern

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

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

　　watchdog 進程夯 120 秒導致主機重啟。這里就要說明下為何夯 120 秒主機就會重啟，因為配置了操作系統參數

　　kernel.hung_task_panic = 1 導致主機重啟了。

　　kernel.hung_task_panic

　　操作系統工程師配置了這個內核參數 kernel.hung_task_panic=1 ，官方意思是如果內核有進程處于 D 狀態在 120s

　　內都沒有被調度，則默認會觸發 panic，說的通俗易懂點就是配置這個參數時當主機有進程夯 120

　　秒時就會觸發主機重啟機制。那么問題就很明白了，每次的重啟都是由于有進程夯了 120 秒觸發了這個參數的設置導致主機重啟。如果要關閉 hung

　　task panic，則可以設置內核參數 kernel.hung_task_panic=0

　　進行關閉。所以這里呢我也就將這個參數注釋掉，默認值就是 0。

　　系統工程師通過 crash 工具分析 core dump 可以看到宕機時的 os 內存使用已經達到了 98%，并且 swap 也已經使用了 68%。

　　由此基本上可以看到是由于內存耗盡導致重啟了。然后進一步檢查數據庫內存參數配置，目前此虛擬機的物理內存為 32G，sga

　　16G，pga  4G ，沒有配置內存大頁，數據庫參數 processes 設置為 2000，pga_aggregate_limit

　　沒有值。那么在這種配置下數據庫連接數比較多的情況下，每個數據庫連接占用 3-5m 內存多達 1000 多個鏈接的情況下在出現幾個排序的大

　　SQL，很容易把內存占完。

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

　　建議：

　　1、增加主機物理內存，從現在的 32G，增加至 64G；

　　2、調整 SGA 和 PGA 大小并設置 pga_aggregate_limit；

　　3、開啟內存大頁；

　　4、在操作系統層面對數據庫內存使用進行限制；

　　5、取消內核參數 kernel.hung_task_panic

　　先調整數據庫 SGA 和 PGA 大小。參數 PGA_AGGREGATE_TARGET 起到的是目標的作用，而非限制實際 PGA

　　大小，參數 PGA_AGGREGATE_LIMIT 是 12c 以后開始的新參數，可以對 PGA 的內存使用量作“硬性規定”。如果 PGA

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

　　most untunable PGA）的會話或進程：

　　CKPT 進程會檢查（每三秒檢查一次）并停掉使用了最多不可優化 PGA 內存的會話調用;

　　如果 PGA 內存使用量仍超過 PGA_AGGREGATE_LIMIT，則 CKPT 進程會終止使用了最多不可優化 PGA 內存的會話和進程.

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

　　1）2 GB

　　2）PGA_AGGREGATE_TARGET 值的 2 倍

　　3）參數 PROCESSES 的值 * 3MB

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

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

　　PGA_AGGREGATE_LIMIT = (原始 PGA_AGGREGATE_LIMIT 值) + ((最大連接進程數) * 4M)

　　所以本次調整虛擬機內存為 64G 后，設置 SGA、PGA 參數如下：

　　然后需要開啟內存大頁

　　vm.min_free_kbytes 這個參數可以控制預留給虛擬機多少內存，設置的太小會出現死鎖，設置的過大會出現 OOM。為了滿足

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

　　OOM；通常經驗值是設置物理內存的 2%-5% 以內，單位是 KB，通常情況下 32G 內存配置 2G，64G 內存配置 5G 即

　　5242880 ，128G 內存 10G 即可。

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

　　內存大頁，大內存頁，標準大頁等均是同一個東西，之前寫的《Linux 透明大頁 THP 和標準大頁 HP》一文有過詳細介紹，這里就不再介紹了。

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

　　通過以上設置后就可以關機修改內存至 64G 然后開機檢查數據庫狀態了。

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