首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >PostgreSQL 9.1能泄漏锁吗?(没有共享内存/增加max_pred_locks_per_transaction)

PostgreSQL 9.1能泄漏锁吗?(没有共享内存/增加max_pred_locks_per_transaction)
EN

Stack Overflow用户
提问于 2012-10-18 03:39:42
回答 2查看 3.7K关注 0票数 2

我们最近升级到postgresql 9.1.6 (从8.3版本)。我们的测试服务器指出,max_pred_locks_per_transaction至少应该设置为900 (这远远超出了建议的64设置)。

我们现在正在生产,我不得不多次增加这个参数,因为我们的日志将开始填充以下内容:

代码语言:javascript
运行
复制
ERROR:  53200: out of shared memory
HINT:  You might need to increase max_pred_locks_per_transaction.

将客户端连接设置为600 (但池系统永远不会超过100个客户端):

max_pred_locks_per_transaction:我们去了3000家。一天后就跑出去了。去了9000,在3天内就用完了。

我现在将它设置为30000,由于这个数字是每个允许的客户端连接的平均分配数,我现在有大约5GB的共享内存专用于锁定空间!

我确实设置了相当高的shared_buffers (目前为24 is ),超过了40%的内存。(我计划在下次重新启动时将其调到内存的25%左右)。

编辑:这个调优结果是个坏主意。我的数据库包含了大量的大量查询,并且有一半的大内存专用于shared_buffers,这样就不会让它窒息,因为它可以完全缓存更大的表。

平均而言,我一次看到大约5-10个活动查询。我们的查询负载远远超过我们的更新负载。

有人想告诉我怎么找出这里出了什么问题吗?有了这么小的更新集,我真的搞不懂为什么我们的锁快用完了,所以often...it确实有泄漏的味道。

有人知道如何检查锁的去向吗?(例如,如何阅读有关此问题的pg_locks内容)

EN

回答 2

Stack Overflow用户

回答已采纳

发布于 2012-10-18 18:33:32

这听起来很可能是由长期运行的事务造成的。在所有重叠的读写事务完成之前,不能释放一个事务的谓词锁。这包括准备好的交易。

看看几分钟前开始(或准备好的)任何事务的pg_stat_activitypg_prepared_xacts

我唯一能想到的其他可能的、无错误的解释是,您的表中有数百个或数千个分区。

如果这两种解释都没有意义的话,我希望能得到一个可重复的测试用例。是否有任何方法来创建表,使用generate_series()填充查询并以可预测的方式实现这一点?有了这样一个测试用例,我肯定可以找到原因。

票数 5
EN

Stack Overflow用户

发布于 2014-01-23 11:23:06

根据http://www.progtown.com/topic1203868-error-out-of-shared-memory.html,减少work_mem配置参数可能是有意义的。

有关其他详细信息,请参见https://dba.stackexchange.com/questions/27893/increasing-work-mem-and-shared-buffers-on-postgres-9-2-significantly-slows-down

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/12946715

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档