4

postgresql 9.1 に大量のデータを挿入している間。Python スクリプトを使用すると、このクエリで次のエラーが発生します。

X: /home/hosting/apps/X の psycopg2.ProgrammingError
X_psycopg.py:162 in : 実行 'execute' (
                        SELECT * FROM xml_fifo.fifo
                        WHERE type_id IN (1,2)
                        ORDER BY type_id、タイムスタンプ LIMIT 10
                        ): 共有メモリが不足しています
ヒント: max_pred_locks_per_transaction を増やす必要があるかもしれません

この数を増やしましたが、それでも共有メモリが不足します (max_pred_locks_per_transaction = 192)。スクリプトを再起動するたびに、しばらく実行された後、このエラー メッセージが表示されます。Postgres 8.1 では、この問題はありませんでした。

以下は、postgresql ログ ファイルの一部です。

2012-06-28 02:55:43 CEST ヒント: バックスラッシュには E'\\' などのエスケープ文字列構文を使用します。
2012-06-28 02:55:43 CEST 警告: 文字 271 の文字列リテラルでの \\ の非標準使用
2012-06-28 02:55:43 CEST ヒント: バックスラッシュには E'\\' などのエスケープ文字列構文を使用します。
2012-06-28 02:55:43 CEST 警告: 文字 271 の文字列リテラルでの \\ の非標準使用
2012-06-28 02:55:43 CEST ヒント: バックスラッシュには E'\\' などのエスケープ文字列構文を使用します。
2012-06-28 02:56:11 CEST 警告: 進行中のトランザクションが既にあります
2012-06-28 02:57:01 CEST 警告: 進行中のトランザクションが既にあります
2012-06-28 02:57:01 CEST エラー: 共有メモリが不足しています
2012-06-28 02:57:01 CEST ヒント: max_pred_locks_per_transaction を増やす必要があるかもしれません。
2012-06-28 02:57:01 CEST ステートメント:
                                SELECT * FROM xml_fifo.fifo
                                WHERE type_id IN (1,2)
                                ORDER BY type_id ASC、タイムスタンプ LIMIT 10

2012-06-28 02:57:01 CEST エラー: 共有メモリが不足しています
2012-06-28 02:57:01 CEST ヒント: max_pred_locks_per_transaction を増やす必要があるかもしれません。
2012-06-28 02:57:01 CEST ステートメント:
                                SELECT * FROM xml_fifo.fifo
                                WHERE type_id IN (1,2)
                                ORDER BY type_id ASC、タイムスタンプ LIMIT 10

問題は何でしょうか？

4

1 に答える 1

8

PostgreSQL はバージョン 9.1 でトランザクションに新しい機能を追加SERIALIZABLEし、以前はその分離レベルで発生する可能性があったいくつかのシリアライゼーションの異常を回避しました。表示されているエラーは、これらの新しいシリアル化可能なトランザクションを使用している場合にのみ発生する可能性があります。一部のワークロードでは、9.1 でシリアル化可能なトランザクションを使用するときに、説明した問題が発生しました。

REPEATABLE READ解決策の 1 つは、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 を増やしてみることができます (使用される実際の接続を増やさずに)。

私は MIT の Dan RK Ports と共に、9.1 の Serializable Snapshot Isolation 機能に取り組みました。この問題の原因は、複数のきめの細かい述語ロックを 1 つのきめの粗いロックに結合するためのヒューリスティックが、この初期バージョンでは非常に単純であることです。改善できると確信していますが、この問題が発生している状況について教えていただける情報は、より優れたヒューリスティックを設計する上で貴重です。使用している CPU の数、アクティブなデータベース接続の数、およびこれにヒットしたワークロードについて少し教えていただければ、本当にありがたいです。

情報をありがとう、そして問題についてお詫び申し上げます。

于 2012-04-21T23:58:42.930 に答える