PostgreSQL 在AWS的 T 系列实例上的性能陷阱
很多人刚上 AWS 时，为了节省成本，会选择：
t3 / t4g 系列实例看起来：
vCPU 多（比如 8核）
内存够用
价格便宜
于是直接用来跑 PostgreSQL 主库。
👉这是一个非常隐蔽但致命的坑。
一、典型问题现象
生产环境常见表现：
load 很高（> CPU核数） CPU 使用率 100% 数据库卡顿 pg_basebackup 很慢 checkpoint 抖动 iowait 偶尔升高甚至你会看到：
CPU 满了，但 QPS 上不去二、核心原因：T 系列 CPU 是“限速”的
以t4g.2xlarge为例：
8 vCPU baseline ≈ 40%换算：
8 × 40% = 3.2 vCPU👉 真实情况：
长期只能稳定使用 ≈ 3.2 核，而不是 8 核
三、CPU Credit：隐形限速器
T 系列依赖：
CPU Credit机制：
平时积累
使用时 burst
用完 → 限速
当 credit 用完后
CPUCreditBalance = 0👉 CPU 会被限制到：
≈ 3.2 vCPU四、为什么 load 会异常升高（重点）
很多人看到：
load = 13 CPU = 100%会误以为：
👉 CPU 不够
其实更准确是：
👉CPU 被限制，导致 load 被放大
load 的本质
load = 正在运行 + 等待CPU + 等待IO 的进程数👉 排队越多，load 越高
T 系列的“限速”不是降频（非常关键）
❌ 不是 CPU 降频
✔ 是 CPU 时间片限制（调度层）
可以理解为：
你有 8 核 但每个核只能用 40% 时间👉 等价于：
≈ 3.2 个真实 CPU举个非常直观的例子
正常实例（m6g）
任务数：8 CPU：8核👉 不排队：
load ≈ 8T 系列（credit 用完）
任务数：8 CPU：≈3.2核👉 只能跑 3.2 个：
8 - 3.2 = 4.8 在排队👉 load：
≈ 13👉 这就是你看到：
load 爆炸（13+）的真正原因
五、PostgreSQL 为什么更容易踩坑
PostgreSQL：
多进程模型（process-based）例如：
每个连接一个进程
autovacuum
walwriter
checkpointer
👉 对 CPU 非常敏感
CPU 不够会发生什么
1️⃣ 进程排队
vmstat r > CPU2️⃣ WAL 写变慢
commit 延迟上升3️⃣ checkpoint 拉长
写放大4️⃣ iowait 被误判（经典坑）
很多人看到：
iowait ↑以为是：
👉 磁盘问题
实际上：
CPU 忙 → IO处理慢 → 看起来像 IO 等待六、典型误判链路
很多团队会这样排查：
数据库慢 → 看 iowait 高 → 提升 IOPS → 问题依旧 → 怀疑 SQL → 调参数 → 还是慢👉 最终发现：
CPUCreditBalance = 0七、如何快速确认这个问题
1️⃣ AWS 指标
CPUCreditBalance = 0 CPUCreditUsage 持续高2️⃣ vmstat
vmstat 1判断：
r > vCPU id ≈ 0👉 CPU 不够
3️⃣ top
load > CPU核数4️⃣ PostgreSQL
SELECT wait_event FROM pg_stat_activity;出现：
WALWrite DataFileWrite八、真实案例（典型）
load: 13 CPU: 100% CPUCreditBalance: 0 vmstat r: 10+换算：
实际需求 ≈ 6~7 CPU 可用 ≈ 3.2 CPU👉 差距 ≈ 2倍
九、为什么 T 系列不适合 PostgreSQL
❌ 1. CPU 不稳定
burst → 限速❌ 2. IO 被 CPU 拖累
IO 看起来慢，其实是 CPU 慢❌ 3. 性能不可预测
什么时候掉速无法控制十、正确选型建议
推荐实例
| 类型 | 实例 |
|---|---|
| 通用 | m6g / m7g |
| 数据库（推荐） | r6g / r7g |
为什么 r 系列更好
内存大 → cache命中高 → IO减少十一、什么时候可以用 T 系列？
仅限：
开发环境 低 QPS 短任务 非核心业务十二、一句话总结
T 系列不是“慢 CPU”，而是“少 CPU”，因此 load 会被严重放大，而 PostgreSQL 是最容易被这种机制放大的数据库。
十三、最终建议
如果你已经看到：
load 高 + CPU 满 + credit 为 0👉 不要再调参数
👉直接换实例（m6g / r6g）