1       topsql的应用场景

1.1       什么是topsql

topsql是监控数据库的资源消耗情况的视图，记录的是sql级别的语句资源消耗情况，提个了实时topsql和历史topsql等系统视图。查询当前和历史数据库中语句的资源消耗情况，记录的资源包括内存，下盘大小，cpu时间，除了资源的使用情况，也记录了sql的执行状态的一些信息，包括阻塞时间、执行时间、执行状态、内存估算、异常信息、执行计划等信息。

实时topsql资源监控视图记录了查询作业运行时的资源使用情况(包括内存、下盘、CPU时间等)以及性能告警等信息。历史topsql提供了资源监控历史视图用例查询。资源监控历史视图记录了查询作业运行结束时的资源使用情况(包括内存、下盘、CPU时间等)和运行状态信息(包括报错、终止、异常等)以及性能告警等信息。

1.2       topsql有哪些应用场景

1）定位性能问题

因为topsql记录了一些语句的执行情况和资源消耗情况，在定位性能问题的时候非常有帮助，比如周期执行的sql，突然有一天变慢了，我们可以通过分析语句的执行时间和阻塞时间判断是语句被阻塞了（排队等）还是执行的慢了，通过记录的执行计划分析语句为什么慢了，是不是当时的统计信息统计不准，还是没有对表做analyze，也可以看下盘量大小分析是不是下盘量大造成的性能变慢。

2）日常调优

有时候我们需要定期的对数据库执行的sql进行维护调优，这个时候可以通过topsql获取sql的历史执行情况，比如可以按照执行时间排序，把执行时间长的语句过滤出来，看看他的执行计划是否有优化的空间，是否需要对表做一些analyze或者vacuum之类的操作。

再比如有报内存错误的情况，需要找到哪些语句占用了很多内存，可以根据内存的使用情况进行排序，看这些sql使用的内存是否合理，执行计划是否是最优等等。

3）资源配置的参考

在设置一些资源池参数的时候，比如资源池内存，资源池的下盘参数，CPU的配额限额等等资源分配的参数的时候，可以根据topsql的语句记录情况进行资源的合理分配。

2       总体介绍

GaussDB(DWS)资源监控的作业级别监控，分为实时级别监控（实时TopSQL）与历史级别监控（历史TopSQL）。实时TopSQL可以完成对于运行中的SQL进行资源监控，其可以通过查询gs_wlm_sesssion_statistics查询得到。历史TopSQL可以对运行结束之后的SQL进行监控，可以通过查询gs_wlm_session_history得到相应的资源消耗信息。整体流程如下图所示：

从流程图中可以看出，历史topsql的数据是取自实时topsql，从实时topsql中按照相关guc的设置，筛选出一部分满足条件的sql进行记录，历史topsql存储在一张表中，表中的数据根据guc的设置进行老化删除处理，其中涉及到的guc参数有

• enable_resource_track 实时topsql的总开关，关闭之后实时topsql将不再进行记录，更不会在历史topsql中出现
• resource_track_cost 记录cost值大于设定的这个cost值的query，只有运行的query的代价大于这个值才会出现在topsql的视图中
• resource_track_level 设置当前会话的资源监控的等级
• resource_track_duration 设置实时topsql中记录的语句执行结束后进行历史信息转存的最小执行时间。当执行完成的作业，其执行时间不小于此参数值时，作业信息会从实时视图（以statistics为后缀的视图）转存到相应的历史视图
• enable_resource_record 设置是否开启资源监控记录归档功能。开启时，对于执行结束的记录，会分别被归档到相应的INFO视图，cn和dn都需要设置上
• topsql_retention_time 设置历史TopSQL中gs_wlm_session_info和gs_wlm_operator_info表中数据的保存时间

3       Topsql数据流向

避免TopsQL功能的启用对数据库性能产生很大的影响，实时TopSQL（statistics后缀的）和历史TopSQL（history后缀的）是存放在内存中的临时表，分别是在语句运行时更新和运行结束时从statistics转存到history,二者都为临时表，想要长时间保存就需要进行转存操作，将history表中信息转存到info表中，默认为3分钟自动转存。
    因为TopSQL的记录范围很大，那么频繁的查询也就频繁的记录，这样也会使得info表中的数据量越来越庞大，为了影响性能，可以通过设置topsql_retention_time来规定info表中数据的保存时间。（默认为0，永久保存）

4       实时topsql

系统提供了query级别和算子级别的资源监控实时视图用来查询实时TopSQL。资源监控实时视图记录了查询作业运行时的资源使用情况（包括内存、下盘、CPU时间和IO等）以及性能告警信息，对于实时TopSQL而言，其中的资源数据的更新在这个SQL执行的过程中每10s会更新收集一次。

4.1       相关视图

Query级别

1）gs_wlm_session_statistics：该视图显示当前用户在当前CN节点正在执行的作业的负载管理记录

2）pgxc_wlm_session_statistics：所有CN上正在执行的作业的负载管理信息

算子级别

1）gs_wlm_operator_statistics：当前用户正在执行的作业的算子相关信息。

