一、问题描述
CPU使用率高。
二、问题现象
出现CPU使用率超过阈值，CPU使用率快速上涨或短时间持续较高水平等现象。
三、告警
CPU使用率告警。
四、业务影响
CPU使用率高集群响应变慢。
五、原因分析
1.期间业务压力增大导致。
2.出现CPU耗时较多的SQL。
六、处理方法
步骤 1：查看监控是某个节点的CPU高还是集群整体CPU高，如果是整体CPU高生成集群级别wdr报告，如果是某个节点则生成节点级wdr报告。
步骤 2：首先查看当前已有的wdr报告快照。
select * from snapshot.snapshot order
by start_ts desc;
步骤 3：生成wdr报告需要两个snapshot_id，根据需要对比的两个时间段选取对应的snapshot_id，调整输出格式，gsql界面输入：
\a \t \o + 生成文件名(html文件)
步骤 4：如果是要生成节点级的报告则执行：
select
generate_wdr_report(snapshot_id1, snapshot_id2, ‘all’, ‘node’, 节点名称)
如果要生成集群级别报告则执行
select generate_wdr_report(snapshot_id1,
snapshot_id2, ‘all’, ‘cluster’)
其中snapshot_id1和snapshot_id2按照时间从小到大的顺序写入上面分析出来的要生成报告的两个id，节点名称可以通过登录到问题节点执行show pgxc_node_name获取。
步骤 5：对应节点级别报告主要关注Top 10 Events by Total Wait Time和SQL ordered by CPU Time部分，集群级别主要关注SQL ordered by CPU Time部分，在wdr报告中搜索即可。
图片
图1-2 SQL ordered by CPU Time
步骤 6：CPU使用率较低期间的wdr报告和较高期间的wdr报告个一份，这里已节点级别为例，集群级别只需要按照SQL ordered by CPU Time部分分析，分析方式一样。
步骤 7：Top 10 Events by Total Wait Time部分包含两个快照期间的主要等待事件，可以进行大致分析是否存在大量CPU耗时较高的等待事件例如文件数据读取，快照期间主要等待事件，如果通过对比发现CPU高期间的文件读事件明显变多，则说明此期间SQL执行读取数据上上涨导致的CPU耗时上涨。如果是各项等待事件都有一定幅度上涨则可能是集群压力上涨导致，具体是那一部分SQL则需要分析SQL ordered by CPU Time部分。
步骤 8：对比两份报告SQL ordered by CPU Time部分的CPU Time(us)差异,一般对比前10个即可，这里介绍一下此部分的主要构成。
1、Unique SQL Id：对应unique_sql_id，可以通过此id去数据库查询使用此模板的SQL的其他数据，例如通过summary_statement查询总体语句的调用情况。
2、Node Name：节点名称。
3、User Name：用户名。
4、CPU Time(us)：两个快照期间的CPU耗时Calls：两个快照期间的语句调用次数。
5、Min Elapse Time(us)：SQL在内核内的最小运行时间，注意这是整体的最小解析时间不是此快照期间的最小。
6、Max Elapse Time(us)：SQL在内核内的最大运行时间，注意这是整体的最大解析时间不是此快照期间的最小。
7、Total Elapse Time(us)：两个快照期间此语句的SQL在内核内的总运行时间时间。
8、Avg Elapse Time(us)：两个快照期间此语句的SQL在内核内的平均运行时间时间。
9、Returned Rows：两个快照期间此语句的SELECT返回的结果集行数。
10、Tuples Read：两个快照期间访问的元组数量。
11、Tuples Affected：两个快照期间Insert/Update/Delete行数。
12、Logical Read：两个快照期间的逻辑读数。
13、Physical Read：两个快照期间的物理读数。
14、Data IO Time(us)：两个快照期间IO上的时间花费。
15、Sort Count：两个快照期间的排序执行的次数。
16、lSort Time(us)：两个快照期间的排序执行的时间。
17、lSort Mem Used(KB)：两个快照期间的排序过程中使用的work memory大小（单位：KB）。
18、Sort Spill Count：两个快照期间的排序过程中，若发生落盘，写文件的次数。
19、Sort Spill Size(KB)：两个快照期间的排序过程中，若发生落盘，使用的文件大小（单位：KB）。
20、Hash Count：两个快照期间的hash执行的次数。
21、Hash Time(us)：两个快照期间的hash执行的时间（单位：微秒）。
22、Hash Mem Used(KB)：两个快照期间的hash过程中使用的work memory大小（单位：KB）。
23、Hash Spill Count：两个快照期间的hash过程中，若发生落盘，写文件的次数。
24、Hash Spill Size(KB)：两个快照期间的hash过程中，若发生落盘，使用的文件大小（单位：KB）。
25、SQL Text：这里显示的SQL语句只有一部分，完整的SQL需要点击Unique SQL Id跳转到完整SQL处。
步骤 9：如果发现CPU高期间报告的CPU Time(us)前面几个的SQL明显不同且CPU耗时较大，则原因可能为CPU高耗时SQL调用量上涨导致，如果需要分析为什么此SQL的CPU耗时高则可以参考步骤11。
图片
步骤 10：如果两个报告前10个Unique SQL Id对比几乎相同，此时看SQL对应的CPU耗时和ncalls，如果calls上涨则说明是业务压力增大导致的CPU上涨，如果calls没有上涨，则需要分析为什么同一条SQL在此阶段的CPU耗时上涨，跳转步骤11。
步骤 11：在语句和调用次数没有变化的情况下，如果是查询语句看此SQL模板的Returned Rows和Physical Read，如果数量有明显增长则说明此SQL读写的数据量增大导致的CPU压力上涨，一般有两种情况，部分特殊值的情况下扫描数据量大或者计划发生改变导致扫描数据量变大。如果是写语句则可以看Tuples Affected是否有明显增加，一般读取数据比较耗CPU，如果是语句本身影响的主要围绕数据读取方面进行对比。
步骤 12：如果两个快照的数据几乎相同，可以通过火焰图或者长事务做进一步分析。
----结束
