2

我们最近升级到了 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 的内容）

4

2 回答 2

5

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

看看几分钟前开始（或准备）的任何交易pg_stat_activity。pg_prepared_xacts

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

如果这些解释都没有意义，我很想得到一个可重现的测试用例。有什么方法可以创建表，使用 generate_series() 用查询填充它们并以可预测的方式发生这种情况？有了这样的测试用例，我绝对可以找到原因。

于 2012-10-18T18:33:32.020 回答
0

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

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

于 2014-01-23T11:23:06.930 回答