[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 メーリングリストの案内