我们有一个Postgres9.0实例,它运行在一台非常强大的机器上(96克RAM/24核)。在最近几周,我们已经经历了崩溃,因为子进程的postgres被杀死,没有内存由OOM杀手。由于使用连接池,这些子进程的寿命似乎很长(这是合理的,因为打开和关闭连接需要时间),问题是它们的内存消耗正在逐渐增加,甚至达到9G/进程。正如你可能想象的那样,有10个这样的,填补了可用的公羊和奥姆杀手踢。
问题如下:
可影响内存的设置,供参考:
max_connections = 950
shared_buffers = 32MB
所有其他设置都不会被覆盖,这意味着我们使用的是默认值。
发布于 2012-09-19 20:15:02
要考虑的第一件事是以更高的方式增加shared_buffers
,至少增加到1GB,甚至可能更高,增加到主内存的25%。那是医生怎么说。
只有32 be,其中~18 be将仅用于处理max_connections
到950,子进程几乎没有足够的共享内存来共享任何东西。
这可能会或不会减轻特定工作负载和情况下的内存消耗问题,但无论如何,这是朝着正确方向迈出的一步。目前的数值非常低。
特别是关于OOM,您可能需要考虑文档的Linux内存过度提交部分中提供的解决方案。但是,请注意,对于一个复杂的问题,这是一个简短的段落。例如,还有更多的在这篇博客文章中及其带有指针的注释,以理解限制或禁用OOM所涉及的上下文和权衡。
除此之外,Postgres中的内存泄漏始终是可能的。您需要确保您正在运行最新的次要版本,以防它已经修复。每一个错误修复版本都会附带一些注释,其中肯定会不时提到内存泄漏。
https://serverfault.com/questions/429826
复制相似问题