版本信息
服务器版本：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调优方面内容。
