Ad
More Related Content
What's hot (20)
Similar to PostgreSQL: XID周回問題に潜む別の問題 (20)
Ad
More from NTT DATA OSS Professional Services (20)
Ad
PostgreSQL: XID周回問題に潜む別の問題
- 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.