版本信息
服務器版本:Kylin v10sp2
數據庫版本:Mogdb 2.0.1
故障現象
早起,用戶告知生產數據庫CPU使用率過高,達到了95+。簡單排查后,發現數據庫主進程占用了75%的CPU消耗,開始進入處理流程。


故障處理流程
一般導致數據庫占用CPU資源過高主要由SQL硬解析,并行,栓鎖spin,執行計劃改變等多個原因導致。碰到此類問題,首先應盡快理清數據庫當前正在運行的事務,運行的SQL,確定問題發生時間,查看數據庫日志,系統日志等明確故障成因。
1、查看數據庫當前事務,及SQL
--查看數據庫當前事務
select datname,usename,state,count(*)
from pg_stat_activity
group by datname,usename,state order by 5 desc;

--查看業務系統運行的SQL
select datname,usename,state,query,count(*)
from pg_stat_activity
where datname='xxxxx' and state='active'
group by datname,usename,state,query order by 5 desc;

可以發現生產業務正在長時間運行同一個SQL,從截圖中發現這個SQL運行了140次,而且都處在active狀態,繼續查看SQL的開始執行時間
--查看pid和SQL,開始時間
select pid,lwtid,state,query_start from pg_stat_activity a,dbe_perf.thread_wait_status s where a.pid=s.tid
and a.datname='xxxxx' and a.state='active' and a.usename='xxxxx'
order by a.query_start;

2、確定故障發生時間
使用Mogdb—export監控軟件,確定故障發生時間,在17日10點發生,17日12點,服務器CPU峰值達到峰值(沒有安裝Mogdb-export的系統可以使用sar命令對系統日志進行小時粒度的性能分析,確定問題時間點)

3、輸出故障SQL
由于在數據字典中,SQL顯示不全,可以通過設置log_min_duration_statement參數將SQL存入數據庫日志中
4、查看數據庫日志
無報錯,略
5、查看系統日志
無報錯,略
故障分析
經過以上的診斷后,基本可以確定故障點就是這個SQL了,查看SQL的執行計劃,發現存在性能瓶頸

同時通過SQL的運行時間發現一個規律,SQL每5min定時啟動運行一次,而5min卻不夠SQL執行完,形成了瀑布效應,最終形成了性能雪崩,導致服務器CPU使用率達到了95%+。
故障處理
對運行SQL的140個會話,直接kill session,釋放性能消耗(注意,如果開啟了線程池,使用pg_terminate_backen(pid)函數將無法正常的釋放事務,可以使用pg_terminate_session(pid,sessionid)替代)
--kill session
select pg_terminate_backend(pid)
from pg_stat_activity
where state = 'active' and datname='xxxxx' and usename='xxxxx';
故障總結
本次遇到的故障處理并不復雜,但是具有代表性,在發生故障時,首先需要確定問題點,在簡單判斷問題成因后,可以通過數據字典,日志,數據庫相關組件一同確定問題。如本次案例中,類似的性能問題,除了上文中提到的,還可以通過查詢判斷栓鎖,等待事件,WDR報告,stack工具等一起定位問題。
同時,清理相關的session也只是處理問題的開始,后續可能還會存在SQL調優的工作,所以盡量收集表結構,表的信息重現故障場景也是很重要的工作。本次案例中,用戶直接將SQL發給研發廠商進行處理,不涉及后續SQL調優方面內容。




