系统相关
首页 > 系统相关> > python – psycopg2超出共享内存和提示增加max_pred_locks_per_transaction

python – psycopg2超出共享内存和提示增加max_pred_locks_per_transaction

作者:互联网

postgresql 9.1中插入大量数据时.使用Python脚本,我们在此查询上收到以下错误:

X: psycopg2.ProgrammingError in /home/hosting/apps/X
X_psycopg.py:162 in : Execute 'execute' (
                        SELECT * FROM xml_fifo.fifo
                        WHERE type_id IN (1,2)
                        ORDER BY type_id, timestamp LIMIT 10
                        ): out of shared memory
HINT:  You might need to increase max_pred_locks_per_transaction

我们增加了这个数字但仍然没有共享内存(max_pred_locks_per_transaction = 192).每次我们再次启动脚本时它会运行一段时间,然后给出此错误消息.在Postgres 8.1上我们没有遇到这个问题.

这是postgresql日志文件的一部分:

2012-06-28 02:55:43 CEST HINT:  Use the escape string syntax for backslashes, e.g., E'\\'.
2012-06-28 02:55:43 CEST WARNING:  nonstandard use of \\ in a string literal at character 271
2012-06-28 02:55:43 CEST HINT:  Use the escape string syntax for backslashes, e.g., E'\\'.
2012-06-28 02:55:43 CEST WARNING:  nonstandard use of \\ in a string literal at character 271
2012-06-28 02:55:43 CEST HINT:  Use the escape string syntax for backslashes, e.g., E'\\'.
2012-06-28 02:56:11 CEST WARNING:  there is already a transaction in progress
2012-06-28 02:57:01 CEST WARNING:  there is already a transaction in progress
2012-06-28 02:57:01 CEST ERROR:  out of shared memory
2012-06-28 02:57:01 CEST HINT:  You might need to increase max_pred_locks_per_transaction.
2012-06-28 02:57:01 CEST STATEMENT:
                                SELECT * FROM xml_fifo.fifo
                                WHERE type_id IN (1,2)
                                ORDER BY type_id ASC, timestamp LIMIT 10

2012-06-28 02:57:01 CEST ERROR:  out of shared memory
2012-06-28 02:57:01 CEST HINT:  You might need to increase max_pred_locks_per_transaction.
2012-06-28 02:57:01 CEST STATEMENT:
                                SELECT * FROM xml_fifo.fifo
                                WHERE type_id IN (1,2)
                                ORDER BY type_id ASC, timestamp LIMIT 10

会出现什么问题?

解决方法:

PostgreSQL在版本9.1中为SERIALIZABLE事务添加了新功能,以避免以前在该隔离级别可能发生的某些序列化异常.只有在使用这些新的可序列化事务时,才能看到错误.在9.1中使用可序列化事务时,某些工作负载遇到了您描述的问题.

一种解决方案是使用REPEATABLE READ事务隔离级别而不是SERIALIZABLE.这将为您提供与9.1之前的PostgreSQL版本中SERIALIZABLE事务完全相同的行为.在决定这样做之前,您可能希望了解这些差异,以便了解是否可能值得重新配置您的环境以避免SERIALIZABLE隔离级别的问题:

http://www.postgresql.org/docs/9.1/interactive/transaction-iso.html

http://wiki.postgresql.org/wiki/SSI

如果增加max_pred_locks_per_transaction没有修复它(并且你可以尝试在不占用太多RAM的情况下显着提高),你可以尝试增加max_connections(不增加实际使用的连接).

我和Dan R.K一起研究了9.1的Serializable Snapshot Isolation功能.麻省理工学院的港口.这个问题的原因是,在这个初始版本中,将多个细粒度谓词锁组合成单个粗粒度锁的启发式算法非常简单.我确信它可以得到改进,但是在设计更好的启发式方面,你能给我的关于它遇到这个问题的环境的任何信息都是有价值的.如果你能告诉我一些你正在使用的CPU数量,活动数据库连接的数量,以及你点击它的工作量,我真的很感激.

感谢您提供任何信息,并对此问题表示歉意.

标签:python,postgresql,postgresql-9-1,isolation-level
来源: https://codeday.me/bug/20190609/1207767.html