GaussDB(DWS)性能问题处理套路

举报
along_2020 发表于 2021/08/26 19:45:57 2021/08/26
【摘要】 在分布式场景下，导致性能问题的因素非常之多，包括但不限于硬件故障（慢盘等）、OS配置、集群故障（不均衡等）、软硬件问题（网卡加固等）、系统资源瓶颈、资源竞争、排队、重试等等。本文主要探讨对于性能问题如何快速切入，并总结出一份套路供大家参考。

对于性能问题，这边习惯将其按照范围和影响分为单点性能问题和系统级性能问题，单点性能问题大多直接转变成单SQL调优，而系统级性能问题因其复杂性往往处理起来比较费时费力，在此根据历史性能问题的处理经验总结一份套路，旨在指导大家在碰到DWS性能问题时有法可依，主要包含问卷和三阶段排查两个部分。

问卷

主要为和客户快速确认性能慢的初步信息，用来快速排除低级的非数据库服务侧的问题，并大致明确问题范围和影响：

维度 目标 确认项
where（哪里慢）
 明确是否慢在数据库侧，即服务侧
 如何统计业务执行时间
是否为DWS库内执行慢
是否涉及上下游供数
是否应用侧数据处理慢
who（都谁慢）
 明确慢的业务范围及影响
 是否单SQL慢
是否特定类SQL慢（例vacuum full）
是否实时查询慢（例报表）
是否数据入库慢（例insert）
是否所有业务慢
what（咋个慢法）
 明确性能对比基线
 与历史比
与其他集群比（例测试集群比）
与其他部署形态比（线上线下）
与其他产品比（例oracle）
与经验值比（例空表查询慢）

Why（为何变慢）
 明确是否存在显在外部变化（如有反馈变更，则主要针对变化展开分析） 是否本身为新业务
是否近期有新业务上线
是否近期业务调度发生变化
是否近期业务数据量突增
是否近期业务访问量突增（并发）
是否近期服务变更（升级、扩容、巡检等）
是否近期运行环境变更（安装服务、监控、杀毒软件等）
When（慢的时间）
 明确问题触发规律（如果为偶发、定期慢，则需部署监控、探针）
 是否一直慢
是否固定时间慢（高峰、跑批时）
是否随机偶发慢

在完成上面的问卷并明确问题范围和影响后，如果确定是整体业务性能都比历史慢且未识别出明显的业务变化，则开始后续三阶段排查。

阶段一 集群健康度

1、集群状态

集群状态异常、不均衡均会影响业务的整体运行效率，所以确定集群状态正常和均衡是整体性能稳定的首要保证。

Check项 异常值 说明 Check方法
Cluster state
 Unavailable 集群不可用影响业务整体进度 cm_ctl query –Cv
Degraded 降级的Deleted/Building状态影响集群均衡
Normal Catchup状态影响IO资源的均衡
Balanced No 主备倒换影响DN实例的均衡

 处理方式：集群修复、集群均衡（主备切换）

2、可服务性

在检查集群状态正常的情况下，还存在服务对外不可提供服务的可能，从而影响整体业务进度，最常见为某CN hang，所以通过建连、建表来快速确认CN、DN的基础可服务性。

Check项 异常值 说明 Check方法
建连（连接CN\DN） 连接hang Check 客户端连接服务是否正常 gsql连接
建表（DDL） 建表hang Check CN与CN/DN间交互是否正常 create table test_tbl(a int,b int,c varchar(100));drop table test_tbl;

 处理方式：gstack保留hang实例进程栈后，重启或隔离CN/DN进行快速恢复

3、资源瓶颈

性能问题尤其是系统级性能问题大多伴随着某类系统资源（CPU/IO/内存/网络）的瓶颈，快速检查集群的整体资源使用情况有利于快速缩小问题范围。

1、线下集群的资源使用情况使用FI Manger管理界面查看：

fim.png

2、公有云集群资源使用情况使用DWS-console管理界面查看：

