数据库负载 - Amazon Relational Database Service
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

数据库负载

数据库负载(数据库负载)衡量数据库中的活动级别。性能详情的关键指标是 DBLoad,每秒收集一次。

活动会话

数据库会话表示的是应用程序与关系数据库的对话。活动的会话 是已将作业提交到数据库引擎并且正在等待响应的连接。

当会话在 CPU 上运行或等待资源变为可用以便继续执行时,该会话即处于活动状态。例如,活动会话可能会等待页面被读入内存,然后占用 CPU 以从页面读取数据。

平均活动会话数

平均活动会话数 (AAS)是性能详情中 DBLoad 指标的单位。为了获取平均活动会话数,性能详情会对同时运行查询的会话数进行采样。平均活动会话数等于会话总数除以特定时间段内的样本总数。下表显示了正在运行的查询的 5 个连续示例。

示例 运行查询的会话数 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 个会话处于活动状态。

数据库负载可以类比成仓库中的活动。假设仓库雇用了 100 名工人。如果收到 1 个订单,则会有 1 名工人配送订单,而其他工人则继续闲置。如果收到 100 个订单,则所有 100 名工人将同时配送订单。如果您定期在给定时间段内进行抽样,了解有多少工人处于活动状态,则可以计算活动工人的平均数量。计算表明,平均而言,在任何指定时间内都会有 N 名工人忙于配送订单。如果昨天平均为 50 名工人而今天为 75 名工人,那么仓库的活动水平就会提升。同样的,数据库负载会随着会话活动的增加而增加。

平均活动执行数

每秒的平均活动执行数 (AAE) 与平均活动会话数相关。为了计算平均活动执行数,性能详情使用查询的总执行时间除以时间间隔。下表显示了上表中同一查询的平均活动执行数计算。

运行时间(秒) 总执行时间(秒) 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%。这一测量结果表明,平均而言,活动会话花费了大部分时间用于等待少量资源。如果您能找出导致这些等待的原因,就可以尝试提出解决方案了。

想想仓库工人的类比。收到了一个订单,内容是一本书。工人在配送订单时可能会出现延迟。例如,其他的工人目前可能正在补货架,因此手推车可能已被占用。或者用于输入订单状态的系统可能运行缓慢。工人等待的时间越长,完成订单所需的时间就越长。等待是仓库工作流程中常见的现象,但是如果等待时间过长,生产力就会降低。同样,重复或冗长的会话等待可能会降低数据库性能。有关更多信息,请参阅《Amazon Aurora 用户指南》中的为 Aurora PostgreSQL 优化等待事件为 Aurora MySQL 优化等待事件

等待事件因数据库引擎而异:

  • 有关所有 MariaDB 和 MySQL 等待事件的信息,请参阅 MySQL 文档中的等待事件摘要表

  • 有关所有 PostgreSQL 等待事件的信息,请参阅 PostgreSQL 文档中的 PostgreSQL 等待事件

  • 有关所有 Oracle 等待事件的信息,请参阅 Oracle 文档中的等待事件说明

  • 有关所有 SQL Server 等待事件的信息,请参阅 SQL Server 文档中的等待类型

注意

对于 Oracle,后台进程有时在没有关联的 SQL 语句的情况下工作。在这些情况下,Performance Insights 报告以冒号连接的后台进程类型以及与该后台进程关联的等待类。后台进程类型包括 LGWRARC0PMON 等。

例如,在存档程序执行 I/O 时,它的 Performance Insights 报告类似于 ARC1:System I/O。有时,还会缺少后台进程类型,而 Performance Insights 仅报告等待类,例如 :System I/O

主要 SQL

等待事件显示运行中的瓶颈,而主要 SQL 则显示哪些查询对数据库负载的影响最大。例如,当前可能正在数据库上运行着许多查询,但某一个查询可能会占用 99% 的数据库负载。在这种情况下,高负载可能表示查询存在问题。

默认情况下,Performance Insights 控制台会显示导致数据库负载的主要 SQL 查询。控制台还显示每个语句的相关统计信息。要诊断特定语句的性能问题,可以检查其执行计划。

计划

执行计划,也简称为计划,是访问数据的一系列步骤。例如,连接表 t1t2 的计划可能会循环访问 t1 中的所有行,并将每一行与 t2 中的行进行比较。在关系数据库中,优化程序是确定 SQL 查询最有效计划的内置代码。

对于 Oracle 数据库实例,Performance Insights 会自动收集执行计划。若要诊断 SQL 性能问题,请检查为高资源 Oracle SQL 查询捕获的计划。这些计划会显示 Oracle Database 如何解析和运行查询。

若要了解如何使用计划分析数据库负载,请参阅 使用 Performance Insights 控制面板分析 Oracle 执行计划

计划捕获

Performance Insights 每五分钟就会识别资源密集度最高的 Oracle 查询并捕获其计划。因此,无需手动收集和管理大量计划。相反,您可以使用 Top SQL(主要 SQL)选项卡重点关注问题最严重的查询计划。

注意

Performance Insights 不会捕获文本超过最大可收集查询文本限制的查询计划。有关更多信息,请参阅 访问 SQL 语句的文本

执行计划的保留期与所有 Performance Insights 数据的保留期相同。免费套餐默认为 7 天,长期保留套餐默认为 2 年。

摘要查询

Top SQL(主要 SQL)选项卡默认显示摘要查询。摘要查询本身没有计划,但所有使用文本值的查询都有计划。例如,摘要查询可能包括文本 WHERE `email`=?。摘要可能包含两个查询,一个带有文本 WHERE email=user1@example.com,另一个带有 WHERE email=user2@example.com。每个文本查询都可能包括多个计划。

如果选择摘要查询,控制台将显示所选摘要的子语句的所有计划。因此,无需浏览所有子语句即可查看计划。计划可能不会显示在前 10 个子语句的列表中。控制台会显示已收集计划的所有子查询计划,无论查询是否在前 10 列表中。