我们有一个 postgres 9.0 实例，它运行在一台非常强大的机器上（96G RAM/24 核）。最近几周，我们遇到了由于 Postgres 的子进程被 OOM 杀手杀死而导致的崩溃。似乎由于使用连接池，这些子进程是长期存在的（这是有道理的，因为打开和关闭连接需要时间），问题是它们的内存消耗逐渐增加，甚至达到 9Gigs/进程。你可以想象，有 10 个这样的进程，会填满可用的内存，然后 oom-killer 就会启动。
问题是：
- 如果我们使用默认的配置参数，进程如何可能分配这么多的内存？
- 为什么这些进程永远不会释放内存？
作为参考，可能影响内存的设置：
max_connections = 950
shared_buffers = 32MB
所有其他设置均不会被覆盖，这意味着我们使用默认设置。
答案1
首先要考虑的是增加shared_buffers内存，至少增加到 1GB，甚至更多，最多增加到主内存的 25%。医生怎么说。
仅为 32MB，其中~18Mb 已经被用来应对max_connections950，子进程只能访问勉强够用的共享内存来共享任何内容。
这可能会或可能不会减轻您特定工作量和情况下的内存消耗问题，但无论如何，这是朝着正确方向迈出的一步。当前值非常低。
关于 OOM 具体来说，您可能需要考虑Linux 内存过量使用文档部分。但请注意，这是针对复杂问题的简短段落。例如，还有更多内容在这篇博文中及其带有指针的注释，以便理解限制或禁用 OOM 所涉及的上下文和权衡。
除此之外，Postgres 中始终存在内存泄漏的可能性。您需要确保运行的是最新的次要版本，以防问题已经修复。每个错误修复版本附带的发行说明肯定会不时提到内存泄漏。