我们最近升级到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,由于这个数字是每个允许的客户端连接的平均分配数,我现在有大约5GB的共享内存专用于锁定空间!
我确实设置了相当高的shared_buffers (目前为24 is ),超过了40%的内存。(我计划在下次重新启动时将其调到内存的25%左右)。
编辑:这个调优结果是个坏主意。我的数据库包含了大量的大量查询,并且有一半的大内存专用于shared_buffers,这样就不会让它窒息,因为它可以完全缓存更大的表。
平均而言,我一次看到大约5-10个活动查询。我们的查询负载远远超过我们的更新负载。
有人想告诉我怎么找出这里出了什么问题吗?有了这么小的更新集,我真的搞不懂为什么我们的锁快用完了,所以often...it确实有泄漏的味道。
有人知道如何检查锁的去向吗?(例如,如何阅读有关此问题的pg_locks内容)
发布于 2012-10-18 18:33:32
这听起来很可能是由长期运行的事务造成的。在所有重叠的读写事务完成之前,不能释放一个事务的谓词锁。这包括准备好的交易。
看看几分钟前开始(或准备好的)任何事务的pg_stat_activity
和pg_prepared_xacts
。
我唯一能想到的其他可能的、无错误的解释是,您的表中有数百个或数千个分区。
如果这两种解释都没有意义的话,我希望能得到一个可重复的测试用例。是否有任何方法来创建表,使用generate_series()填充查询并以可预测的方式实现这一点?有了这样一个测试用例,我肯定可以找到原因。
发布于 2014-01-23 11:23:06
根据http://www.progtown.com/topic1203868-error-out-of-shared-memory.html,减少work_mem
配置参数可能是有意义的。
https://stackoverflow.com/questions/12946715
复制相似问题