作者：羅貴林

原文鏈接：https://mp.weixin.qq.com/s/2e5eKSoGlU9J4Rjq1zwLnw

導(dǎo)讀：在使用數(shù)據(jù)庫的過程中，內(nèi)存不足常常會引起數(shù)據(jù)庫異常。但是內(nèi)存不足，又會為數(shù)據(jù)庫帶來哪些具體的影響呢？本次，我們將通過某客戶現(xiàn)場數(shù)據(jù)庫在某個時段內(nèi)性能嚴(yán)重下降的案例來展示由于主機(jī)內(nèi)存不足而造成數(shù)據(jù)庫日志寫入卡頓的問題分析過程。通過本案例，我們也可以對相關(guān)問題的分析方法及解決建議有一些深入的了解。

問題描述

---

2020年1月15號凌晨2點(diǎn)左右客戶產(chǎn)線異常，應(yīng)用后臺消息報錯業(yè)務(wù)處理超時。此外，在16號凌晨2點(diǎn)左右和下午2點(diǎn)左右，也發(fā)生業(yè)務(wù)處理超時，影響較大。

故障時段數(shù)據(jù)庫的等待事件信息如下：

問題分析

---

查看數(shù)據(jù)庫故障時間段的ash信息，可以看到確實(shí)在1：56~1：57分的時候，等待比較嚴(yán)重：

select trunc(sample_time, 'mi'), count(1)

from gv$active_session_history

where sample_time >= to_date('2020-01-16 01:50:00', 'yyyy-mm-dd hh24:mi:ss')

and sample_time < to_date('2020-01-16 01:59:00', 'yyyy-mm-dd hh24:mi:ss')

and event is not null

group by trunc(sample_time, 'mi')

order by 1;

2. 進(jìn)一步分析等待事件，可以看到log file sync等待排名第一，而其他等待事件很少。因此主要是log filesync等待事件發(fā)了超時：

select inst_id, event, count(1)

from gv$active_session_history

where sample_time >=

to_date('2020-01-16 01:50:00', 'yyyy-mm-dd hh24:mi:ss')

and sample_time <

to_date('2020-01-16 01:58:00', 'yyyy-mm-dd hh24:mi:ss')

and event is not null

group by inst_id, event

order by 1, 3 desc;

3. 進(jìn)一步查看lgwr 的 trace，但沒有發(fā)現(xiàn)異常信息。

4. 繼續(xù)查看log file sync等待信息，可以看到都是被同一條SQL的會話阻塞。該SQL對應(yīng)的文本為insert into xxx……，是用于業(yè)務(wù)寫日志的語句，體現(xiàn)在應(yīng)用日志上就是卡在進(jìn)程剛開始的時候超時的執(zhí)行。

5. 由于告警日志和LGWR TRACE里都沒有異常信息，于是我們可以查看那條SQL的執(zhí)行情況，發(fā)現(xiàn)故障時點(diǎn)每次執(zhí)行時間變長了。

6. 繼續(xù)查詢故障時段log file sync、LGWR wait for redo copy等待事件直方圖信息。從這條insert sql執(zhí)行歷史信息，調(diào)用次數(shù)并沒有突增的情況，但是log filesync/LGWR wait for redo copy等待抖動比較嚴(yán)重：

根據(jù)故障處理經(jīng)驗(yàn)來判斷，LGWR抖動比較嚴(yán)重，懷疑物理IO出現(xiàn)了問題。

7. 分析排查物理IO問題，IO沒看到異常情況，所以在這里排除了IO引起的日志寫入抖動的問題。

8. 查詢故障時段SQL占用CPU排名的情況

而該sql_id的sql_text則是：

對故障時間點(diǎn)的ASH報告進(jìn)行分析，故障時間點(diǎn)這個select 1 from dual占用的cpu最高，這個sql一般是weblogic等中間件測試連接池連接用的，一般不會引起CPU的使用問題，且總體CPU使用率并沒有撐滿。故在這里可以排除CPU使用影響的情況，由于這套數(shù)據(jù)庫平時內(nèi)存的使用率就是98%左右，只剩2G空閑內(nèi)存，而故障時點(diǎn)，只剩幾百兆內(nèi)存。

