postgresql: xid周回問題に潜む別の問題
TRANSCRIPT
Copyright © 2015 NTT DATA Corporation
2015年5月30日 株式会社 NTTデータ 澤田雅彦
XID周回問題に潜む別の問題
PostgreSQLアンカンファレンス@Tokyo
2 Copyright © 2015 NTT DATA Corporation
自己紹介
澤田 雅彦 @sawada_masahiko
NTTデータ 基盤システム事業本部
• PostgreSQLの技術開発、技術支援に従事
• 今年PGCon行きます
3 Copyright © 2015 NTT DATA Corporation
INDEX
• XID周回とXID周回問題
• XID周回問題を防ぐ
• XID周回問題に潜む”別の問題”
• 解決に向けて
4 Copyright © 2015 NTT DATA Corporation
XID周回とXID周回問題
• 約40億トランザクション経過すると0に戻る(→XID周回)
• トランザクションID(XID)は4Byte
• ”過去の見えていたデータ”が、見えなくなってしまう(→XID周回問題)
• 約20億トランザクション経過すると発生。
• 例えば、200TPSのシステムだと、約115日で訪れる→年に3回発生
XID=100
過去 (見える)
未来 (見えない)
XID=100
過去 (見える)
未来 (見えない)
見えない!
XID=100
過去 (見える)
未来 (見えない)
INSERT。 もちろん見える。
まだ見える。
5 Copyright © 2015 NTT DATA Corporation
XID周回問題を防ぐ
• タプルを凍結(FREEZE)
• FREEZEされたタプルはどのXIDよりも古い
• FREEZEする契機
• VACUUM/auto-vacuum/CLUSTER/VACUUM FULL
• auto-vacuumがXID周回問題防止VACUUMを自動で実施
• (残り1000万トランザクションでWARNING)
• (残り100万トランザクションでXIDの払い出しを禁止)
XID=100
過去 (見える)
未来 (見えない)
XID=100
FREEZE
過去 (見える)
未来 (見えない)
XID=100
FREEZE
過去 (見える)
未来 (見えない)
FREEZEされてるので見える!
INSERT。 もちろん見える。
まだ見える。 FREEZE処理実施。
6 Copyright © 2015 NTT DATA Corporation
XID周回問題は防げる。が、
• XID周回防止VACUUMはテーブルのフルスキャンが必要
• これは、更新が全くないテーブルでも必要
→ PostgreSQLは定期的にテーブルのフルスキャンが発生することになる
XID周回問題に潜む別の問題は、
7 Copyright © 2015 NTT DATA Corporation
XID周回問題は防げる。が、
• XID周回防止VACUUMはテーブルのフルスキャンが必要
• これは、更新が全くないテーブルでも必要
→ PostgreSQLは定期的にテーブルのフルスキャンが発生することになる
XID周回問題に潜む別の問題は、
”XID周回防止VACUUMに伴う大量のI/O”
ところで、なぜXID周回防止VACUUMはテーブルをフルスキャンする必要がある?
8 Copyright © 2015 NTT DATA Corporation
blkno lp vm_info t_xmin
0 1 BIT 60(FREEZE)
0 2 BIT 151
1 1 50(FREEZE)
1 2 52(FREEZE)
2 1 BIT 100
2 2 BIT 100
2 3 BIT 101
3 1 90(FREEZE)
3 2 101
4 1 BIT 120(FREEZE)
なぜテーブルをフルスキャンする必要がある?
通常のVACUUMはVisibility Mapにより飛び飛びに実行されることで、
テーブルのrelfrozenxidを更新できないため。
• pg_class.relfrozenxid : FREEZEされていない最小のXID
• XID周回防止VACUUMの必要性は主にrelfrozenxidの値で判断
relfrozenxid
100
: スキップされる ブロック
9 Copyright © 2015 NTT DATA Corporation
解決に向けて
CF9.6でパッチ出してます(★の所)
• XIDを8Byteにする
• XIDをLSNを結びつける
• ★Read-Only Table
• ★すべてのタプルがFREEZEされたページを覚えておく
10
Copyright © 2015 NTT DATA Corporation
VisibilityMapにビットを追加
• これまでは、VMは1ページ当たり1ビットで管理
• ページ内のタプルが全てのトランザクションから見える(all-visible)→ビットを立てる
• ビットが立っているページはVACUUM(ゴミ掃除)不要
• VMに1ビットを追加する
• つまり1ページ当たり2ビット(all-visible, all-frozen)で管理。CLOGみたいな感じ。
• ページ内のタプルが全てFREEZEされている(all-frozen)→ビットを立てる
• ビットが立っているページはVACUUM(タプルFREEZE)不要
• VACUUM(タプルFREEZE)でページをスキップしてもrelfrozenxidを更新できる
9.6ではどちらのVACUUMも高速になる!かも!
11
Copyright © 2015 NTT DATA Corporation
まとめ
• PostgreSQLは更新のないテーブルにも、
定期的にフルスキャン(VACUUM)が走ります。
• 計画的なVACUUM FREEZEである程度防止できる
• 9.6で問題が解決するかも
Copyright © 2011 NTT DATA Corporation
Copyright © 2015 NTT DATA Corporation
Please Review the Patch.