2010年9月10日

[pgsql-jp: 40387] Re:max_locks_per_transactionとpg_dumpの関係

高塚@JPUG/SRAOSS です。

ちょっとソースをのぞいてみました。
およそ推定式通りになっていますが、実際の上限は離散的に決まるようです。

#define NLOCKENTS() \
mul_size(max_locks_per_xact, add_size(MaxBackends, max_prepared_xacts))

ロック用ハッシュテーブルサイズ
= (D)max_locks_per_xact × ((B)MaxBackends + (C)max_prepared_xacts)

となっていて、このテーブルサイズの対数に比して、実際の上限を決める
ロック管理ハッシュの固定のディレクトリサイズを
256 か、512 か、1024 か、というふうに決めているようです。

詳しくはこのあたりを参照ください。

src/backend/storage/lmgr/lock.c:NLOCKENTS()
src/backend/storage/lmgr/README
src/backend/storage/ipc/shmem.c:ShmemInitHash()
src/backend/utils/hash/dynahash.c:hash_select_dirsize()


On Fri, 10 Sep 2010 08:42:32 +0900
川原泰三 <t_kawahara-osk@xxxxx> wrote:

> 現在 pg_dump を行うと以下のようなメッセージが表示されることがあり
> 調査を行っております。
> ERROR: out of shared memory
> HINT: You may need to increase max_locks_per_transaction.
>
> 調査は max_locks_per_transaction を増加させ pg_dump が可能な
> 限界値を測定することで、関係式は無理やり作りましたが、その
> 理由がわからないため納得できておりません。
>
> 関係式もしくは何かしらの考え方があればご教授頂けないでしょうか。
> ちなみに、データベースのバージョンは 8.2.4 になります。
>
> 以下、データベースのパラメータと測定した限界値になります。
> [固定パラメータ]
> (B)max_connections = 128
> (C)max_prepared_transactions = 5
> shared_buffers = 196608(1024MB)
> wal_buffers = 8192(64MB)
> max_fsm_relations = 31000
> max_fsm_pages = 1000000
>
> [変動パラメータ]
> (D)max_locks_per_transaction = 16,32,64,128,256,512,1024
>
> [限界値(同時ロック数)]
> (A)max_locks_per_transaction それぞれの値に対して
> 3548,6593,12607,24693,48932,97362,194129
>
> 考えてみた関係式
> (A)≒(3.891+1.422*(D))*((B)+(C))

______________________________________________________________________
日本PostgreSQLユーザ会 事務局 (担当 高塚) http://www.postgresql.jp
〒170-0005 東京都豊島区南大塚3-46-3 大塚セントコアビル5F SRAOSS内
TEL: 03-5951-1214 FAX: 03-5951-1192


投稿者 xml-rpc : 2010年9月10日 10:14
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/98267
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。