数据库异常难定位?GaussDB(DWS) 运维神器 TopSQL 来解决
本文分享自华为云社区《【云驻共创】GaussDB(DWS)运维利刃:TopSQL工具解析》,作者:金鱼哥。
在生产环境中,难免会面临查询语句出现异常中断、阻塞时间长等突发问题,如果没能及时记录信息,事后就需要投入更多的人力及时间成本进行问题的定位和解决,有时还无法定位到错误出现的地方。为了解决这种场景,GaussDB(DWS)提供了强大的运维工具 TopSQL,对运行中和运行完成的语句全方面记录,帮助用户定位性能问题。而 TopSQL 被誉为性能定位、劣化分析等的重要基石,为用户提供覆盖内存、耗时、IO、网络、空间等多方面的信息记录。接下来将介绍 TopSQL 的基本原理、能力及典型应用场景,并讲解如何使用好 TopSQL 这把运维利刃。
一、TopSQL 简介
1. 什么是 TopSQL?
TopSQL 是 GaussDB(DWS)数据库中内置的一款功能十分强大的性能分析工具。在实际生产环境中,难免会出现一些突发情况,导致查询语句出现异常中断、阻塞时间长等情况,如果当时没能记录下来,那么事后就要投入更多的人力以及时间成本去对错误进行定位和解决,有时还往往定位不到错误出现的地方。
为了解决这样的窘迫的情况,GaussDB(DWS)开发了 TopSQL 功能,对运行中的语句记录(实时 TopSQL),对运行完成的语句进行记录(历史 TopSQL)。
TopSQL 作为 GaussDB(DWS)的性能诊断工具,记录 GaussDB(DWS)中各个作业、算子级别的资源使用数据、耗时数据,包括下盘信息、内存、网络、耗时、自诊断告警、基础信息等作业执行的数据。
2. 怎么实现 TopSQL 功能?
在 GaussDB 中,通过设定 GUC 参数,来开启 TopSQL 功能,由于小功能不同,那么相应的小功能的 GUC 参数也会有所区别。
大部分都是开关类型的,想要自定义场景就只需要关注传参类型的参数,以及参数之间的依赖关系即可。下一章节将介绍常用系统表和参数的设置介绍。
开启 TopSQL 功能必须要确保如下参数设置(下列参数为开启 TopSQL 功能的必要条件):
user_workload_manager = on(默认为 on)
enable_resource_track = on(默认为 on)
resource_track_level = query / perf / operator(默认为 query)若是 8.2.1.200 版本,新增一个枚举参数为 operator_realtime
二、TopSQL 系统表和参数介绍
1. 公共 GUC 参数
以 GaussDB(DWS) 8.1.3 版本为例,推荐 TopSQL 相关的一些参数,如下表所示:
TopSQL 系统表关键字段:
2. 实时 TopSQL
系统提供了 query 级别和算子级别的资源监控实时视图来用于查询实时 TopSQL。资源监控实时视图记录了查询作业运行时的资源使用情况(包括内存、下盘、CPU 时间、IO 等)以及性能告警信息。
实时视图具体的对外接口如下表所示:
开启条件
必须要确保如下 GUC 参数设置:
use_workload_manager 为 on(默认为 on)
enable_resource_track 为 on(默认为 on)
resource_track_level 为 query 或 operator(默认为 query)
监控作业类型为:
优化器估算的执行代价大于或等于 resource_track_cost 的取值的作业。
增删改查,包括使用 explain analyze 和 explain performance 来执行的场景。query 级别视图还额外支持 create table as 语法。
重分布过程中的作业不统计。
Cgroups 功能正常加载,可通过gs_cgroup -P
查看控制组信息。
use_workload_manager 为系统级参数,用于是否开启资源管理功能。enable_resource_track 为系统级参数,用于设置是否开启资源监控功能。resource_track_level 为 session 级参数,可以对某个 session 的资源监控级别进行灵活设置。
这两个参数的设置方法如下表:
3. 历史 TopSQL
系统提供了 query 级别和算子级别的资源监控历史视图用例查询历史 TopSQL。资源监控历史视图记录了查询作业运行结束时的资源使用情况(包括内存、下盘、CPU 时间、IO 等)和运行状态信息(包括报错、终止、异常等)以及性能告警信息。但对于由于 FATAL、PANIC 错误导致查询异常结束时,状态信息列只显示 aborted,无法记录详细异常信息。对于查询解析,优化阶段的状态信息则无法监控。
历史视图具体的对外接口如下表所示:
开启条件
必须要确保如下 GUC 参数设置:
use_workload_manager 为 on (默认为 on)
enable_resource_track 为 on (默认为 on)
resource_track_level 为 query 或 operator(默认为 query)
enable_resource_record 为 on(默认为 off)
resource_track_duration 小于作业执行时间(默认为 60s)
监控作业类型为:
资源监控实时视图中记录的作业结束时的执行时间大于或等于 resource_track_duration 的作业。
优化器估算的执行代价大于或等于 resource_track_cost 的取值的作业
Cgroups 功能正常加载,可通过gs_cgroup -P
查看控制组信息。该功能会引起存储空间膨胀及轻微性能影响,不建议生成系统默认使用。
三、TopSQL 典型应用场景
1. 实时 TopSQL
问题场景:某集群业务反馈某业务 SQL 偶发执行慢,该集群 resource_track_duration 设置较大,历史 TopSQL 中没有记录计划详情,需要定位原因。
处理过程:
① 系统管理员根据 queryid 查看等待视图,等待视图部分结果如下:
② 管理员执行 explain verbose,得到的执行计划如下
③ 第 8 层非 Stream 算子,说明该计划不是正在执行语句的计划,使用实时 TopSQL 查看实际计划:
2. 历史 TopSQL
问题场景:某客户由于内存规格较小,经常出现内存不可用的报错,云上运维人员通过 autopilot 定期巡检时发现该集群内存周期性冲高,且存在单实例内存使用倾斜的问题,需定位原因。
处理过程:
① 通过历史 TopSQL 找到内存占用高的语句
② 根据 unique_sql_id 确认作业的历史执行情况
3. 存储过程子语句
问题场景:某客户在业务中封装了大量的存储过程和匿名块脚本,用于业务系统的调度,随着业务数据越来越多,存储过程和匿名块脚本执行越来越慢,需要对其中的脚本进行优化。示例脚本如下:
处理过程:
① 查看历史 TopSQL,存储过程和匿名块的 query_plan 字段显示 NoPlan。
② 设置 enable_track_record_subsql: on,该参数打开后可以记录存储过程和匿名块中的自语句和执行计划。
③ 重新执行慢的存储过程,根据 query_id 查看历史 TopSQL 中各个自语句的执行计划。
四、如何通过 TopSQL 进行信息统计
1. 常用 TopSQL 进行业务信息统计
① 识别 stream 数量多的语句:
② 识别内存占用高的语句:
③ 识别需要优化的语句:
2. TopSQL 使用注意事项
① 查询时使用 start_time 做条件,避免全表查询。
② 查询时使用 limit 对结果集大小限制,防止结果集过大导致客户端 OOM。
总结
GaussDB 具备将瞬息万变的负载情况记录下来,提供回看数据库系统内部资源负载情况的能力,方便管理员对已经发生的问题做定位定界。
TopSQL 收集的数据来源于数据库内部,为用户提供了实时监控数据库的能力。
TopSQL 功能被用户广泛使用,是性能定位、劣化分析、审计回溯等重要的基石,为用户提供覆盖内存、耗时、IO、网络、空间等多方面的监控能力。在此基础上,内核也拓展出了异常规则等一些高阶用法,在日常使用中,用户可对 TopSQL 提出了更高的要求,比如记录子语句、记录语句类型、提升算子级别语句监控准确性等诸多建议。
版权声明: 本文为 InfoQ 作者【华为云开发者联盟】的原创文章。
原文链接:【http://xie.infoq.cn/article/0ddb8e99c72fd1c823ab1d6d4】。文章转载请联系作者。
评论