2）pgxc_wlm_operator_statistics：所有CN上正在执行作业的算子信息。

gs_session_cpu_statistics：显示和当前用户执行复杂作业正在运行时的负载管理CPU使用的信息

gs_session_memory_statistics：显示和当前用户执行复杂作业正在运行时的负载管理内存使用的信息。

pg_session_wlmstat：显示和当前用户执行作业正在运行时的负载管理相关信息

pgxc_wlm_workload_records：显示当前用户在每个CN上执行作业时在CN上的状态信息，且仅在动态负载功能开启时，即enable_dynamic_workload=on时有效。

相关视图字段解释请查看产品文档

4.2       相关注意事项

• 不记录特殊数据定义语句，如：SET、RESET、SHOW、ALTER SESSION SET、SET CONSTRAINTS语句；
• 记录数据定义语句，例如：执行CREATE、ALTER、DROP、GRANT、REVOKE和VACUUM语句；
• 记录数据操作语句，例如：
• 执行SELECT、INSERT、UPDATE和DELETE语句。
• 执行explain analyze和explain performance场景。
• 使用query级别/perf级别视图。

• 记录函数与存储过程的调用入口语句，当GUC参数enable_track_record_subsql开启的情况下，可记录存储过程的部分内部语句(declare定义语句除外)，仅会记录其中下发到DN执行的内部语句，未下发到DN执行的内部语句会被过滤掉；
• 记录匿名块语句，当GUC参数enable_track_record_subsql开启的情况下，可记录匿名块中的部分内部语句，仅会记录其中下发到DN执行的内部语句，未下发到DN执行的内部语句会被过滤掉；
• 记录游标语句，当游标并非从缓存中读取数据，而确实触发语句下发到DN上执行的条件下，该游标语句会被记录，并且会进行语句、执行计划增强，但当游标从缓存中读取数据时，不进行记录；当游标语句在匿名块或者函数中使用时，当游标从DN上读取较多数据但不完全使用时，因当前架构限制，无法记录该游标在DN上的监控信息。对于With Hold游标，该语法执行逻辑特殊，会在事务提交阶段执行实际查询动作，当语句在该阶段执行报错时，作业的aborted状态无法反馈到TopSQL历史表中。
• 重分布过程中的作业不统计；
• JDBC执行的带占位符语句，通常会补齐参数内容，但如果参数和原语句合起来长度超过64KB，则不记录参数，或者如果是轻量化语句，直接下发到DN上执行，不记录参数。

5       历史topsql

系统提供了query级别和算子级别的资源监控历史视图来查询历史TopSQL。资源监控历史视图记录了查询作业运行结束时的资源使用情况（包括内存、下盘、CPU时间、IO等）和运行状态信息（包括报错、终止、异常等）以及性能告警信息。但对于由于FATAL、PANIC错误导致查询异常结束时，状态信息列只显示aborted，无法记录详细的异常信息。这里需要开启参考手册开启相应的GUC参数。

这里以query当前CN查询为例说一下这个整体的流程，当作业执行完之后就会从实时static那个视图里存储到gs_wlm_session_history这个视图当中，默认三分钟之后数据就会转存到gs_wlm_session_info这个表中，存到数据库当中。在这里需要注意的是gs_wlm_session_history是一个视图，而gs_wlm_session_info是一个实际的表。另外在配置相关的GUC时，要注意有可能会配置的hash表大小过小导致数据存储不下的情况。

5.1       相关视图

Query级别

1）gs_wlm_session_history：当前用户在当前CN上执行作业结束后的负载管理记录。

2）gs_wlm_session_info：CN执行作业结束后的负载管理记录。

3）pgxc_wlm_session_history：在所有CN上执行作业结束后的负载管理记录。

4）pgxc_wlm_session_info：所有CN上执行作业结束后的负载管理记录。

算子级别

1）gs_wlm_operator_history：当前用户在当前CN上执行作业结束后的算子的相关记录。

2）gs_wlm_operator_info：显示执行作业结束后的算子相关的记录。

3）pgxc_wlm_operator_history：所有CN上执行作业结束时的算子信息。

4）pgxc_wlm_operator_info：在所有CN上执行作业结束时的算子信息。

相关视图字段解释请查看产品文档

5.2       历史topsql数据流转

如图1所示，在设置enable_resource_track为on，resource_track_level为query的时候，当该SQL的执行代价大于设定的resource_track_cost的时候，就可以在实时TopSQL中查到相应的SQL执行信息，当该SQL执行结束之后对于其执行时间大于resource_track_duration的SQL即可以在历史TopSQL中查询到。在设置enable_resource_record为on的时候，每过三分钟会将gs_wlm_session_history中的数据落盘存到gs_wlm_session_info中。对于存入到gs_wlm_session_info中的数据可以通过设定topsql_rentention_time对其中的数据进行老化处理。

6       推荐配置

以813版本为例，推荐topsql全开，配置如下：

enable_resource_track     on

resource_track_cost       0  新建集群默认值为0，升级场景该参数的默认值为保持前向兼容维持原值。

resource_track_level      query

resource_track_duration   0

enable_resource_record    on

topsql_retention_time     90