带你掌握数仓的作业级监控 TopSQL
本文分享自华为云社区《GaussDB(DWS)监控工具指南(一)作业级监控TopSQL》,作者:幕后小黑爪 。
1、引言:
监控系统是智能化管理和自动化运维的基石,可以为资源规划,故障排查,性能优化提供至关重要的数据支持。GaussDB(DWS)作为企业级数仓,为用户提供了一整套覆盖实例级、用户级、作业级的资源监控能力,其中,作业级监控(下文统称为 TopSQL)主要是对运行作业的监控,包括了实时运行作业的相关信息,历史运行作业的相关信息等。它收集的数据来源于数据库内部,为用户提供了实时监控数据库的能力。
目前 TopSQL 功能被用户广泛使用,是性能定位、劣化分析、审计回溯等重要的基石,为用户提供覆盖内存、耗时、IO、网络、空间等多方面的监控能力。
本文以数仓 813 版本作为基线,对 TopSQL 进行介绍。
2、TopSQL 功能介绍
对于用户而言,数据库是个黑盒,输入 SQL 语句,输出预期结果。在此过程中,用户关心两点:
输出结果是否符合预期;
语句要多久跑完。
关于第一个问题,用户需要关注下 SQL 语句写的是否合理。而对于第二个问题,普通用户可以通过 explain 等手段分析作业的执行计划,然而企业用户的 SQL 作业耗时久,影响较大,重跑代价较高,无法额外通过 explain performance 等手段进行分析,此时 TopSQL 可以帮助用户打开数据库黑盒,查看作业执行的实时情况和历史情况,便于用户分析数据库的情况。
TopSQL 功能主要通过视图进行承载,如下表所示,本文以 query 级别的视图为例进行说明。
使用 TopSQL 功能需要 sysadmin 权限。此外,用户需先检查下 TopSQL 功能是否开启,涉及 TopSQL 的数据库 GUC 参数包括:
ENABLE_RESOURCE_TRACK (ON)
是否开启监控功能,实时 TopSQL 的总开关,关闭之后实时 TopSQL 将不再进行记录,更不会在历史 TopSQL 中出现。
RESOURCE_TRACK_COST(0)
设置对当前会话的语句进行资源监控的最小执行代价。
RESOURCE_TRACK_LEVEL(QUERY)
设置当前会话的资源监控的等级,默认为 query 级别。
RESOURCE_TRACK_DURATION(60S)
设置实时 TopSQL 中记录的语句执行结束后进行历史信息转存的最小执行时间。当执行完成的作业,其执行时间不小于此参数值时,作业信息会从实时视图(以 STATISTICS 为后缀的视图)转存到相应的历史视图
ENABLE_RESOURCE_RECORD(ON)
设置是否开启资源监控记录归档功能。开启时,对于执行结束的记录,会分别被归档到相应的 INFO 视图,CN 和 DN 都需要设置上。
TOPSQL_RETENTION_TIME(30)
设置历史 TopSQL 中 GS_WLM_SESSION_INFO 和 GS_WLM_OPERATOR_INFO 表中数据的保存时间,单位为天。
参数正确设置后,TopSQL 会记录用户的 SQL 语句执行过程中的相关信息,用户可以使用 TopSQL 的视图筛选出执行时间较长的作业,专注于慢 SQL 的分析。
TopSQL 功能分为实时 TopSQL 和历史 TopSQL,以 query 级别为例,当需要查看正在运行的作业时,用户可查看实时 TopSQL 视图 GS_WLM_SESSION_STATISTICS 和 PGXC_WLM_SESSION_STATISTICS,若需要对已经执行完成的作业进行分析,可查询历史 TopSQL 视图 GS_WLM_SESSION_ HISTORY 和 PGXC_WLM_SESSION_ HISTORY。其中 GS_开头的可以查询当前 CN 节点上正在执行的作业信息,PGXC_开头的可查询所有 CN 节点上正在执行的作业信息。
实时 TopSQL 视图为用户记录了作业运行时的相关信息,比如作业下发来源、阻塞时间、执行时长、开始时间、内存消耗、作业下盘量、作业 IO、网络、语句类型、语句的执行计划等信息。用户可先通过 resource_pool、nodename、username、query 等信息定位到自己需要分析的语句,再通过作业运行信息定位问题。又或者用户可通过对查询进行筛选,筛选出当前占用资源较多的作业。
历史 TopSQL 视图记录了作业运行结束时的资源使用情况(包括内存、下盘、CPU 时间等)和运行状态信息(包括报错、终止、异常等)以及性能告警信息。用户可通过对历史语句运行数据的分析,筛选出执行时长较大的语句,看语句执行计划是否有优化的空间,是否需要对表做一些 analyze 或者 vacuum 之类的操作。又比如对于内存报错的情况,可分析内存占用高的语句是否合理,从执行计划上分析是否有优化空间。
文末附 TopSQL 实践:常见问题现象及对应原因。
3、TopSQL 的原理解析
3.1 TopSQL 原理简介:
TopSQL 的数据来源于数据库内核,当语句执行时,TopSQL 会实时记录语句执行的相关信息。实时 TopSQL 数据会保存在内存的临时表中,当语句执行结束后,数据会转存到对应实体表 GS_WLM_SESSION_INFO 中,在实际使用中,由于下发作业繁多,历史 TopSQL 记录的作业数也不断增长,这样会导致 INFO 表中的数据量逐渐庞大,为了确保数仓整体性能不受影响,支持通过 TOPSQL_RETENTION_TIME 来设置 INFO 表中数据的保存时间(单位为天)。当数据存留时长超过这个时限,会对实体表 GS_WLM_SESSION_INFO 进行数据老化删除处理。
图 3-1 TopSQL 数据流通图
如图 3-1 所示,各项 GUC 参数决定了 TopSQL 生成的记录信息,具体的参数说明详见第 2 节使用 TopSQL 前的检验。
3.2 性能分析:
对于企业用户而言,性能问题是 Top 级问题,对于 TopSQL 功能,我们进行了性能压测,在 4TB 的场景下,进行 TPCC 基准性能测试,进行了 2000 的并发压测,TPMC 下降了约有 2%,属于可接受的范围。
3.3 相关指标
语句属性列说明:
语句的执行信息属性列,斜体代表可更换前缀/后缀式的指标,类似前缀后缀有(min_,max_,total_,average_,_skew_percent)
3.4 特殊情况说明:
TopSQL 由于自身限制,存在一些记录异常的情况,此处对 8.1.3 版本的 TopSQL 语句记录情况进行说明:
不记录特殊数据定义语句,如:SET、RESET、SHOW、ALTER SESSION SET、SET CONSTRAINTS 语句;
记录数据定义语句,例如:执行 CREATE、ALTER、DROP、GRANT、REVOKE 和 VACUUM 语句;
记录数据操作语句,例如:执行 SELECT、INSERT、UPDATE 和 DELETE 语句。执行 explain analyze 和 explain performance 场景。执行查询 query 级别/perf 级别视图
ODBC 下发作业,由于多语句原因,会记录事务的 BEGIN 和 end 语句;
JDBC 下发作业,随机性多记录一条 JDBC 的内部语句
解析错误和语法报错的异常不记录
用户手动 CANCEL 作业,显示的监控数据可能为 0;
当子语句开关打开后,只会记录下发到 DN 上执行的子语句;
游标语句,当游标并非从缓存中读取数据,而确实触发语句下发到 DN 上执行的条件下,该游标语句会被记录,并且会进行语句、执行计划增强,但当游标从缓存中读取数据时,不进行记录;当游标语句在匿名块或者函数中使用时,当游标从 DN 上读取较多数据但不完全使用时,无法记录该游标在 DN 上的监控信息。
JDBC 执行的带占位符语句,通常会补齐参数内容,但如果参数和原语句合起来长度超过 64KB,则不记录参数,或者如果是轻量化语句,直接下发到 DN 上执行,不记录参数。
4、TopSQL 扩展及应用
TopSQL 功能是 GaussDB(DWS)支持性能问题定位、语句劣化分析、审计回溯等重要功能的基石。在此基础上,内核也拓展出了异常规则等一些高阶用法,在日常使用中,用户也对 TopSQL 提出了更高的要求,比如记录子语句、记录语句类型、提升算子级别语句监控准确性等诸多建议。为此,GaussDB(DWS)团队会在此基础上继续演进,更好的服务用户,提升用户满意度。
5、TopSQL 实践:常见问题定位
总结一下:
因数据量变化,导致作业执行时间增加,可以分析 A2/B1/D1/G1,进而确认作业查询的数据表是否有明显的数据量增加;
因其它并发作业抢占,导致作业排队,从而导致作业执行时间增加,可以分析 A1/B1/D1,进而查看作业执行的同时期是否有大量并发作业在执行;
因其它作业而产生的 CPU 抢占,导致作业执行时间增加,可以分析 A2/D1/E1,进而查看作业执行的同时期是否有大量并发作业在执行;
因其它作业而产生的 IO 抢占,导致作业执行时间增加,可以分析 A2/F1,进而查看作业执行的同时期是否有大量并发作业在执行;
I1 中有结果情况,可通过提示的信息进行分析,或者进行 SQL 自适应诊断相关告警处理,SQL 自适应诊断处理方法见:https://support.huaweicloud.com/performance-dws/dws_10_0013.html
对于 enqueue 异常排队的情况 H1,用户可参考:GaussDB(DWS)资源管理排队原理与问题定位-云社区-华为云 (huaweicloud.com),进行问题排查分析。
值得注意的是,发生资源争抢时,可能会出现并发症,即 CPU、IO 抢占,作业排队现象都会发生,针对并发症问题,可以逐步分析解决,比如:
第一步,调整作业执行顺序,减少并发作业数量,减少阻塞时间;
第二步,定位出同时段执行的典型计算密集型、存储密集型作业,先移动到其它时间段执行,减少对本作业的影响;
第三步,在无其他作业明显干预的情况下,做进一步分析,
6、参考文献:
版权声明: 本文为 InfoQ 作者【华为云开发者联盟】的原创文章。
原文链接:【http://xie.infoq.cn/article/781f26b4fc27c4c1bdb37996a】。文章转载请联系作者。
评论