[pgsql-jp: 38165] Re: cacuum に異常に時間がかかる理由
Tatsuo Ishii
ishii @ sraoss.co.jp
2007年 3月 15日 (木) 21:07:43 JST
石井です.
# このサブジェクト,なんとかならないですかねぇ.
> 全メモリが1Gしか無いので、このくらいが限界かと思いました。
1Gですか.1000万行以上あるテーブルを抱えている割にはずいぶん少ないです
ね.vmstatなどを使って,システムの負荷状況を見た方がよいと思いますよ.
> 気になることがあるのでどなたか教えていただきたいのですが、
> vacuum のアルゴリズムですが、時間は溜まったゴミの量に単純に比例ではなく、
> log(n)×n とか n×n に比例するのでしょうか。
VACUUMにかかる時間は,少なくとも物理的なDBの大きさに比例します.
ところで,
INFO: index "odds_sanhuku_pkey" now contains 13282848 row versions in 295540 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 26.96s/2.91u sec elapsed 3402.66 sec.
INFO: "odds_sanhuku": found 0 removable, 13282848 nonremovable row versions in 94426 pages
というのを見ると,テーブル本体が94426ページ(737MB)しかないのに,インデッ
クスが295540(2.2GB)と,テーブル本体の3倍にも膨れています.いわゆる
"index bloat" の状態と思われます.
ここまで来てしまっている以上,REINDEXするか,いっそDBをdump/restoreし
た方がよいような気がします.
> 単純な比例だと思っていたので、負荷のはげしくかかる土日を避けて、
> 全く更新もなく、ユーザーも来ない火曜にまとめて vacuum していました。
ほかの人も書いていますが,その運用はまずいですね.
というわけで,推測するに問題の原因は,ハードの能力不足と,不要領域の溜
りすぎ,index bloatだと思われます.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
pgsql-jp メーリングリストの案内