GaussDB整体性能慢-视图分析

问题描述

整体性能慢。不满足客户作业对时延要求或者不满足客户预期。

问题现象

业务反馈业务接口时延高；或者数据库P80/P95等指标升高；有可能会出现大量慢SQL。

告警

1、业务侧相关接口时延、成功率等告警。

2、数据库内核P80/P95相关告警。

业务影响

业务时延受损，或者业务在预期时间内无法执行完成。

原因分析

通常整体慢，建议参考"整体性能慢分析"章节，逐步找到性能慢问题点。本章节主要描述使用性能视图分析如下原因导致的性能慢，找到问题的根因点。

1、CPU高

2、IO高

3、内存高

4、异常等待事件(包含并发更新)

5、性能抖动

处理方法

本章节描述内容聚焦在识别到影响性能相关SQL，具体SQL优化可参考1.2.1 单SQL性能慢分析。

1、CPU高

如果CPU高是gaussdb进程导致的，通常是由于不优SQL导致，本部分仅关注由于用户语句导致的CPU异常。

a.如果是持续CPU高，可查询如下两个视图，对cpu_time字段进行逆序排序即可识别。

b.如果当前CPU高，表示正在执行的SQL语句CPU消耗较高。

c.如果过去某段时间内CPU高，可参考本章节性能抖动部分识别目标SQL。

d.可查询慢SQL，通常如果说语句的CPU消耗较高，慢SQL语句的cpu_time和db_time差距就较小。

e.如果上述步骤找到的语句，CPU消耗过高可能是间隔性的，可以使用动态接口，抓取后续执行Query的详细信息。

select * fromdynamic_func_control(‘LOCAL’,‘STMT’,‘TRACK’,’{“3182919165”,“L2”}’);

select * fromdynamic_func_control(‘LOCAL’,‘STMT’,‘UNTRACK’,’{“3182919165”}’);

select * fromdynamic_func_control(‘LOCAL’,‘STMT’,‘LIST’,’{}’);

select * fromdynamic_func_control(‘LOCAL’,‘STMT’,‘CLEAN’,’{}’);

2、IO高

通常可使用pidstat/iotop识别到导致IO高的线程，有可能是其它内核后台线程导致的IO高，比如刷WAL线程，这些场景不具有代表性，而且和特性业务场景强关，本部分仅关注由于用户语句导致的IO异常。

a.如果持续IO高，可查询dbe_perf.statement/dbe_perf.summary_statement内n_blocks_fetched/n_blocks_hit字段，通常导致IO读高的情况，两个字段的差值会比较高，两者差值表示物理读的次数。

b.如果当前IO高，可查询pg_thread_wait_status视图，查询wait_status/wait_event字段，通常Query两者状态为IO_EVENT/DataFileRead表示有物理读产生。

c.如果过去某段时间IO高，可查询视图或者表dbe_perf.local_active_session/gs_asp中Query等待事件为:IO_EVENT/DataFileRead的记录，具体细节可参考本章节性能抖动部分。

d.查询慢SQL内n_blocks_fetched/n_blocks_hit字段差值较高记录，或者查询data_io_time较高记录；如果慢SQL开启了L2, details字段内相应events也会有相关events(DataFileRead)耗时显示，注意：仅在内核503版本有此能力。

解析details字段：pg_catalog.statement_detail_decode(details, ‘plaintext’, true)

e.使用动态接口（见•CPU高），结合d也可识别异常SQL。

3、内存高

本节内容仅讨论数据库内核内部内存高分析定位。

a.查询dbe_perf.memory_node_detail视图，明确内存占用点。

nmax_process_memory：进程最大使用内存

nprocess_used_memory：进程已经使用的内存

nmax_dynamic_memory：最大可使用动态内存

ndynamic_used_memory：已使用动态内存

ndynamic_used_shrctx：已使用的共享动态内存

通常我们仅需要关注max_dynamic_memory和dynamic_used_memory差距，如果dynamic内存不足，会导致用户查询报错，dynamic_used_memory包含两部分内容：

b.dynamic_used_shrctx较小，查询dbe_perf.session_memory_detail可获取到不同Session的内存消耗，通常来讲：用户会话数和用户每个session上内存占用都会导致动态内存异常问题。

c.dynamic_used_shrctx较大，查询dbe_perf.shared_memory_detail可获取到异常内存消耗的context，通常此处有过多的异常消耗，多数情况下为用户session上的内存异常消耗。

4、异常等待事件(包含并发更新)

异常等待事件导致的整体慢，通常需要先识别到异常等待事件，分析此等待事件是否有可能导致性能慢，然后再去想办法消减异常等待事件

a.当时性能慢

查询pg_thread_wait_status，获取当前多数会话正在等待的事件。

b.过去性能慢

n过去短时间内性能慢，查询dbe_perf.local_active_session。

n两天内的性能慢，查询gs_asp表（postgres库内）。

c.排查异常慢SQL

n查询statement_history表内details字段（内核需要503版本及以上），需要切换至postgres库内。

n使用pg_catalog.statement_detail_decode(details,‘plaintext’, true)函数解析异常events。

d.一直慢

n可排查dbe_perf.wait_events，按total_wait_time或者avg_wait_time进行逆序排序。

n识别top events，可参考1.2.7 整体性能慢-等待事件分析。

5、性能抖动

小时级性能抖动，可使用WDR分析；分钟级性能抖动，可通过ASP(Active Session Profile）的相关视图和表进行分析识别。

−ASP默认每秒采样活跃会话信息，然后存入内存(dbe_perf.local_active_session)，默认内存存储10W条记录，满后按十分之一采样率下盘(gs_asp)。

−所以理想情况下，ASP内存视图存储每秒的会话数据，物理表存储以10秒为间隔存储会话数据。

a.对于短时间秒级性能抖动，分析相应时间点的dbe_perf.local_active_session，可排查点如下：

b.对于两天内秒级性能抖动，分析相应时间点的gs_asp表，排查点参考a。

快速恢复

无固定快速恢复手段，同具体问题相关，有时可能要协调业务侧进行规避。