我试图弄清楚为什么大约30个空闲的postgres进程在正常使用后会占用这么多进程特定的内存。我使用的是Postgres9.3.1和CentOS版本6.3 (最终版)。使用top
,我可以看到许多postgres连接使用了高达300mb (平均约200MB)的非共享(RES - SHR)内存:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3534 postgres 20 0 2330m 1.4g 1.1g S 0.0 20.4 1:06.99 postgres: deploy mtalcott 10.222.154.172(53495) idle
9143 postgres 20 0 2221m 1.1g 983m S 0.0 16.9 0:14.75 postgres: deploy mtalcott 10.222.154.167(35811) idle
6026 postgres 20 0 2341m 1.1g 864m S 0.0 16.4 0:46.56 postgres: deploy mtalcott 10.222.154.167(37110) idle
18538 postgres 20 0 2327m 1.1g 865m S 0.0 16.1 2:06.59 postgres: deploy mtalcott 10.222.154.172(47796) idle
1575 postgres 20 0 2358m 1.1g 858m S 0.0 15.9 1:41.76 postgres: deploy mtalcott 10.222.154.172(52560) idle
总共大约有29个空闲连接。这些空闲连接在内存中不断增长,直到机器开始使用交换,然后性能逐渐停止。正如预期的那样,重置连接将清除特定于进程的内存。当我定期重新连接时,同一台机器上相同数量的连接仅使用20%的内存(没有交换)。这些进程持有哪些类型的信息?我希望长时间运行的空闲postgres进程的内存使用量与全新的空闲进程相似。
值得一提的是:我大量使用模式。对于我的应用程序的每一个请求,我都在设置和重置search_path。
发布于 2013-12-18 03:15:52
这些进程持有哪些类型的信息?我希望长时间运行的空闲postgres进程的内存使用量与全新的空闲进程相似。
实际上,Postgres加载后会在本地内存中缓存相当多的内容:
关系descriptors)
对于大多数用例,所有这些加起来可以忽略不计。这里的关键是模式的大量使用以及对relcache的影响。这个数据库包含大约500个模式,每个模式都有相同的大约90个表。对于Postgres来说,即使所有的模式都是相同的,这相当于45,000个表(500*90)。
每个请求都在内存中缓存了一些表的关系描述符(最常见的情况是在与前一个请求不同的模式中),逐渐填满了relcache。不幸的是,Postgres does not offer a way to limit the size of these caches,因为开销在大多数用例中可能会适得其反。
可能的解决方案:
在请求达到一定数量后重新连接
的postgres连接的数量
感谢汤姆·莱恩和梅林·蒙库尔在Postgres mailing lists上的帮助。
https://stackoverflow.com/questions/20514569
复制相似问题