dws.png

3、混合云集群资源使用情况可随机抽取CN/DN使用top/iostat/free初步排查资源使用情况。

处理方式：对整体的资源使用情况有大致的把握后继续进行后续排查，并在后续每个排查措施实施后，观察对应飙高资源是否回落。


阶段二 业务状态

1、烂SQL清理

Check项 异常值 说明 Check方法
长时间执行的业务SQL 执行时间超过阈值（根据实际场景确定，例如1h） 长时间执行的sql大多会长期占用系统资源 SELECT usename
,coorname
,now() - query_start AS runtime
,substr(query, 1, 100) AS query
,pid
,query_id
,waiting
,enqueue
FROM pgxc_stat_activity
WHERE STATE = 'active'
AND usename <> 'omm'
AND usename <> 'Ruby'
ORDER BY runtime DESC LIMIT 50;

处理方式：和客户沟通对执行时间长的sql进行查杀，观察其他业务和资源恢复情况，若恢复则进入对被查杀SQL的调优环节，否则继续进行后续排查

业务SQL查杀：https://bbs.huaweicloud.com/forum/thread-147712-1-1.html 

2、业务阻塞点

Check项 异常值 说明 Check方法
整体业务阻塞情况

1）长时间wait某个节点

2）长时间wait某类资源

 多次执行，观察是否长期停留 在wait特定对象的状态 SELECT wait_status
,wait_event
,count(*) AS cnt
FROM pgxc_thread_wait_status
WHERE wait_status <> 'wait cmd'
AND wait_status <> 'synchronize quit'
AND wait_status <> 'none'
GROUP BY 1,2
ORDER BY 3 DESC limit 50;

其中等待状态含义参见：https://support.huaweicloud.com/devg2-dws/dws_0402_0863.html

部分状态举例说明：

  • wait node：等待其他CN/DN节点，可能为慢节点
  • wait io：等待读写，可能为IO问题
  • wait pooler：等待内部建连，可能为网络问题
  • acquire lock：等锁，对相同表并发操作导致
  • acquire lwlock：等轻量级锁，并发高导致内部

问题1：针对IO、网络等资源方面的问题参考阶段三 系统状态中处理

问题2：针对LOCK的问题参考：

3、业务并发

Check项 异常值 说明 Check方法
整体并发负载情况

1）并发数长期维持高位

2）各CN上业务分布不均

执行多次，check整体负载及CN负载均衡

 SELECT usename
,coorname
,enqueue
,count(*)
FROM pgxc_stat_activity
WHERE STATE = 'active'
AND usename <> 'omm'
AND usename <> 'Ruby'
GROUP BY 1,2,3
ORDER BY 4 desc;

问题1：并发高（在前面明显的烂SQL已经清理的情况下）如伴随着cpu、内存等整体资源瓶颈，则需降低业务并发度并继续观察（并发值根据实际业务情况实测、压测最终明确）：

问题2：CN上分布不均（部分CN排队严重）

4、业务排队

Check项 异常值 说明 Check方法
业务排队 业务排队严重 多次执行，Check排队情况及持续排队的缓解情况 SELECT
,usename,
,resource_pool
,enqueue
,count(*)
FROM public.pgxc_session_wlmstat()
WHERE attribute != 'Internal'
AND enqueue != 'None'
AND status = 'pending'
GROUP BY 1,2,3
ORDER BY 4 DESC;

说明：pgxc_session_wlmstat需手动创建，请参考https://bbs.huaweicloud.com/blogs/278874

问题1：Global状态的排队多：触发全局max_active_statements阈值

问题2：Respool状态的排队多：触发资源池内存、并发限额，评估该用户使用资源合理性

  • 触发资源池内存限额
  • 触发资源池max_active_statements限额
  • 触发资源池max_dop限额(仅针对简单语句)

问题3：CentralQueue状态的排队多：触发全局内存max_dynamic_memory限制，评估内存参数设置及业务使用内存情况

