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

理论基础

偶发性能问题分析的难点主要在于没有现场，或者现场保留的时间短，因此本类问题分析较依赖历史监控信息的保留和分析，常用工具和信息如下：

• 资源类监控信息：CPU、IO、内存、网络监控
• 业务类监控信息：gs_dbmonitor、topsql、explain performance业务探针

场景一：资源负载

某客户反馈相同的业务SQL在早上运行快，晚上运行慢。

1、查看资源监控，晚19:00-20:00后特定业务开始运行后，整体CPU水位上升到80%以上。

2、通过explain performance探针对比快慢时信息，执行计划和A-rows等信息均相同，但算子耗时全面增加。

问题原因：特定业务导致CPU负载过高，导致整体业务性能下降。

解决方案：

• 通过业务错峰调度、业务优化等手段，降低和稳定19:00-20:00期间系统的CPU水位。
• 针对CPU水位持续高的场景，若已经完成优化后CPU还居高不下，则需考虑扩充计算资源。

 同类场景：

• IO瓶颈：影响所有业务查询和写入的性能。
• 内存瓶颈：影响作业CCN排队、作业下盘、hashjoin->nestloop等。
• 网络瓶颈：影响作业中涉及节点间数据交互的stream算子效率。

场景二：业务排队

某客户场景反馈节假日期间，业务性能下降持续1hour后自动恢复。

1、首先通过资源监控排除了资源过载的情况，通过dbmonitor业务监控看到该时段出现大量waiting in global queue排队。

2、其中存在mbs_dws用户的业务从16:00开始持续上涨，到17:00左右直接突增至超过DWS集群并发上限，导致业务全局排队。

问题原因：GaussDB(DWS)中并发管控的防过载机制，当并发超过管控阈值(max_active_statements)则会排队，业务感知为性能下降。

解决方案：

• 业务侧确认异常高并发流量是否符合预期，非预期内则整改。
• 规划资源管控，将特定业务使用单独资源池管控，避免影响其他业务。

同类场景：

• CCN排队：即常见的waiting in ccn queue,表示作业在CCN排队中，包含以下场景：

        1）全局可用内存超过上限，进行全局内存队列排队。

        2）资源池慢车道并发上限，即资源池并发超过active_statements上限。

        3）资源池慢车道内存上限，即资源池并发作业估算内存超过mem_percent计算的上限。

• 资源池排队：即常见的waiting in respool queue，主要是简单作业并发超过快车道并发上限max_dop。

场景三：并发锁冲突

某客户反馈，特定业务性能抖动严重，每整点耗时突增。

1、业务情况如下，排查问题期间的CPU/IO/内存等资源平稳无异常。

2、通过dbmonitor中pgxc_lock_conflict锁监控发现存在锁冲突情况。

问题原因：业务侧定期调度ALTER TABLE增删加分区操作持锁，阻塞查询导致性能抖动。

解决方案：

• 调整ALTER TABLE调度，避免高峰期执行阻塞查询业务
• 调整将涉及ALTER表的长查询，避免和ALTER TABLE并发

除了本例中的表锁，行锁、轻量级锁等数据库中其他类型的锁也会影响业务的运行效率，可参考锁问题处理案例。

同类场景：

• 业务中定时调度的vacuum full、truncate等业务持锁阻塞查询和入库
• 系统中定时调度的autoanalyze、autovacuum阻塞ALTER等DDL操作，进而阻塞查询

这类问题的关键在于明确锁冲突链条，并通过优化业务调度和业务本身来降低锁冲突的影响。

场景四：计划跳变

某客户场景反馈夜间批量执行2hour+导致批量延迟，早上重试1min以内通过。

1、通过topsql(pgxc_wlm_session_info)查看运行快的执行计划。

2、手动explain verbose打印当前计划如下，其中b、p和bc的JOIN顺序存在明显差异，为导致性能抖动原因。

问题原因：多表关联场景，相关表对象ANALYZE不及时，导致计划跳变

解决方案：针对相关表在进行批量增删改后，及时ANALYZE（需尽量避免不及时、异步做情况）

同类场景：

• FQS在不同DN生成不同计划，如使用不同索引。
• 大表默认的采样率低，ANALYZE采样不稳定导致计划和耗时不稳定。
• PBE场景内部出现Costom Plan和Generic Plan切换，导致耗时不稳定。

这类问题主要通过ANALYZE、提高采样率ANALYZE、PLAN hint等手段稳定查询计划来解决。

场景五：缓存命中

某客户反馈，某指标查询时快时慢，导致考核指标不达标。

1、将指标查询做成explain performance探针在dbmonitor中循环执行，看到慢时慢在SCAN。

2、对比业务探针中快慢SQL的执行信息，慢SQL的buffer命中情况明显差于快的SQL。

问题原因：并发查询场景，SCAN扫描量过大导致buffer淘汰严重，查询未命中buffer场景性能下降。

解决方案：

• 优化shared_buffers、cstore_buffers参数，提升buffer效率，参考内存参数设置。
• 优化查询业务，减少大表并发查询（顺序扫描），降低buffer淘汰率。

同类场景：Disk cache命中差异（9.1.x版本后）、物化视图等。

场景六：数据差异

某客户场景反馈相同的Merge Into业务突然变慢。

1、作业运行情况如下，业务跑了100min未结束，排除了上述的资源瓶颈、排队、并发锁、计划跳变等各类情况，怀疑为数据量&数据特征变化。

2、定位到作业流程中具体慢的SQL为MERGE INTO语句，其中涉及Update和Insert语义，当匹配数据大量进入Update逻辑时会出现性能下降。

问题原因：业务表数据特征变化大，上层查询或写入量增加，导致出现性能波动。

解决办法：业务优化

同类场景：

• 业务表存在异常重复数据，导致上层join后计算结果翻倍。
• 基表数据量增加，未及时analyze，当前计划非优，无法自行调整。
• 同样的SQL，filter条件中访问到热点门店数据，导致出现性能差异。

小结

通过上述案例稍微总结下即不难发现，相同的业务性能不稳定的原因主要可分为两类：外部执行环境差异（并发、负载、排队、锁）和内部执行过程差异（数据变化、计划变化、缓存差异），处理这类问题的核心在于通过资源监控和业务监控具找到差异点，并完成对症下药。