问题现象，问题描述：
业务反馈业务接口时延高；或者数据库P80/P95等指标升高；业务时延受损，或者业务在预期时间内无法执行完成。
通常整体慢，建议参考整体性能慢分析，逐步找到性能慢问题点。
•CPU高 •IO高 •内存高 •异常等待事件(包含并发更新) •性能抖动
整体性能慢-等待事件分析，等待事件主要分布于如下性能视图：
- dbe_perf.wait_events：内存累积视图，重启数据丢失
- pg_thread_wait_status：实时视图，当前语句等待事件
- statement_history：Full/Slow SQL语句
- dbe_perf.local_active_session/gs_asp
情况分为，持续，当前，过去某段时间
| CPU高 | IO高 | 异常等待事件 | 内存高 | |
|---|---|---|---|---|
持续 | 查询两个视图dbe_perf.statement 本CN发起的历史语句信息 dbe_perf.summary_statement 所有CN发起的历史语句信息 | 查询两个视图dbe_perf.statement/dbe_perf.summary_statement， 视图字段：n_blocks_fetched/n_blocks_hit字段，通常导致IO读高的情况，两个字段的差值会比较高，两者差值表示物理读的次数。 | ||
当前 | 查询pg_stat_activity 获取正在运行的SQL的query_id 查询pg_thread_wait_status 获取正在运行的SQL的lwtid 命令top -Hp <gaussdb进程号>，查看相应lwtid(PID)的CPU使用率 | 查询pg_thread_wait_status视图， 查询wait_status/wait_event字段，通常Query两者状态为IO_EVENT/DataFileRead表示有物理读产生。 | ||
过去某段时间 | 小时级性能抖动，可使用WDR分析； 分钟级性能抖动，可通过ASP的相关视图和表进行分析识别。ASP（Active Session Profile） 1.对于短时间秒级性能抖动，分析相应时间点的 dbe_perf.local_active_session。 | 查询视图或者表 dbe_perf.local_active_session gs_asp表 Query等待事件为: IO_EVENT/DataFileRead的记录。 | ||
查询慢SQL | 查询相应时间段的statement_history表。 | 查询statement_history表，慢SQL n_blocks_fetched/n_blocks_hit字段差值较高记录，或者查询data_io_time较高记录； |
处理方法
- •CPU高
如果CPU高是gaussdb进程导致的，通常是由于不优SQL导致，关注由于用户语句导致的CPU异常。
1.如果是持续CPU高，可查询如下两个视图，对cpu_time字段进行逆序排序即可识别。
a. dbe_perf.statement ：可查询分布式本CN发起的历史语句信息。b. dbe_perf.summary_statement ：可查询分布式所有CN发起的历史语句信息。
2.如果当前CPU高，表示正在执行的SQL语句CPU消耗较高。
a.查询pg_stat_activity获取正在运行的SQL的query_id。b.使用上一步的query_id，查询pg_thread_wait_status获取正在运行的SQL的lwtid。
c.使用操作系统命令top -Hp <gaussdb进程号>，查看相应lwtid(PID)的CPU使用率。 如果确实CPU占用较高，可能为目标SQL；本步骤假设目标SQL已运行一段时间且在几个查询SQL运行期间线程号不变。
3.如果过去某段时间内CPU高，可参考本章节性能抖动部分识别目标SQL。
4.可查询慢SQL，通常如果说语句的CPU消耗较高，慢SQL语句的cpu_time和db_time差距就较小。
a.登录至各CN/DN节点查询相应时间段的statement_history表。
b.使用全局接口dbe_perf.get_global_full_sql_by_timestamp(‘开始时间’,‘结束时间’)。注意：需要切换至postgres库。
5.如果上述步骤找到的语句，CPU消耗过高可能是间隔性的，可以使用动态接口，抓取后续执行Query的详细信息。
a.抓此SQL（unique sql id是3182919165）的FULL SQL L2。SELECT * FROM dynamic_func_control('LOCAL','STMT','TRACK','{"3182919165","L2"}');
b.取消抓取SQL（unique sql id是3182919165）。SELECT * FROM dynamic_func_control('LOCAL','STMT','UNTRACK','{"3182919165"}');
c.查看所有在抓取的SQL状态。SELECT * FROM dynamic_func_control('LOCAL','STMT','LIST','{}');
d.取消抓取所有SQL。SELECT * FROM dynamic_func_control('LOCAL','STMT','CLEAN','{}');
e.最终在动态接口命令下达后，后续有目标SQL运行的话，会记录到statement_history表内，此处一定注意：动态接口一定要评估好目标SQL的执行次数，不可长开，否则会导致statement_history表占用空间过高；使用后，记得清理动态接口内所有SQL语句。
- •IO高
通常可使用pidstat/iotop识别到导致IO高的线程，有可能是其它内核后台线程导致的IO高，比如刷WAL线程，这些场景不具有代表性，而且和特性业务场景强关，本部分仅关注由于用户语句导致的IO异常。1.如果持续IO高，可查询dbe_perf.statement/dbe_perf.summary_statement内
n_blocks_fetched/n_blocks_hit字段，通常导致IO读高的情况，两个字段的差值会比较高，两者差值表示物理读的次数。
2.如果当前IO高，可查询pg_thread_wait_status视图，
查询wait_status/wait_event字段，通常Query两者状态为IO_EVENT/DataFileRead表示有物理读产生。
3.如果过去某段时间IO高，可查询视图或者表dbe_perf.local_active_session/gs_asp中
Query等待事件为: IO_EVENT/DataFileRead的记录，具体细节可参考本章节性能抖动部分。
4.查询慢SQL内n_blocks_fetched/n_blocks_hit字段差值较高记录，或者查询data_io_time较高记录；
如果慢SQL开启了L2（请参考《开发指南》中“系统表和系统视图>系统表>STATEMENT_HISTORY”章节的details字段介绍），
details字段内相应events也会有相关events(DataFileRead)耗时显示，注意：仅在内核503.X.X版本有此能力。
解析details字段：pg_catalog.statement_detail_decode(details,'plaintext' , true)
5.使用动态接口（见•CPU高），结合4也可识别异常SQL。慢SQL内n_blocks_fetched/n_blocks_hit字段差值较高记录，或者查询data_io_time较高记录；
- •内存高
1.查询dbe_perf.memory_node_detail视图，明确内存占用点。
•max_process_memory：进程最大使用内存
•process_used_memory：进程已经使用的内存
•max_dynamic_memory：最大可使用动态内存
•dynamic_used_memory：已使用动态内存
•dynamic_used_shrctx：已使用的共享动态内存
通常仅需要关注max_dynamic_memory和dynamic_used_memory差距，如果dynamic内存不足，会导致用户查询报错，
dynamic_used_memory包含两部分内容：a.用户session上的内存消耗，比如：计划缓存、排序等。 b.内核模块的内存消耗，如：Global Sys Cache、Unique SQL等。
2.dynamic_used_shrctx较小，查询dbe_perf.session_memory_detail可获取到不同Session的内存消耗，通常来讲：用户会话数和用户每个session上内存占用都会导致动态内存异常问题。
3.dynamic_used_shrctx较大，查询dbe_perf.shared_memory_detail可获取到异常内存消耗的context，通常此处有过多的异常消耗，多数情况下为用户session上的内存异常消耗。
- •异常等待事件(包含并发更新)
异常等待事件导致的整体慢，通常需要先识别到异常等待事件，分析此等待事件是否有可能导致性能慢，然后再去想办法消减异常等待事件。1.当时性能慢
查询pg_thread_wait_status，获取当前多数会话正在等待的事件。2.过去性能慢
•过去短时间内性能慢，查询 dbe_perf.local_active_session。
•两天内的性能慢， 查询gs_asp表（postgres库内）。
3.排查异常慢SQL
•查询statement_history表内details字段（内核需要503.0.0版本及以上），需要切换至postgres库内。
•使用pg_catalog.statement_detail_decode(details, 'plaintext', true)函数解析异常events。
4.一直慢
•可排查dbe_perf.wait_events，按total_wait_time或者avg_wait_time进行逆序排序。
•识别top events，可参考整体性能慢-等待事件分析。
- •性能抖动
小时级性能抖动，可使用WDR分析；
分钟级性能抖动，可通过ASP（Active Session Profile）的相关视图和表进行分析识别。
◾ASP默认每秒采样活跃会话信息，然后存入内存（dbe_perf.local_active_session），默认内存存储10W条记录，满后按十分之一采样率下盘（gs_asp）。
◾所以理想情况下，ASP内存视图存储每秒的会话数据，物理表存储以10秒为间隔存储会话数据。
1.对于短时间秒级性能抖动，分析相应时间点的dbe_perf.local_active_session，
可排查点如下：
•异常等待事件，当时SQL的异常等待事件，可参考整体性能慢-等待事件分析。
•异常SQL，分析某些SQL出现的频率变化，以及执行速度，如多次采样均被采集到，即可反向分析到SQL执行时间。
•异常连接数变化，比如业务突然连接增加。
2.对于两天内秒级性能抖动，分析相应时间点的gs_asp表
