本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

数据库性能调整的主要概念

DevOpsGuru for RDS 假设你熟悉一些关键的性能概念。要了解有关这些概念的更多信息，请参阅《Amazon Aurora 用户指南》的性能见解概述或《Amazon RDS 用户指南》的性能见解概述。

指标

指标代表一个按时间顺序排列的数据点集。可将指标视为要监控的变量，而数据点代表该变量随时间变化的值。Amazon RDS 为数据库和 DB 实例所运行的操作系统 (OS) 实时提供指标。您可以在 Amazon RDS 控制台上查看 Amazon RDS 数据库实例的所有系统指标和过程信息。 DevOpsGuru for RDS 可以监控其中一些指标并提供有关这些指标的见解。有关更多信息，请参阅在 Amazon Aurora 集群中监控指标或在 Amazon 关系数据库关系实例中监控指标 。

问题检测

DevOpsGuru for RDS 使用数据库和操作系统 (OS) 指标来检测关键的数据库性能问题，无论这些问题是即将发生的还是持续的。 DevOpsGuru for RDS 问题检测主要有两种工作方式：

使用阈值检测问题

阈值是据以评估受监控指标的临界值。可以将阈值视为指标图表上的一条水平线，用于区分正常行为和可能有问题的行为。 DevOpsGuru for RDS 可监控特定指标，并通过分析哪些级别被认为对特定资源有潜在问题来创建阈值。 DevOps然后，当新的指标值在给定时间段内持续超过指定阈值时， DevOpsGuru for RDS 会在 Guru 控制台中创建见解。这些见解包含防止将来影响数据库性能的建议。

例如， DevOpsGuru for RDS 可能会在 15 分钟内监控使用磁盘的临时表的数量，并在临时表每秒使用磁盘的速率异常高时创建见解。磁盘上临时表使用量增加可能会影响数据库性能。 DevOpsGuru for RDS 通过在情况变得危急之前将其暴露出来，可以帮助您采取纠正措施来防止出现问题。

检测异常问题

虽然阈值为检测数据库问题提供了一种简单而有效的方法，但这些在某些情况下还不够。考虑这样一种情况：由于已知流程（例如每日报告任务），指标值经常激增并演变为可能存在问题的行为。由于预计会出现这样的激增，因此为每个激增创建见解和通知会适得其反，并可能导致警报疲劳。

但是，仍然有必要检测非常不寻常的激增，因为比其他指标高得多或持续时间更长的指标可能代表真正的数据库性能问题。为了解决这个问题， DevOpsGuru for RDS 会监控某些指标，以检测指标的行为何时变得非常异常或异常。 DevOps然后，Guru 在见解中报告了这些异常情况。

例如， DevOpsGuru for RDS 可能会在数据库负载不仅很高而且与其通常行为明显偏离时创建见解，这表明数据库操作出现了意想不到的严重减速。通过仅识别异常的数据库负载峰值， DevOpsGuru for RDS 可让您专注于真正重要的问题。

数据库负载

数据库调整的主要概念是数据库负载（DB 负载）指标。数据库负载表示数据库在任何给定时间的繁忙程度。数据库负载增加意味着数据库活动增加。

数据库会话表示的是应用程序与关系数据库的对话。活动会话是指正在运行数据库请求的会话。当会话在 CPU 上运行或等待资源变为可用以便继续执行时，该会话即处于活动状态。例如，活动会话可能会等待页面被读入内存，然后占用 CPU 以从页面读取数据。

性能见解中的DBLoad指标可在平均活动会话 (AAS)中衡量。为了计算 AAS，“性能见解”会对每秒的活动会话数进行采样。平均活动会话数等于活动会话总数除以特定时间段内的样本总数。AAS 值为 2 表示平均而言，在任何指定时间内请求中有 2 个会话是活动的。

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

要了解更多信息，请参阅《Amazon Aurora 用户指南》中的数据库加载或《Amazon RDS 用户指南》中的数据库加载。

等待事件

等待事件是一种数据库工具类型，它告诉您数据库会话正在等待哪个资源，以便它可以继续。当“性能见解”计算活动会话以计算数据库负载时，它还会记录导致活动会话等待的等待事件。该技术让“性能见解”可以向您显示哪些等待事件导致了数据库负载。

每个活动的会话要么会在 CPU 上运行，要么仍在等待。例如，在搜索内存寻找缓冲区、执行计算或运行过程代码时，会话都会占用 CPU。当会话不占用 CPU 时，它们可能正在等待内存缓冲区变为空闲、等待要读取的数据文件或等待将要写入的日志。会话等待资源的时间越长，它在 CPU 上运行的时间就越少。

当您优化数据库时，经常尝试找出会话正在等待的资源。例如，两三个等待事件可能会占据数据库负载的 90％。这一测量结果表明，平均而言，活动会话花费了大部分时间用于等待少量资源。如果您能找出导致这些等待的原因，就可以尝试纠正问题。

想想仓库工人的类比。收到了一个订单，内容是一本书。工人在配送订单时可能会出现延迟。例如，其他的工人目前可能正在补货架，因此手推车可能已被占用。或者用于输入订单状态的系统可能运行缓慢。工人等待的时间越长，完成订单所需的时间就越长。等待是仓库工作流程中常见的现象，但是如果等待时间过长，生产力就会降低。同样，重复或冗长的会话等待可能会降低数据库性能。

有关更多信息，请参阅《Amazon Aurora 用户指南》中的为 Aurora PostgreSQL 优化等待事件和为 Aurora MySQL 优化等待事件。

有关其他 Amazon RDS 数据库中的等待事件的更多信息，请参阅《Amazon RDS 用户指南》中的使用 RDS for PostgreSQL 的等待事件进行调整。