太平洋电脑网站,湘潭网站制作,织梦只显示网站首页,茂名模板建站定制网站在数字化系统扮演重要角色的今天#xff0c;数据库稳定性成为企业关注的核心问题。对于重要计算机系统而言#xff0c;突发的性能下降可能对业务造成不可估量的损失。为了稳定数据库性能#xff0c;用户可以从管理流程入手规范变更的测试#xff0c;或者利用产品手段减少预…在数字化系统扮演重要角色的今天数据库稳定性成为企业关注的核心问题。对于重要计算机系统而言突发的性能下降可能对业务造成不可估量的损失。为了稳定数据库性能用户可以从管理流程入手规范变更的测试或者利用产品手段减少预期外的变化。然而这仍旧无法完全规避突发的SQL性能问题其中的原因包括但不仅限于
数据量和数据分布剧烈变化从前被验证过的执行计划可能变得效率更低。数据库中的查询变得越来越复杂优化器对执行计划的选择存在不可控因素。频繁的业务更新给测试带来巨大压力未经充分验证的 SQL 有潜在的性能问题 。
对于一些对延迟非常敏感的应用而言这些潜在问题有可能对业务造成不可估量的损失。 如何降低这类不可控的突发问题对业务的影响是摆在每个管理者面前的难题。
做为资源管控的一部分TiDB 在 7.2.0 引入 Runaway Queries 管理并持续增强旨在通过系统化的手段缓解上述难题。
本文将从从适用场景、实现原理等角度详细介绍 TiDB 的 Runaway Queries 管理功能并通过一个示例展示其在系统中的作用。
什么是 Runaway Queries
Runaway Queries 是指执行时间或消耗资源超出预期的查询在运行时间和资源消耗上有显著特征。
Runaway Queries 管理旨在提供一种高效、可控、自动化的资源识别和管控机制以降低突发 SQL 性能问题带来的负面影响保护复杂工作负载下系统的稳定性让 TiDB 更加可靠。
Runaway Queries 管理适用哪些场景
● 为了保障重要系统的服务质量需要能够自动识别并处理异常 SQL 性能问题。
● 当遇到突发 SQL 性能问题但又没有立即有效的修复手段时希望临时缓解其影响。
● 当已知个别 SQL 有安全或性能问题希望加入黑名单或对其进行限流。
Runaway Queries 管理能做什么
Runaway Queries 管理主要提供两个重要能力即对查询的 “识别” 和 “处置” 。
3.1 查询的识别
TiDB 资源管控模块提供 两类 识别方式
● 动态识别 - 根据运行时规则识别 。指根据 SQL 实际运行指标自动识别 通过 resource group 定义目前支持利用 EXEC_ELAPSED 设置实际执行时间即当查询运行时间超过 EXEC_ELAPSED 的定义时这个查询会被识别为 Runaway Query。比如
ALTER RESOURCE GROUP default QUERY_LIMIT(EXEC_ELAPSED5s, ACTIONKILL);
○ 上面命令执行的效果是 属于 default 资源组的查询运行超过 5 秒钟那么这个查询会被识别为 Runaway Query。 (识别规则的生效范围为“资源组”如果你没有创建任何资源组那么可以修改 default 资源组的规则将会对全局有效。 )
○ TiDB 特意提供了每个资源组 Query Max Duration 的监控指标能够查看一段时间内运行时间最长的查询这个指标能够协助设置一个合理的 EXEC_ELAPSED .
Resource Group 的定义同时支持将识别到的 SQL 特征同时加入监控列表特定一段时间即一段时间内资源管控直接识别 SQL 特征而无需用规则识别。相当于将 SQL 放入监控名单并阶段性检查是否它已经恢复健康。
ALTER RESOURCE GROUP default QUERY_LIMIT(EXEC_ELAPSED5s, ACTIONKILL, WATCHSIMILAR DURATION10m);
○ 上述例子里我们向配置里加入了 WATCH 规则 那么和被识别成 Runaway Query 查询类似的查询比如只有过滤值不同在接下来的 10 分钟里会直接执行对应操作而不会再等待 5 秒。10 分钟之后如果这个查询的性能已经恢复则不再对其进行限制如果没有恢复则再次对这个查询监控 10 分钟。
● 静态识别 - 根据 SQL 特征识别 。自动筛选规则并不能精确的识别出所有有问题的查询因此我们加入了对监控列表的人工管理。通过 query watch 命令定义 SQL 特征识别及处置规则 能够达到数据库查询黑名单的作用。目前已支持的 SQL 特征的设置
○ SQL Text : 根据 SQL 文本做精确匹配。
○ SQL Digest : 根据 SQL Digest 匹配模式相同的查询。比如 select c from t1 where a1 和 select c from t1 where a2 拥有相同的 Digest。
○ Plan Digest : 根据 Plan Digest 匹配执行计划相同的查询。相同 SQL 可能存在多个执行计划造成性能问题的往往是其中少部分执行计划。
SQL 特征可以通过“慢查询”等方式采集这里是一个“慢查询”示例
SELECT count(1) FROM sbtest.sbtest1 AS S1 ,sbtest.sbtest2 AS S2 ,sbtest.sbtest3 AS S3 WHERE S1.cS2.c AND S1.cS3.c;
# Time: 2023-09-19T17:16:56.64043608:00
...
# Digest: d3c7846bb8f6b817ae395db30eadedec57af08f7983466f68db93d9ce1ac5872
...
# Plan_digest: 41fee801f07e06aa4aba4c0142ce4c624e8dc932c9e14d49854b8ce57366b443
用户可以根据经验选择其中一种识别方式比如下面例子里用 SQL DIGEST 子句将类似的查询加入监控队列 那么和此查询类似的查询会被识别并做出对应的处置。
mysql QUERY WATCH ADD ACTION KILL SQL DIGEST d3c7846bb8f6b817ae395db30eadedec57af08f7983466f68db93d9ce1ac5872;
Query OK, 0 rows affected (0.01 sec)
mysql SELECT * FROM INFORMATION_SCHEMA.RUNAWAY_WATCHES ORDER BY id\G
*************************** 1. row ***************************ID: 54
RESOURCE_GROUP_NAME: defaultSTART_TIME: 2023-09-20 01:59:14END_TIME: UNLIMITEDWATCH: SimilarWATCH_TEXT: d3c7846bb8f6b817ae395db30eadedec57af08f7983466f68db93d9ce1ac5872SOURCE: manualACTION: Kill
1 row in set (0.04 sec)
3.2 查询的处置
处置 指被识别到的 Runaway Queries 要如何处理。目前支持以下几个处理方式。
● DRYRUN 仅识别不做处理在日志和对应视图中显示。 初期配置的时候可以利用 DRYRUN 试运行一段时间检测是否有误判的风险。
● COOLDOWN 将查询置于资源组的最低优先级限制其处理速度。
● KILL 终止被识别的查询防止其进一步影响数据库性能。
○ 在 7.5.0 版本 COOLDOWN 在复杂场景下的限制作用有限如果对服务质量要求比较高则推荐设置 KILL
在这个例子里被识别为 Runaway Queries 的查询会被自动取消。
ALTER RESOURCE GROUP default QUERY_LIMIT(EXEC_ELAPSED5s, ACTIONKILL, WATCHSIMILAR DURATION10m);
3.3 历史记录及观测性
以上所有的设置及识别和处置的历史记录TiDB 提供了一组系统表用于查询
● INFORMATION_SCHEMA.RESOURCE_GROUPS 资源组定义包括对 Runaway Queries 识别规则和处置设置。
● INFORMATION_SCHEMA.RUNAWAY_WATCHES 监控队列中的规则。
● MYSQL.TIDB_RUNAWAY_QUERIES 记录被识别和处置的 Runaway Queries 历史记录。
运行示例 正常负载下 整体 QPS 接近 11k , P999 在 50ms 上下。出现一个异常查询每秒提交一次运行时间在 3~8 秒 QPS 从 11K 急剧下降至 3K 左右P999 由 60ms 增加到 200ms 。这时我们尝试向 default 资源组加入一条规则自动杀掉运行时间超过 1 秒的查询。QPS 回升至 7.5k P999 下降。
mysql alter resource group default QUERY_LIMIT(EXEC_ELAPSED1s, ACTIONKILL);
Query OK, 0 rows affected (1.02 sec)
mysql SELECT * FROM information_schema.resource_groups;
--------------------------------------------------------------------------------------
| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | BACKGROUND |
--------------------------------------------------------------------------------------
| default | UNLIMITED | MEDIUM | YES | EXEC_ELAPSED1s, ACTIONKILL | NULL |
--------------------------------------------------------------------------------------
1 row in set (0.01 sec)
通过系统表 mysql.tidb_runaway_queries 我们看到 Runaway 管理开始介入有问题的 SQL 被持续标记并处理。
mysql select * from mysql.tidb_runaway_queries limit 1 \G
*************************** 1. row ***************************
resource_group_name: defaulttime: 2023-09-19 15:18:10match_type: identifyaction: killoriginal_sql: SELECT count(1)FROM sbtest.sbtest1 AS S1,sbtest.sbtest2 AS S2,sbtest.sbtest3 AS S3WHERE S1.cS2.cAND S1.cS3.cplan_digest: 41fee801f07e06aa4aba4c0142ce4c624e8dc932c9e14d49854b8ce57366b443tidb_server: 127.0.0.1:4000
mysql select count(*) from mysql.tidb_runaway_queries;
----------
| count(*) |
----------
| 56 |
----------
1 row in set (0.02 sec)
这里 QPS 仍没有回升至原先的水平 因为虽然会把运行超过 1 秒的查询杀掉但每个查询仍旧都会运行 1 秒对系统仍旧造成消耗 。
修改资源组规则把符合 runaway 规则的查询的文本加入到监控列表中时长为 5 分钟。 这意味着如果文本匹配到被标记为 runaway 的查询那么会被直接杀掉不再等待 1 秒而每隔 5 分钟TiDB 会自动放开限制检查一下查询的性能是否恢复。如果恢复则不再对此查询进行取消处理 。这时系统的 QPS 和 P999 恢复到阶段 1 的水平。
mysql alter resource group default QUERY_LIMIT(EXEC_ELAPSED1s, ACTIONKILL, WATCHEXACT DURATION5m);
Query OK, 0 rows affected (0.53 sec)
mysql SELECT * FROM information_schema.resource_groups;
-------------------------------------------------------------------------------------------------------------------
| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | BACKGROUND |
-------------------------------------------------------------------------------------------------------------------
| default | UNLIMITED | MEDIUM | YES | EXEC_ELAPSED1s, ACTIONKILL, WATCHEXACT DURATION5m0s | NULL |
-------------------------------------------------------------------------------------------------------------------
1 row in set (0.00 sec)
查看视图有一条 watch 规则生成
mysql SELECT * FROM INFORMATION_SCHEMA.RUNAWAY_WATCHES ORDER BY id\G
*************************** 1. row ***************************ID: 50
RESOURCE_GROUP_NAME: defaultSTART_TIME: 2023-09-19 16:58:20END_TIME: 2023-09-19 17:03:20WATCH: ExactWATCH_TEXT: SELECT count(1)FROM sbtest.sbtest1 AS S1,sbtest.sbtest2 AS S2,sbtest.sbtest3 AS S3WHERE S1.cS2.cAND S1.cS3.cSOURCE: 127.0.0.1:4000ACTION: Kill
1 row in set (0.01 sec)
有问题的查询被执行时会直接退出告知已经被监控隔离
ERROR 8254 (HY000): Quarantined and interrupted because of being in runaway watch list
至此我们看到 通过对异常查询的自动识别和监测能够有效限制个别 SQL 的资源消耗 缓解其对整体性能的影响。
在上述示例中即使没有设置资源组对查询的自动识别在出现 SQL 性能问题时我们仍可以通过“慢日志”或者系统表找出问题查询的“特征”用 QUERY WATCH 手工将查询加入监视列表达到设置黑名单的效果。
展望
TiDB Runaway Queries 管理的一个显著优势是提升了用户体验。通过自动化和手动管理的结合用户能够更轻松地监控和控制数据库中的 Runaway Queries避免它们对正常业务的干扰。
未来 TiDB 会持续增强管理 Runaway Queries 的能力 支持更多且复杂的识别规则 增加更丰富的处理手段全面提升可观测性通过引入图形化管理的方式进一步提升用户体验 为 TiDB 迈向企业级数据库平台保驾护航。
