大家好，在上一篇文章中，我们聊了如何利用 AWS Performance Insights 揪出消耗 CPU 的“元凶”用户。许多朋友在后台问我，那个图表里的“Average Active Sessions (AAS)”到底是什么意思？为什么它比传统的 CPU利用率、IOPS 这些指标更重要？
问得好！可以说，理解了 AAS，我们就掌握了使用 Performance Insights 的精髓。今天，我们就来彻底搞懂这个让许多人感到困惑，却又无比强大的核心指标。
先抛开定义，来看一个超市收银的例子
想象一下，我们正在管理一家超市，数据库就是我们的收银台区域，而数据库的 vCPU 核心数就是我们开放的收银通道数量（比如，我们有 4 个 vCPU，就代表有 4 个收银通道）。
- 数据库连接 (Connections)：所有进入超市的顾客。有些人在闲逛（
Sleep状态），有些人则在排队结账。 - 活跃会话 (Active Sessions)：那些正在结账或正在排队等待结账的顾客。一个顾客只要离开了货架，进入了收银排队区，他就成了一个“活跃会话”。
- 平均活跃会话 (AAS)：在一段时间内（比如一分钟），收银区平均有多少顾客在排队或结账。如果这一分钟里，收银队伍的长度平均是 10 个人，那么 AAS 就是 10。
现在，我们作为超市经理，看到 AAS 为 10，同时我们知道我们只有 4 个收银通道。这意味着什么？
显而易见：我们的收银区出现了严重的瓶颈！ 队伍的长度（10）远超于我们的服务能力（4），顾客们正在经历漫长的等待。
回到数据库：AAS 的正式解读
理解了超市的比喻，我们再来看技术定义就简单多了。
AAS (Average Active Sessions) 指的是在指定时间范围内，平均有多少个数据库会话（连接）正处于“活跃”状态。
一个会话怎样才算“活跃”？很简单，只要它不是空闲的（IDLE 或 Sleep），它就是活跃的。具体来说，它可能正在：
- 使用 CPU：正在执行计算、排序、处理数据等。对应到 Performance Insights 图表里，就是那抹亮眼的绿色。
- 等待资源：它想工作，但被某些事情卡住了，无法使用 CPU。比如：
- 等待 I/O：等待从磁盘读取或写入数据页。（图表中的蓝色系）
- 等待锁 (Lock)：等待其他会话释放某个表或某行数据的锁。（图表中的红色/粉色系）
- 等待其他各种内部资源。
在 Performance Insights 的图表中，那条被称为 “数据库负载 (DB Load)” 的曲线，其数值就是 AAS。
AAS 与 “Max vCPU” 这条线的重要性
Performance Insights 中有一条非常关键的虚线，叫做 “Max vCPU”。这代表了我们数据库实例的 CPU 核心数，也就是我们的“算力天花板”，是我们超市例子中的“收银通道数量”。
解读图表的黄金法则：
- 如果 DB Load (AAS) 曲线远低于 Max vCPU 线：恭喜，数据库很健康，游刃有余。就像超市里只有一两个顾客在结账，而我们有 4 个收银台，毫无压力。
- 如果 DB Load (AAS) 曲线持续高于 Max vCPU 线：警报！我们的数据库遇到了性能瓶颈！ 这意味着等待处理的会话数量已经超过了 CPU 的处理能力。就像收银队伍的长度（AAS）超过了收银通道的数量（Max vCPU），大量的会话正在排队等待 CPU 时间。
具体示例：
假设我们的 RDS 实例是 db.m5.xlarge，它有 4 个 vCPU。那么 Max vCPU 线就在 y=4 的位置。
- 如果我们看到 AAS 为 2，其中大部分是绿色（CPU），说明平均有 2 个会话在消耗 CPU，而我们有 4 个核心，所以 CPU 利用率大约在 50% 左右，非常健康。
- 如果我们看到 AAS 飙升到 10，其中 80% 是绿色（CPU），这意味着平均有 8 个会话在激烈地争抢 4 个 CPU 核心。CPU 会 100% 跑满，并且还有大量的查询在排队，应用自然会感到卡顿。
- 如果我们看到 AAS 是 10，但大部分是蓝色（IO Wait），这意味着 CPU 可能并不忙，但有大量的会话因为等待磁盘读写而卡住了。这时我们的优化方向应该是 I/O，而不是 CPU。
为什么 AAS 是比 CPU 利用率更好的指标？
传统的 CPU 利用率（CPU Utilization）是一个结果指标。它告诉我们“CPU 很忙”，但没告诉我们“为什么忙”以及“忙不过来的程度有多严重”。
而 AAS 是一个需求指标。它不仅告诉我们数据库的负载有多高（曲线的高度），还通过不同颜色的“等待事件”告诉我们负载的构成成分（为什么慢）。它清晰地量化了“需求”（AAS）和“供给”（Max vCPU）之间的关系，让我们能一眼看出瓶颈所在。
总结
让我们把 AAS 的核心思想浓缩一下：
- AAS = 数据库负载：它衡量的是有多少会话在“排队”或“工作”。
- AAS vs. Max vCPU：将 AAS 值与我们的 CPU 核心数进行比较，是判断数据库是否存在 CPU 瓶颈最直接、最有效的方法。
- AAS 的颜色 = 瓶颈的原因：通过分析 AAS 图表中各种颜色（等待事件）的占比，我们可以精确地知道会话们都在等什么（CPU、I/O、锁等），从而找到正确的优化方向。
所以，下次当我们的数据库变慢时，别再只盯着 CPU 利用率了。打开 Performance Insights，看看 AAS 曲线，我们对问题的理解会立刻提升一个维度。
