数据库负载
数据库负载(DB 负载)衡量数据库中的会话活动级别。DBLoad
是 Performance Insights 中的关键指标,Performance Insights 每秒都会收集数据库负载。
活动的会话
数据库会话表示的是应用程序与关系数据库的对话。活动的会话 是已将作业提交到数据库引擎并且正在等待响应的连接。
当会话在 CPU 上运行或等待资源变为可用以便继续执行时,该会话即处于活动状态。例如,活动的会话可能会等待页面(或块)读入内存中,然后占用 CPU 以从页面读取数据。
平均活动会话数
平均活动会话数(AAS)是 Performance Insights 中 DBLoad
指标的单位。它衡量数据库上有多少个会话同时处于活动状态。
Performance Insights 每秒都会对并行运行查询的会话数进行采样。对于每个活动的会话,Performance Insights 都会收集以下数据:
-
SQL 语句
-
会话状态(正在 CPU 上运行或正在等待)
-
Host
-
运行 SQL 的用户
Performance Insights 通过以下方式计算 AAS:对于特定时间段内,将会话总数除以样本数。例如,下表显示了正在运行的查询的 5 个连续样本,其间隔为 1 秒。
示例 | 运行查询的会话数 | AAS | 计算 |
---|---|---|---|
1 | 2 | 2 | 总计 2 个会话/1 个样本 |
2 | 0 | 1 | 总计 2 个会话/2 个样本 |
3 | 4 | 2 | 总计 6 个会话/3 个样本 |
4 | 0 | 1.5 | 总计 6 个会话/4 个样本 |
5 | 4 | 2 | 总计 10 个会话/5 个样本 |
在前面的示例中,该时间间隔的数据库负载为 2 AAS。这一测量结果表明,在采集 5 个样本的时间间隔内,在任何给定时间,平均有 2 个会话处于活动状态。
平均活动执行数
每秒的平均活动执行数 (AAE) 与平均活动会话数相关。为了计算平均活动执行数,Performance Insights 使用查询的总执行时间除以时间间隔。下表显示了上表中同一查询的平均活动执行数计算。
运行时间(秒) | 总执行时间(秒) | AAE | 计算 |
---|---|---|---|
60 | 120 | 2 | 120 秒执行时间/60 秒运行时间 |
120 | 120 | 1 | 120 秒执行时间/120 秒运行时间 |
180 | 380 | 2.1.1 | 380 秒执行时间/180 秒运行时间 |
240 | 380 | 1.58 | 380 秒执行时间/240 秒运行时间 |
300 | 600 | 2 | 600 秒执行时间/300 秒运行时间 |
在大多数情况下,查询的平均活动会话数和平均活动执行数大致相同。但是,由于计算所用的数据是不同的数据源,因此计算通常略有不同。
尺寸
db.load
指标不同于其他时间序列指标,因为您可以将它分为称为维度的子组件。您可以将维度视为 DBLoad
指标的不同特征的“切片依据”类别。
诊断性能问题时,以下维度通常最有用:
有关 Amazon RDS 引擎维度的完整列表,请参阅 按维度切片的数据库负载。
等待事件
等待事件 会导致 SQL 语句等待特定事件发生,然后才能继续运行。等待事件是数据库负载的一个重要维度(或称类别),因为它们指示了工作受阻的位置。
每个活动的会话要么会在 CPU 上运行,要么仍在等待。例如,在搜索内存寻找缓冲区、执行计算或运行过程代码时,会话都会占用 CPU。当会话不占用 CPU 时,它们可能正在等待内存缓冲区变为空闲、等待要读取的数据文件或等待将要写入的日志。会话等待资源的时间越长,它在 CPU 上运行的时间就越少。
当您优化数据库时,经常尝试找出会话正在等待的资源。例如,两三个等待事件可能会占据数据库负载的 90%。这一测量结果表明,平均而言,活动会话花费了大部分时间用于等待少量资源。如果您能找出导致这些等待的原因,就可以尝试提出解决方案了。
等待事件因数据库引擎而异:
-
有关所有 MariaDB 和 MySQL 等待事件的信息,请参阅 MySQL 文档中的等待事件摘要表
。 -
有关所有 PostgreSQL 等待事件的信息,请参阅 PostgreSQL 文档中的统计数据收集器 > 等待事件表
。 -
有关所有 Oracle 等待事件的信息,请参阅 Oracle 文档中的等待事件说明
。 -
有关所有 SQL Server 等待事件的信息,请参阅 SQL Server 文档中的等待类型
。
注意
对于 Oracle,后台进程有时在没有关联的 SQL 语句的情况下工作。在这些情况下,Performance Insights 报告以冒号连接的后台进程类型以及与该后台进程关联的等待类。后台进程类型包括 LGWR
、ARC0
、PMON
等。
例如,在存档程序执行 I/O 时,它的 Performance Insights 报告类似于 ARC1:System I/O
。有时,还会缺少后台进程类型,而 Performance Insights 仅报告等待类,例如 :System
I/O
。
主要 SQL
等待事件显示运行中的瓶颈,而主要 SQL 则显示哪些查询对数据库负载的影响最大。例如,当前可能正在数据库上运行着许多查询,但某一个查询可能会占用 99% 的数据库负载。在这种情况下,高负载可能表示查询存在问题。
默认情况下,Performance Insights 控制台会显示导致数据库负载的主要 SQL 查询。控制台还显示每个语句的相关统计信息。要诊断特定语句的性能问题,可以检查其执行计划。
计划
执行计划,也简称为计划,是访问数据的一系列步骤。例如,连接表 t1
和 t2
的计划可能会循环访问 t1
中的所有行,并将每一行与 t2
中的行进行比较。在关系数据库中,优化程序是确定 SQL 查询最有效计划的内置代码。
对于数据库实例,Performance Insights 会自动收集执行计划。要诊断 SQL 性能问题,请检查为高资源 SQL 查询捕获的计划。这些计划会显示数据库如何解析和运行查询。
要了解如何使用计划分析数据库负载,请参阅:
计划捕获
Performance Insights 每五分钟就会识别资源密集度最高的查询并捕获其计划。因此,无需手动收集和管理大量计划。相反,您可以使用 Top SQL(主要 SQL)选项卡重点关注问题最严重的查询计划。
注意
Performance Insights 不会捕获文本超过最大可收集查询文本限制的查询计划。有关更多信息,请参阅 在 Performance Insights 控制面板中访问更多 SQL 文本。
执行计划的保留期与 Performance Insights 数据的保留期相同。免费套餐中的保留设置为 Default (7 days) [原定设置(7 天)]。要将性能数据保留更长时间,请指定 1–24 个月。有关保留期的更多信息,请参阅性能详情的定价和数据留存。
摘要查询
Top SQL(主要 SQL)选项卡默认显示摘要查询。摘要查询本身没有计划,但所有使用文本值的查询都有计划。例如,摘要查询可能包括文本 WHERE `email`=?
。摘要可能包含两个查询,一个带有文本 WHERE email=user1@example.com
,另一个带有 WHERE
email=user2@example.com
。每个文本查询都可能包括多个计划。
如果选择摘要查询,控制台将显示所选摘要的子语句的所有计划。因此,无需浏览所有子语句即可查看计划。计划可能不会显示在前 10 个子语句的列表中。控制台会显示已收集计划的所有子查询计划,无论查询是否在前 10 列表中。