我们正在对访问 Postgres 数据库的应用程序运行负载测试。
在测试过程中，我们突然发现错误率有所增加。在分析平台和应用程序行为后，我们注意到：
- Postgres RDS 的 CPU 为 100%
- 同一台服务器上的可用内存减少
在 postgres 日志中我们看到：
2018-08-21 08:19:48 UTC::@:[XXXXX]:LOG: 服务器进程 (PID XXXX) 被信号 9 终止：已终止
经过调查和阅读文档后，似乎有一种可能性是 Linux oomkiller 正在运行并终止了该进程。
但由于我们使用的是 RDS，因此我们无法访问系统日志 /var/log 消息进行确认。
有人也可以：
- 确认 oom killer 确实在 AWS RDS for Postgres 上运行
- 给我们一种方法来检查一下？
- 能给我们提供一种根据连接数计算 Postgres 使用的最大内存的方法吗？
我没有在这里找到答案：
答案1
即使 OOM 杀手没有采取行动（它可能已经采取行动了），持续 100% 的 CPU 和非常低的可用内存也会对性能产生不利影响。
使用更大的实例大小，看看问题是否消失。在您控制的非 RDS Postgres 上测试较小的实例大小，看看 OOM 杀手是否会发怒。
连接数不一定是内存消耗的主要因素：共享内存用于其他用途，并且并非每个查询都使用大量内存。另请参阅此对话：PostgreSql 为每个连接分配内存。
额外的建议Amazon RDS 的最佳实践
数据库实例 RAM 建议
Amazon RDS 性能最佳实践是分配足够的 RAM，以便您的工作集几乎完全驻留在内存中。要判断您的工作集是否几乎全部驻留在内存中，请在数据库实例处于负载状态时检查 ReadIOPS 指标（使用 Amazon CloudWatch）。ReadIOPS 的值应该很小且稳定。如果将数据库实例类扩展为具有更多 RAM 的类导致 ReadIOPS 急剧下降，则您的工作集并非几乎完全驻留在内存中。继续扩展，直到 ReadIOPS 在扩展操作后不再急剧下降，或者 ReadIOPS 减少到非常小的量。
评估绩效指标
可用内存 – 数据库实例上可用的 RAM 量（以兆字节为单位）。监控选项卡指标中的红线标记为 CPU、内存和存储指标的 75%。如果实例内存消耗频繁超过该线，则表明您应该检查工作负载或升级实例。
答案2
我对 Postgres 没什么经验，但在同样的情况下，我发现 RDS MySql 实例很容易完全重启。即使您无法访问底层系统，您也应该能够通过 Web 控制台获取 postgres 日志。查看重启，守护进程应该会指示它正在关闭并启动。
无论如何，如果你在危险区域工作，你无能为力。你应该转移到具有更多可用 RAM / CPU 的实例。