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に行きました。約1日で使い果たされました。9000に行き、約3日でなくなりました。

現在、30000に設定しています。この数は、許可されたクライアント接続ごとに割り当てられる平均であるため、ロックスペース専用の約5GBの共有メモリがあります。

私はshared_buffersをかなり高く設定しています（現時点では24GB）。これはRAMの40％を超えています。（次回の再起動時にこれをRAMの約25％に調整する予定です）。

編集：このチューニングは悪い考えであることが判明しました。私のデータベースは大量のクエリを伴うものであり、shared_buffers専用の大きなRAMの半分を使用すると、大きなテーブルを完全にキャッシュできるため、データベースが窒息するのを防ぎます。

平均して、一度に約5〜10個のアクティブなクエリが表示されます。クエリの負荷は、更新の負荷をはるかに上回っています。

ここで何が問題になっているのかを追跡する方法を教えてくれる人はいますか？このような小さなアップデートセットでは、なぜロックが頻繁に不足しているのか理解できません...それは本当に私へのリークのようなにおいがします。

ロックがどこに向かっているのかを調べる方法を知っている人はいますか？（たとえば、この問題に関してpg_locksの内容をどのように読み取ることができますか）

4

2 に答える 2

5

これは、実行時間の長いトランザクションが原因である可能性が高いようです。1つのトランザクションの述語ロックは、重複するすべての読み取り/書き込みトランザクションが完了するまで解放できません。これには、準備されたトランザクションが含まれます。

両方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.htmlによると、work_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 に答える