GaussDB(DWS) 全节点CPU高且无异常SQL排查方法
【版本信息】800
【问题描述】全节点CPU高
【处理方法】
首先是按照cpu高的标准处理流程进行:
https://bbs.huaweicloud.com/blogs/419012
先查看集群基本情况:
1.活跃语句100左右
2.Stream数最大10
3.Cpuwatcher脚本占CPU的语句都在40以下
4.抓进程也抓不到高CPU的进程
ps H -eo pid,tid,pcpu|sort -n -k 3 |grep master
5.语句最长执行时间1hr;有线程等待和cpu倾斜:
6.并发数60无改动
由此可以看出,长SQL,占CPU高的SQL语句都抓不到,但是全节点CPU均超过90%;定位不出具体SQL,则重新回到业务侧确认业务情况(若确认是资源不够导致cpu高的问题则此时可进行资源管控)。
7.确认实时业务为短查询高并发语句,且在CPU高时期出现大量超时告警;查询dws的超时告警设置,发现数值为0,说明告警为客户外部程序设置,执行超过时间4s触发告警,与dws无关。因此告警后语句仍然正常执行。
8.当前业务影响为实时业务查询感知慢,因此找到与实时业务一起执行的并发业务。活跃语句查询结果只找到一个非实时业务的语句,优化该语句后CPU无变化,且该语句执行时间在20分钟内。
9.此时怀疑是短查询语句自身占用的CPU高,需要做优化处理。此时让客户明确提供了实时查询并发语句,优化该表后仍然无明显变化。
查询表大小:select count(1) from 表名;
查询表数量:select count(1) from pg_class;
10. 查询实时查询的业务库的表数量,900+,全部做ANAYLZE后CPU降至20%以下:
本问题中导致CPU高的根因为业务库中的900多个表中有个别或者部分表的统计信息不完整,导致执行计划选择了更消耗CPU的执行方式,导致了CPU高;但是由于都是快查询高并发语句(执行4s即为慢语句);因此抓不到异常SQL。
【根因分析】
实时查询中有部分表统计信息不完整导致执行计划对资源占用更大,由于900+表排查困难,对业务库做统计信息收集后CPU立即恢复。
本案例中对于CPU高的现象用常规的查杀语句,资源管控的方式无法解决,因为占用CPU的语句都是短查询语句,活跃数量基本在100以内,一个语句几秒钟就执行完成,这种情况下是无法抓到单独占CPU高的SQL语句的。这种情况下需要从另一个角度解决问题,就是SQL执行慢,SQL慢的常规解决方法就是查询执行计划,收集统计信息,优化语句。本案例中,SQL慢的表象结果仅为CPU高;内存,磁盘等其他指标均正常。
- 点赞
- 收藏
- 关注作者
评论(0)