笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
AWS 上 PostgreSQL 实例选型指南：基于 23 种 EC2 实例类型的性能与成本基准测试
通过基准测试对比 23 种 AWS EC2 实例类型在 PostgreSQL 上的性能与成本，帮助开发者找到满足吞吐需求的最具性价比配置。
引言
在 AWS 上运行 PostgreSQL 时，选择合适的 EC2 实例类型和磁盘配置是一项常见但棘手的任务。实例种类繁多——从通用型（m 系列）、计算优化型（c 系列）到内存优化型（r 系列），加上 x86-64 与 Arm64（Graviton）两种架构，以及 gp3 磁盘的不同基线性能模式，开发者很容易陷入选择困难。
本文作者通过系统化的基准测试，测量了 23 种 EC2 实例类型（每种搭配不同磁盘配置，共 52 种组合）在 PostgreSQL 17 下的表现，并以一个直观的交互式工具呈现结果，帮助开发者“一眼”找到最便宜且满足吞吐需求的配置。
测试方法论
工作负载
- 读写比例：90% 读 / 10% 写（模拟典型 Web 应用场景）
- 并发连接数：32
- 数据库版本：PostgreSQL 17
- 区域：us-east-1（美东一区）
- 计费模式：按需付费（On-Demand）
数据集规模
测试覆盖了三种数据量级：1 GB、10 GB、50 GB。本文重点呈现 1 GB 数据集的结果，因为小数据量下更能体现 CPU 和内存的性能差异，而大数据集则更容易受磁盘 I/O 限制。
性能指标
- RPS：每秒请求数（Requests Per Second），即吞吐量
- RPS/$：每美元成本对应的每秒请求数（性价比指标）
- 延迟：平均延迟（avg ms）、P95 延迟、P99 延迟
- Headroom：实际吞吐量相对于目标吞吐量的倍数（如 1.4× 表示超出目标 40%）
磁盘配置
所有测试均使用 gp3（通用型 SSD）卷，但区分两种 IOPS 模式：
- gp3-baseline：使用 gp3 的基线 IOPS（3000 IOPS，125 MB/s 吞吐量），适合低成本场景
- gp3-max：开启 gp3 的最大性能模式（16000 IOPS，1000 MB/s 吞吐量），适合高 I/O 场景
核心发现：1 GB 数据集，目标 33,000 RPS
以 33,000 RPS 为目标吞吐量，作者筛选出所有满足或超过该性能的实例配置，并按月成本排序。以下是关键结果：
最便宜的选择：m8g.large（Graviton Arm64）
- 配置：2 vCPU、8 GiB 内存、gp3-baseline 磁盘
- 月成本：~$82/月
- 实际 RPS：45,515（超出目标 1.4×）
- P99 延迟：2.76 ms
- 性价比：407,555 RPS/$（每美元每小时可处理约 40 万请求）
这个结果令人惊讶：最便宜的方案并非来自 x86-64 架构，而是 Arm64 的 Graviton 实例。m8g.large 仅用 $82/月就实现了 45,515 RPS，远超目标 33,000 RPS，且延迟极低。
最佳性价比：c8i.large（x86-64）
- 配置：2 vCPU、4 GiB 内存、gp3-baseline 磁盘
- 月成本：~$84/月
- 实际 RPS：52,203（超出目标 1.6×）
- 性价比：451,476 RPS/$（全场最高）
虽然 c8i.large 的月成本略高于 m8g.large（$84 vs $82），但其 RPS/$ 指标更高，意味着在同样的预算下能处理更多请求。不过它的内存只有 4 GiB，对于需要较大 shared_buffers 的工作负载可能不够。
其他值得关注的配置
| 实例类型 | 架构 | vCPU | 内存 | 磁盘模式 | 月成本 | RPS | 性价比 (RPS/$) | Headroom |
|---|---|---|---|---|---|---|---|---|
| m8g.xlarge | Arm64 | 4 | 16 GiB | gp3-baseline | ~$147 | 70,871 | 351,826 | 2.1× |
| m7i.large | x86-64 | 2 | 8 GiB | gp3-baseline | ~$90 | 41,305 | 336,586 | 1.3× |
| m7g.xlarge | Arm64 | 4 | 16 GiB | gp3-baseline | ~$135 | 58,726 | 317,234 | 1.8× |
| c8i.xlarge | x86-64 | 4 | 8 GiB | gp3-baseline | ~$153 | 64,585 | 308,522 | 2.0× |
| r8g.large | Arm64 | 2 | 16 GiB | gp3-baseline | ~$92 | 38,531 | 304,746 | 1.2× |
头部配置的共性
- Graviton 全面领先：在性价比前 10 名中，Arm64 实例占据 6 席，且前两名均为 Graviton 实例。
- gp3-baseline 优于 gp3-max：对于 1 GB 数据集，基线 IOPS 已足够，开启最大模式反而因成本增加而降低性价比。
- 小实例更划算：2 vCPU 的实例（如 m8g.large、c8i.large）在性价比上优于更大规格，因为工作负载尚未达到 CPU 瓶颈。
深入分析：磁盘模式的影响
对于 1 GB 数据集，gp3-baseline 和 gp3-max 的性能差异很小——因为数据可以完全缓存在内存中，磁盘 I/O 不是瓶颈。例如：
- m8g.large（gp3-baseline）：45,515 RPS，$82/月
- m8g.large（gp3-max）：38,463 RPS，$182/月（性能反而略低，成本翻倍）
结论：当数据集远小于内存时，不必为磁盘性能付费。但若数据集增长到 10 GB 或 50 GB（超过内存容量），磁盘 I/O 将成为关键因素，届时 gp3-max 的优势会显现。
架构对比：Arm64 vs x86-64
| 指标 | Arm64 (Graviton) | x86-64 |
|---|---|---|
| 性价比冠军 | m8g.large（407,555 RPS/$） | c8i.large（451,476 RPS/$） |
| 最便宜达标方案 | m8g.large（$82/月） | c8i.large（$84/月） |
| 最高 RPS | m8g.2xlarge（81,451） | c8i.2xlarge（61,861） |
| 平均延迟 | 相近 | 相近 |
Arm64 在性价比上整体占优，但 x86-64 在特定实例（如 c8i 系列）上也有出色表现。值得注意的是，Graviton 实例通常提供更多内存（如 m8g.large 有 8 GiB，而同价位的 c8i.large 只有 4 GiB），这对 PostgreSQL 的 shared_buffers 配置更友好。
实例系列对比
通用型（m 系列）
- m8g（Graviton 4）：性价比之王，m8g.large 和 m8g.xlarge 分别占据性价比前两名
- m7g（Graviton 3）：性能与 m8g 接近，但价格略高
- m7i（x86-64）：在 x86-64 阵营中表现不错，但整体不如 Graviton
- m5（上一代 x86-64）：性能明显落后，不建议新部署使用
计算优化型（c 系列）
- c8i（x86-64）：在低内存场景下性价比突出，c8i.large 是全场 RPS/$ 最高
- c8i 与 m8g 对比：同样 2 vCPU，c8i.large 有 4 GiB 内存，m8g.large 有 8 GiB 内存——如果应用需要更多内存用于缓存，m8g 更优
内存优化型（r 系列）
- r8g（Graviton）：适合大数据集场景，但小数据集下性价比不如 m 系列
- 例如 r8g.large（2 vCPU, 16 GiB）月成本 $92，RPS 38,531，性价比 304,746 RPS/$，低于 m8g.large
突发型（t 系列）
- t3（x86-64）和 t4g（Arm64）：适合低负载或突发性工作负载
- 性能差距巨大：t3.small 仅 3,353 RPS，且 P99 延迟高达 71 ms，完全不适合生产环境
- 结论：t 系列只适合开发、测试或极低负载场景，生产环境应避免
实用建议
如何选择？
- 确定目标吞吐量：估算你的应用需要多少 RPS（例如通过压测或流量预估）
- 选择数据集规模：数据量直接影响是否需要关注磁盘 I/O
- 优先考虑 Graviton：对于 PostgreSQL，Arm64 实例通常提供更好的性价比
- 从 m8g.large 开始：如果目标在 30,000-50,000 RPS 范围内，m8g.large 是安全且经济的选择
- 考虑内存需求：如果 shared_buffers 需要大量内存（例如数据量 > 内存），转向 r8g 系列
- 磁盘选择：当数据集可完全缓存时，gp3-baseline 足够；否则考虑 gp3-max 或 io2 块存储
成本优化技巧
- 预留实例：按需价格只是参考，预留实例或 Savings Plans 可降低 30-60% 成本
- 避免过度配置：很多开发者习惯选择大实例“以防万一”，但测试表明小实例往往已足够
- 监控实际负载：使用 pg_stat_statements 和 CloudWatch 持续监控，按需调整
总结
这份基准测试清晰地展示了 AWS 上 PostgreSQL 实例选型的“甜点”：
- 最佳入门选择：m8g.large（Graviton，$82/月，45,515 RPS）
- 极致性价比：c8i.large（x86-64，$84/月，52,203 RPS，RPS/$ 最高）
- 高吞吐需求：m8g.2xlarge（8 vCPU，32 GiB，81,451 RPS，$278/月）
核心原则：不要盲目选择大实例，也不要盲目选择 x86-64。Graviton 在 PostgreSQL 场景下已证明其价值，而小实例配合合理的内存配置往往能带来最高性价比。
对于生产环境，建议基于实际工作负载和数据集大小，使用作者提供的交互式工具（或类似方法）进行验证，而非仅凭经验猜测。