裸金属 vs. AWS RDS：深入探讨 NUMA 感知调优与 PostgreSQL 性能
Source: Dev.to
请提供您希望翻译的正文内容，我将按照要求保留源链接并翻译其余部分。
设置：32‑核 NUMA‑感知机器
为了保持比较公平，所有环境（裸金属 vs 云）都分配了 2 vCPU / 8 GB RAM。
然而，底层的“金属”存在根本差异。我们的裸金属节点是一台强大的机器：
| 特性 | 描述 |
|---|---|
| CPU | 32 核（16 物理 + 16 超线程） |
| 架构 | NUMA‑感知 |
| 存储 | 本地 SSD （SAS） |
不同于在带有“噪声邻居”的 hypervisor 上运行的云 VM（t3.large），我们的裸金属主机让 PostgreSQL 进程直接与物理核心和专用内存银行通信。这就是为什么 裸金属上的 2 vCPU ≠ 云上的 2 vCPU。
测试配置
| 标签 | 描述 |
|---|---|
| CNPG Local ① | CloudNativePG，local-path 存储，默认调优 |
| CNPG Local ② | 同一集群，work_mem + 连接数调优 |
| CNPG Local ③ | 同一集群，shared_buffers 最大化 |
| CNPG Longhorn | CloudNativePG，Longhorn 分布式存储 |
| RDS Standard | AWS RDS PostgreSQL 17.6，t3.large |
| Aurora IO‑Opt | AWS Aurora PostgreSQL 17.4，I/O‑优化版 |
| Aurora Standard | AWS Aurora PostgreSQL 17.4，标准版 |
1. 基准结果（平均 TPS）
在对完整矩阵进行多次迭代后，最终的平均性能排行榜如下：
| 环境 | 平均 TPS（读‑写） | 性能状态 |
|---|---|---|
| AWS RDS (t3.large) | 4,826.39 | 峰值性能（可突发） |
| AWS Aurora (I/O‑Prov.) | 3,480.31 | 高性能（昂贵） |
| CNPG + Tuning ③ | 3,350.58 | 效率之王（裸金属） |
| AWS Aurora Standard | 3,325.89 | AWS 标准层 |
| CNPG + Tuning ② | 3,214.43 | 高性能 |
| CNPG + Longhorn | 1,654.84 | 分布式存储开销 |
2. 峰值只读 TPS（最大读取）
Maximum read throughput achieved across all client/thread combinations:
| 环境 | 峰值读取 TPS | 最佳配置 |
|---|---|---|
| RDS Standard | 13,955 | 10 c / 4 t |
| Aurora IO‑Optimized | 10,928 | 10 c / 1 t |
| Aurora Standard | 10,020 | 10 c / 1 t |
| CNPG Local ③ | 8,325 | 10 c / 1 t |
| CNPG Local ② | 8,065 | 10 c / 1 t |
| CNPG Longhorn | 6,165 | 10 c / 8 t |
| CNPG Local ① | 4,758 | 10 c / 8 t |
RDS Standard 在原始读取上领先，但 CNPG ① 与 ③（相同硬件）之间的 75 % 差距 证明配置与底层硬件同样关键。
3. 峰值读写 TPS（最大写入）
| 环境 | 峰值写入 TPS | 最佳配置 |
|---|---|---|
| RDS Standard | 2,839 | 25 c / 8 t |
| CNPG Local ③ | 2,539 | 25 c / 1 t |
| Aurora IO‑Opt | 1,622 | 100 c / 1 t |
| Aurora Standard | 1,557 | 100 c / 8 t |
| CNPG Longhorn | 1,318 | 25 c / 8 t |
| CNPG Local ① | 1,254 | 25 c / 1 t |
结果： 调优后的裸金属性能优于两种 Aurora 变体。Aurora 的写入路径涉及分布式存储复制，会增加延迟。我们使用 NUMA 感知的物理核心 加上本地 SSD SAS，在原始写入吞吐量方面表现更佳。
4. 改变一切的调优发现
| 阶段 | 配置 | TPS | 延迟 |
|---|---|---|---|
| CNPG 本地 ① (baseline) | Default | 1,116 | 0.896 ms |
| 步骤 1 – 内存争用（调优 ②） | work_mem 32 → 4 MB, max_connections 800 → 200 | 2,402 | 0.416 ms |
| 步骤 2 – 缓冲池最大化（调优 ③） | shared_buffers = 6 GB, enable HugePages | 3,350 | 0.394 ms |
步骤 1 背后的计算
800 个连接 × 32 MB = 25.6 GB 的潜在内存压力，在 8 GB 节点上 → 持续换页。限制连接数使系统稳定。
步骤 2 利用了主机的直接内存访问和 NUMA 亲和性，在不更换硬件的情况下将延迟降低了 56 %。
① 0.896 ms ████████████████████████
② 0.416 ms ███████████
③ 0.394 ms ██████████5. 最终结论：性能与成本效率
“虽然 RDS Standard 由于 t3.large 实例的突发特性显示出更高的峰值 TPS，但它的价格显著更高，并且一旦 CPU 积分耗尽，长期性能不可预测。对于成本效率为优先的持续生产工作负载，裸金属上的 CNPG 显然是赢家——以 1/10 的成本提供约 70 % 的性能。”
突发式 CPU 陷阱
AWS t3 实例依赖积分制系统。积分用完后，性能会下降。我们的 32‑核裸金属 为您提供 专用资源——无需 CPU 积分，也没有“噪声邻居”。您可以 100 % 使用 CPU，100 % 的时间。
投资回报率因素
我们的裸金属主机（IDCloudHost Paket 13）配备 512 GB RAM。在 AWS 上，拥有 512 GB RAM 的实例费用极高。而在裸金属上，我们可以在这台机器上托管 数十 个高性能集群，费用固定约为每月 ~Rp 7 M。
关键要点
| # | 洞察 |
|---|---|
| 1 | 存储就是一切。 使用 Longhorn 的测试显示出巨大的性能下降。对于数据库来说，本地 SSD SAS 调优是不可谈判的。 |
| 2 | “云税”是真实存在的。 你为“托管”标签支付额外费用。使用 CNPG，在 K8s 上管理 Postgres 变得可行且更便宜。 |
| 3 | 了解你的工作负载。 如果有不可预测的峰值，RDS 的突发容量非常好。对于稳定的高流量系统，裸金属是基础。 |
| 4 | 默认配置是敌人。 work_mem 与 max_connections 的交互是非线性的。永远不要相信默认设置。 |
| 5 | 裸金属本身并不慢。 经过适当调优，我们在自有硬件上实现了 RDS 写入吞吐量的 69 %。 |
| 6 | Aurora 的写入路径开销。 分布式存储优化的是持久性和读取扩展，而非原始单节点写入速度。 |
| 7 | 存储选择 = 配置选择。 你选择的存储层决定了必须调整的调优参数。 |
ghorn vs. local‑path
性能差异为 33–50 %。存储后端与数据库配置同等重要，需要同等关注。
环境详情
- CloudNativePG：v1.24 on K8s 1.31
- 主机：裸金属 32 核（16 物理 / 16 超线程），NUMA 感知
- 存储：2 × Samsung SM863a Enterprise SSD，RAID 1（SAS 接口）。即使没有 NVMe，适当调优后也实现了 Aurora Standard 性能的 100 %。
- AWS 区域：ap‑southeast‑3（印度尼西亚）
- 规模因子：100（10 M 行）
— Iwan Setiawan，Hybrid Cloud & Platform Architect
portfolio.kangservice.cloud