我们最近升级到postgresql 9.1.6（从8.3开始）。我们的测试服务器指出max_pred_locks_per_transaction应该设置为至少高达900（这超出了建议的64的设置）。
我们现在正在制作中，我不得不多次增加此参数，因为我们的日志将开始填充：
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，并且因为这个数字是每个允许的客户端连接分配的平均值，所以我现在有大约5 GB的共享内存专用于锁定空间！
我确实将shared_buffers设置得相当高（目前为24GB），这超过了40％的RAM数字。 （我打算在下次重启时将其调低到大约25％的RAM。）
编辑：这个调整结果是一个坏主意。我的数据库有很多繁重的查询，并且有一半专用于shared_buffers的大RAM使它不会窒息，因为它可以完全缓存较大的表。
平均而言，我一次看到大约5-10个活动查询。我们的查询负载远超过了我们的更新负载。
有人想告诉我如何追踪这里出了什么问题吗？有了这么小的更新集，我真的无法弄清楚为什么我们经常用完锁......它真的闻起来像是泄漏给我。
任何人都知道如何检查锁的去向？ （例如，我如何阅读有关此问题的pg_locks的内容）
答案 0 :(得分：3)
这听起来很可能是由长时间运行的交易引起的。在完成所有重叠的读写事务之前，不能释放一个事务的谓词锁。这包括准备好的交易。
对于在几分钟前开始（或准备好）的任何交易，请查看pg_stat_activity和pg_prepared_xacts。
我能想到的唯一其他可能的非bug解释是你有数百或数千个分区的表。
如果这些解释都没有意义，我很乐意接受可重复的测试用例。有没有办法创建表，使用generate_series（）用查询填充它们，并以可预测的方式实现这一点？有了这样的测试用例，我绝对可以找到原因。
答案 1 :(得分：0)