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

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

问卷

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

|------------|----------------------------------|---------------------------|
| 维度 | 目标 | 确认项 |
| where（哪里慢） | 明确是否慢在数据库侧，即服务侧 | 如何统计业务执行时间 |
| where（哪里慢） | 明确是否慢在数据库侧，即服务侧 | 是否为DWS库内执行慢 |
| where（哪里慢） | 明确是否慢在数据库侧，即服务侧 | 是否涉及上下游供数 |
| where（哪里慢） | 明确是否慢在数据库侧，即服务侧 | 是否应用侧数据处理慢 |
| who（都谁慢） | 明确慢的业务范围及影响 | 是否单SQL慢 |
| who（都谁慢） | 明确慢的业务范围及影响 | 是否特定类SQL慢（例vacuum full） |
| who（都谁慢） | 明确慢的业务范围及影响 | 是否实时查询慢（例报表） |
| who（都谁慢） | 明确慢的业务范围及影响 | 是否数据入库慢（例insert） |
| who（都谁慢） | 明确慢的业务范围及影响 | 是否所有业务慢 |
| what（咋个慢法） | 明确性能对比基线 | 与历史比 |
| what（咋个慢法） | 明确性能对比基线 | 与其他集群比（例测试集群比） |
| what（咋个慢法） | 明确性能对比基线 | 与其他部署形态比（线上线下） |
| what（咋个慢法） | 明确性能对比基线 | 与其他产品比（例oracle） |
| what（咋个慢法） | 明确性能对比基线 | 与经验值比（例空表查询慢） |
| Why（为何变慢） | 明确是否存在显在外部变化（如有反馈变更，则主要针对变化展开分析） | 是否本身为新业务 |
| Why（为何变慢） | 明确是否存在显在外部变化（如有反馈变更，则主要针对变化展开分析） | 是否近期有新业务上线 |
| Why（为何变慢） | 明确是否存在显在外部变化（如有反馈变更，则主要针对变化展开分析） | 是否近期业务调度发生变化 |
| Why（为何变慢） | 明确是否存在显在外部变化（如有反馈变更，则主要针对变化展开分析） | 是否近期业务数据量突增 |
| Why（为何变慢） | 明确是否存在显在外部变化（如有反馈变更，则主要针对变化展开分析） | 是否近期业务访问量突增（并发） |
| Why（为何变慢） | 明确是否存在显在外部变化（如有反馈变更，则主要针对变化展开分析） | 是否近期服务变更（升级、扩容、巡检等） |
| Why（为何变慢） | 明确是否存在显在外部变化（如有反馈变更，则主要针对变化展开分析） | 是否近期运行环境变更（安装服务、监控、杀毒软件等） |
| When（慢的时间） | 明确问题触发规律（如果为偶发、定期慢，则需部署监控、探针） | 是否一直慢 |
| When（慢的时间） | 明确问题触发规律（如果为偶发、定期慢，则需部署监控、探针） | 是否固定时间慢（高峰、跑批时） |
| When（慢的时间） | 明确问题触发规律（如果为偶发、定期慢，则需部署监控、探针） | 是否随机偶发慢 |

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

阶段一集群健康度

1、集群状态

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

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

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

集群修复：https://bbs.huaweicloud.com/blogs/detail/198733
主备切换：https://bbs.huaweicloud.com/forum/thread-140502-1-1.html

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进行快速恢复

单节点重启或隔离： https://bbs.huaweicloud.com/forum/thread-147714-1-1.html
单实例重启或隔离： https://bbs.huaweicloud.com/forum/thread-147713-1-1.html
多CN隔离：https://bbs.huaweicloud.com/forum/thread-147718-1-1.html

3、资源瓶颈

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

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

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

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的问题参考：

锁等待场景：https://bbs.huaweicloud.com/blogs/233114
死锁的场景：https://bbs.huaweicloud.com/blogs/228840

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、内存等整体资源瓶颈，则需降低业务并发度并继续观察（并发值根据实际业务情况实测、压测最终明确）：

CN级并发调整(max_active_statements)：https://bbs.huaweicloud.com/blogs/179009
用户级并发调整：https://bbs.huaweicloud.com/forum/thread-74904-1-1.html

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

线下建议部署LVS：https://bbs.huaweicloud.com/forum/thread-145807-1-1.html
无法部署LVS和ELB的场景建议客户将应用业务分散到不同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高）

业务侧排查重点：

排查存储倾斜：https://bbs.huaweicloud.com/blogs/183585
排查计算倾斜：https://bbs.huaweicloud.com/blogs/254845
排查Sharding业务（分布列作为过滤条件的点查）

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

小结

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