GaussDB(DWS) 资源监控Topsql

1 topsql的应用场景1.1 什么是topsqltopsql是监控数据库的资源消耗情况的视图记录的是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功能的启用对数据库性能产生很大的影响实时TopSQLstatistics后缀的和历史TopSQLhistory后缀的是存放在内存中的临时表分别是在语句运行时更新和运行结束时从statistics转存到history,二者都为临时表想要长时间保存就需要进行转存操作将history表中信息转存到info表中默认为3分钟自动转存。因为TopSQL的记录范围很大那么频繁的查询也就频繁的记录这样也会使得info表中的数据量越来越庞大为了影响性能可以通过设置topsql_retention_time来规定info表中数据的保存时间。默认为0永久保存4 实时topsql系统提供了query级别和算子级别的资源监控实时视图用来查询实时TopSQL。资源监控实时视图记录了查询作业运行时的资源使用情况包括内存、下盘、CPU时间和IO等以及性能告警信息对于实时TopSQL而言其中的资源数据的更新在这个SQL执行的过程中每10s会更新收集一次。4.1 相关视图Query级别1gs_wlm_session_statistics该视图显示当前用户在当前CN节点正在执行的作业的负载管理记录2pgxc_wlm_session_statistics所有CN上正在执行的作业的负载管理信息算子级别1gs_wlm_operator_statistics当前用户正在执行的作业的算子相关信息。2pgxc_wlm_operator_statistics所有CN上正在执行作业的算子信息。gs_session_cpu_statistics显示和当前用户执行复杂作业正在运行时的负载管理CPU使用的信息gs_session_memory_statistics显示和当前用户执行复杂作业正在运行时的负载管理内存使用的信息。pg_session_wlmstat显示和当前用户执行作业正在运行时的负载管理相关信息pgxc_wlm_workload_records显示当前用户在每个CN上执行作业时在CN上的状态信息且仅在动态负载功能开启时即enable_dynamic_workloadon时有效。相关视图字段解释请查看产品文档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级别1gs_wlm_session_history当前用户在当前CN上执行作业结束后的负载管理记录。2gs_wlm_session_infoCN执行作业结束后的负载管理记录。3pgxc_wlm_session_history在所有CN上执行作业结束后的负载管理记录。4pgxc_wlm_session_info所有CN上执行作业结束后的负载管理记录。算子级别1gs_wlm_operator_history当前用户在当前CN上执行作业结束后的算子的相关记录。2gs_wlm_operator_info显示执行作业结束后的算子相关的记录。3pgxc_wlm_operator_history所有CN上执行作业结束时的算子信息。4pgxc_wlm_operator_info在所有CN上执行作业结束时的算子信息。相关视图字段解释请查看产品文档5.2 历史topsql数据流转如图1所示在设置enable_resource_track为onresource_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 onresource_track_cost 0 新建集群默认值为0升级场景该参数的默认值为保持前向兼容维持原值。resource_track_level queryresource_track_duration 0enable_resource_record ontopsql_retention_time 90