『XID周回問題に潜む別の問題』 （PostgreSQLアンカンファレンス@Tokyo 2015/05 発表資料）

1. Copyright © 2015 NTT DATA Corporation
2015年5月30日
株式会社 NTTデータ
澤田雅彦
XID周回問題に潜む別の問題
PostgreSQLアンカンファレンス@Tokyo

2. 2Copyright © 2015 NTT DATA Corporation
自己紹介
澤田 雅彦 @sawada_masahiko
NTTデータ 基盤システム事業本部
• PostgreSQLの技術開発、技術支援に従事
• 今年PGCon行きます

3. 3Copyright © 2015 NTT DATA Corporation
INDEX
• XID周回とXID周回問題
• XID周回問題を防ぐ
• XID周回問題に潜む”別の問題”
• 解決に向けて

4. 4Copyright © 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. 5Copyright © 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. 6Copyright © 2015 NTT DATA Corporation
XID周回問題は防げる。が、
• XID周回防止VACUUMはテーブルのフルスキャンが必要
• これは、更新が全くないテーブルでも必要
→ PostgreSQLは定期的にテーブルのフルスキャンが発生することになる
XID周回問題に潜む別の問題は、

7. 7Copyright © 2015 NTT DATA Corporation
XID周回問題は防げる。が、
• XID周回防止VACUUMはテーブルのフルスキャンが必要
• これは、更新が全くないテーブルでも必要
→ PostgreSQLは定期的にテーブルのフルスキャンが発生することになる
XID周回問題に潜む別の問題は、
”XID周回防止VACUUMに伴う大量のI/O”
ところで、なぜXID周回防止VACUUMはテーブルをフルスキャンする必要がある？

8. 8Copyright © 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. 9Copyright © 2015 NTT DATA Corporation
解決に向けて
CF9.6でパッチ出してます(★の所)
• XIDを8Byteにする
• XIDをLSNを結びつける
• ★Read-Only Table
• ★すべてのタプルがFREEZEされたページを覚えておく

10. 1Copyright © 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. 1Copyright © 2015 NTT DATA Corporation
まとめ
• PostgreSQLは更新のないテーブルにも、
定期的にフルスキャン(VACUUM)が走ります。
• 計画的なVACUUM FREEZEである程度防止できる
• 9.6で問題が解決するかも

12. Copyright © 2011 NTT DATA Corporation
Copyright © 2015 NTT DATA Corporation
Please Review the Patch.