其中针对Global状态排队多问题：根据资源余量情况决策是否调大max_active_statements

其中针对Respool及CentralQueue类问题参考https://bbs.huaweicloud.com/blogs/222017

阶段三 系统状态

这里所说系统状态主要指系统CPU、IO、内存、网络等系统资源使用情况，导致这些系统资源不足的场景非常之多，且之间互相影响。

Check项 Check方法 异常值
CPU top 整体或部分>80%
内存 top/free 整体或部分>70%
IO iostat/iotop >90%/长期100%
网络 ping/gsar/neststat 重传、丢包严重

1、资源高（cpu/io/mem）

1）单节点资源瓶颈

分针对DWS分布式场景，单节点资源瓶颈大多为硬件、OS故障、业务倾斜导致，主要进行以下排查：

硬件、OS侧排查重点：

  • 排查bmc日志（常见IO问题如磁盘告警、磁盘读写策略、CPU节能模式）
  • 排查messages日志（例历史上出现过的主板故障导致CPU高）

业务侧排查重点：

2）排除taishan问题

泰山服务器有已知的网卡、内存等方面问题，需排查是否做过加固：

https://support.huawei.com/enterprise/zh/bulletins-product/ENEWS2000007743

3）排除异常进程

使用top/iotop等工具明确消耗资源的进程为gaussdb进程，历史上出现过杀毒软件、ssh进程、getClientInfo进程导致CPU飙高的情况。

https://bbs.huaweicloud.com/forum/thread-74914-1-1.html

4）抓top资源业务

Top CPU消耗的业务抓取方法：

https://bbs.huaweicloud.com/forum/thread-70939-1-1.html

Top IO消耗的业务抓取方法：

https://bbs.huaweicloud.com/forum/thread-149502-1-1.html

Top内存消耗的业务抓取方法：

https://bbs.huaweicloud.com/forum/thread-110215-1-1.html

5）停业务或查杀

查杀方法：

https://bbs.huaweicloud.com/forum/thread-147712-1-1.html

6）业务整改和调优

针对单个业务导致的资源高，处理方法主要为SQL调优。

针对批量业务导致的资源高，处理方法主要为SQL调优或限并发（前提SQL已最优）。

2、网络慢

通信是分布式场景下的基础建设，承担着各节点数据交互的使命，通信效率的高低会极大影响着查询等各类业务性能的好坏。

网络慢大多体现在以下两点：

     1.客户端连接满、连接慢

     处理案例：https://bbs.huaweicloud.com/blogs/239471

     2.集群内节点建连慢、数据交互慢

  •      计划中Gather、Redistribute、Broadcast等通信算子耗时高
  •      等待视图中create conn、wait pooler等状态持续时间长

     通信性能问题处理方法及案例：https://bbs.huaweicloud.com/blogs/248843

小结

触发数据库性能问题的因素本就种类繁多，而在分布式场景更是这样，任何一个节点、环节、链路出现问题和瓶颈，都会因短板效应影响整个集群的性能，因此快速识别短板（阻塞点）、瓶颈点（系统资源）就成为关键，而前面说的三个阶段也是围绕这两个点进行。当然，也并不是所有场景都需要严格按照一二三的顺序来排查，可以根据实际情况调整排查顺序并且可能需要来回校验来互相印证，希望大家能灵活运用。

【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱： cloudbbs@huaweicloud.com
EI企业智能 Gauss AP 应用性能调优 云数据仓库 GaussDB(DWS)
  • 点赞
  • 收藏
  • 关注作者

评论（0）

0/1000
抱歉，系统识别当前为高风险访问，暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称，即可参与社区互动！

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

确认 取消

加入云驻计划，成为创作者

  • 华为云周边好礼
  • 免费体验产品
  • 特殊身份标识
  • 线下官方门票
  • 内部专家零距离
  • 与10000+优质创作者共同成长
立即加入