因此，分析到這里基本可以定位是內(nèi)存消耗過高引起的問題，這里考慮到觸發(fā)故障的時間點(diǎn)有高度規(guī)律性，于是考慮可能是由于一些定時任務(wù)引起的，于是檢查了crontab，job定時任務(wù)、備份等，但都沒發(fā)現(xiàn)有故障時間的運(yùn)行的信息。

這個時候考慮數(shù)據(jù)庫主機(jī)層面上定時任務(wù)和進(jìn)程分析一些信息，由于以前出現(xiàn)故障的時候，有讓客戶開啟oswatch采集，故這次也同樣從osw中top的采樣時間進(jìn)行檢查，且最終發(fā)現(xiàn)在異常時osw的采樣時間也變長了，說明故障出現(xiàn)的時候整個操作系統(tǒng)都有受影響。

9. 查看osw中ps的信息

將osw采樣的時間加大到42秒的和正常15秒內(nèi)的兩個時間進(jìn)行比對，可以發(fā)現(xiàn)故障出現(xiàn)的事件點(diǎn)內(nèi)，多出來的一個進(jìn)程是CVU的JAVA進(jìn)程。故懷疑是cvu的java進(jìn)程對主機(jī)的內(nèi)存造成了大量的消耗。

查看cvu的運(yùn)行日志，可以看到cvu是6小時執(zhí)行一次，而在1：56和13:56的時候主機(jī)確實(shí)都運(yùn)行了這個進(jìn)程。當(dāng)然，cvu服務(wù)停用并不影響數(shù)據(jù)庫實(shí)例正常使用，只是在運(yùn)行cluvfy時有調(diào)用到，而在01:56:25~01:57:07這個中間系統(tǒng)中是卡著的，且內(nèi)存的free一直減少。

從vmstat上看，也驗(yàn)證了異常時主要是內(nèi)存問題，交換空間頁面切換和系統(tǒng)調(diào)用次數(shù)也在加大。

綜合以上的分析，可以確認(rèn)是cvu定時調(diào)用導(dǎo)致內(nèi)存消耗過大，而內(nèi)存本身就不足，在調(diào)用的那一瞬間引起了數(shù)據(jù)庫主機(jī)內(nèi)存抖動，引起了數(shù)據(jù)庫主機(jī)的卡頓，臨時處理方法是停止cvu服務(wù)，在之后的跟蹤中沒有發(fā)現(xiàn)同樣的故障發(fā)生，故障處理完成。

cvu定時任務(wù)是集群軟件調(diào)用cvu工具定時檢查集群運(yùn)行狀態(tài)，記錄到日志文件中的。它的運(yùn)行導(dǎo)致現(xiàn)有服務(wù)器內(nèi)存資源過于緊張，導(dǎo)致幾乎所有進(jìn)程都變慢。

問題解決

---

本次案例出現(xiàn)的主要原因是由于cvu定時任務(wù)進(jìn)程的調(diào)用導(dǎo)致現(xiàn)有服務(wù)器內(nèi)存資源過于緊張，引起了數(shù)據(jù)庫主機(jī)內(nèi)存抖動，造成數(shù)據(jù)庫卡頓。臨時處理方法是停止cvu服務(wù)，在之后的跟蹤中沒有發(fā)現(xiàn)同樣的故障發(fā)生，故障處理完成。

想了解更多關(guān)于數(shù)據(jù)庫、云技術(shù)的內(nèi)容嗎？

快來關(guān)注“數(shù)據(jù)和云"、"云和恩墨，"公眾號及"云和恩墨"官方網(wǎng)站，我們期待大家一同學(xué)習(xí)與進(jìn)步！

小程序”DBASK“在線問答，隨時解惑，歡迎了解和關(guān)注！

總結(jié)

以上是生活随笔為你收集整理的sql 2008服务器内存一直居高不下_经验之谈：内存问题造成数据库性能异常怎么破？...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。