PostgreSQL 9.1 可以泄漏锁吗？ （共享内存不足/增加 max_pred_locks_per_transaction）

Question

我们最近升级到了 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 数字。 （我计划在下次重启时将其调低至 RAM 的 25% 左右）。

编辑：这个调整结果是个坏主意。我的数据库有很多繁重的查询，并且有一半的大 RAM 专用于 shared_buffers 可以防止它阻塞，因为它可以完全缓存更大的表。

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

有人愿意告诉我如何找出这里出了什么问题吗？有了这么小的更新集，我真的不明白为什么我们经常会用完锁……这对我来说确实闻起来像泄漏。

有人知道如何检查锁的去向吗？ （例如，关于这个问题，我如何阅读 pg_locks 的内容）

Answer 1

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

查看 pg_stat_activity 和 pg_prepared_xacts 以了解几分钟前开始（或准备好）的任何事务。

我能想到的唯一其他可能的、非错误的解释是您的表具有成百上千个分区。

如果这些解释都没有道理，我很想得到一个可重现的测试用例。有什么方法可以创建表，使用 generate_series() 使用查询填充它们并以可预测的方式实现这一点？有了这样的测试用例，我肯定可以追查原因。

Answer 2

根据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。