KEMBAR78
PostgreSQL: XID周回問題に潜む別の問題 | PDF
Copyright © 2015 NTT DATA Corporation
2015年5月30日
株式会社 NTTデータ
澤田雅彦
XID周回問題に潜む別の問題
PostgreSQLアンカンファレンス@Tokyo
2Copyright © 2015 NTT DATA Corporation
自己紹介
澤田 雅彦 @sawada_masahiko
NTTデータ 基盤システム事業本部
• PostgreSQLの技術開発、技術支援に従事
• 今年PGCon行きます
3Copyright © 2015 NTT DATA Corporation
INDEX
• XID周回とXID周回問題
• XID周回問題を防ぐ
• XID周回問題に潜む”別の問題”
• 解決に向けて
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。
もちろん見える。
まだ見える。
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処理実施。
6Copyright © 2015 NTT DATA Corporation
XID周回問題は防げる。が、
• XID周回防止VACUUMはテーブルのフルスキャンが必要
• これは、更新が全くないテーブルでも必要
→ PostgreSQLは定期的にテーブルのフルスキャンが発生することになる
XID周回問題に潜む別の問題は、
7Copyright © 2015 NTT DATA Corporation
XID周回問題は防げる。が、
• XID周回防止VACUUMはテーブルのフルスキャンが必要
• これは、更新が全くないテーブルでも必要
→ PostgreSQLは定期的にテーブルのフルスキャンが発生することになる
XID周回問題に潜む別の問題は、
”XID周回防止VACUUMに伴う大量のI/O”
ところで、なぜXID周回防止VACUUMはテーブルをフルスキャンする必要がある?
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
: スキップされる
ブロック
9Copyright © 2015 NTT DATA Corporation
解決に向けて
CF9.6でパッチ出してます(★の所)
• XIDを8Byteにする
• XIDをLSNを結びつける
• ★Read-Only Table
• ★すべてのタプルがFREEZEされたページを覚えておく
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も高速になる!かも!
1Copyright © 2015 NTT DATA Corporation
まとめ
• PostgreSQLは更新のないテーブルにも、
定期的にフルスキャン(VACUUM)が走ります。
• 計画的なVACUUM FREEZEである程度防止できる
• 9.6で問題が解決するかも
Copyright © 2011 NTT DATA Corporation
Copyright © 2015 NTT DATA Corporation
Please Review the Patch.

PostgreSQL: XID周回問題に潜む別の問題

  • 1.
    Copyright © 2015NTT DATA Corporation 2015年5月30日 株式会社 NTTデータ 澤田雅彦 XID周回問題に潜む別の問題 PostgreSQLアンカンファレンス@Tokyo
  • 2.
    2Copyright © 2015NTT DATA Corporation 自己紹介 澤田 雅彦 @sawada_masahiko NTTデータ 基盤システム事業本部 • PostgreSQLの技術開発、技術支援に従事 • 今年PGCon行きます
  • 3.
    3Copyright © 2015NTT DATA Corporation INDEX • XID周回とXID周回問題 • XID周回問題を防ぐ • XID周回問題に潜む”別の問題” • 解決に向けて
  • 4.
    4Copyright © 2015NTT DATA Corporation XID周回とXID周回問題 • 約40億トランザクション経過すると0に戻る(→XID周回) • トランザクションID(XID)は4Byte • ”過去の見えていたデータ”が、見えなくなってしまう(→XID周回問題) • 約20億トランザクション経過すると発生。 • 例えば、200TPSのシステムだと、約115日で訪れる→年に3回発生 XID=100 過去 (見える) 未来 (見えない) XID=100 過去 (見える) 未来 (見えない) 見えない! XID=100 過去 (見える) 未来 (見えない) INSERT。 もちろん見える。 まだ見える。
  • 5.
    5Copyright © 2015NTT 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 © 2015NTT DATA Corporation XID周回問題は防げる。が、 • XID周回防止VACUUMはテーブルのフルスキャンが必要 • これは、更新が全くないテーブルでも必要 → PostgreSQLは定期的にテーブルのフルスキャンが発生することになる XID周回問題に潜む別の問題は、
  • 7.
    7Copyright © 2015NTT DATA Corporation XID周回問題は防げる。が、 • XID周回防止VACUUMはテーブルのフルスキャンが必要 • これは、更新が全くないテーブルでも必要 → PostgreSQLは定期的にテーブルのフルスキャンが発生することになる XID周回問題に潜む別の問題は、 ”XID周回防止VACUUMに伴う大量のI/O” ところで、なぜXID周回防止VACUUMはテーブルをフルスキャンする必要がある?
  • 8.
    8Copyright © 2015NTT 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 © 2015NTT DATA Corporation 解決に向けて CF9.6でパッチ出してます(★の所) • XIDを8Byteにする • XIDをLSNを結びつける • ★Read-Only Table • ★すべてのタプルがFREEZEされたページを覚えておく
  • 10.
    1Copyright © 2015NTT 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 © 2015NTT DATA Corporation まとめ • PostgreSQLは更新のないテーブルにも、 定期的にフルスキャン(VACUUM)が走ります。 • 計画的なVACUUM FREEZEである程度防止できる • 9.6で問題が解決するかも
  • 12.
    Copyright © 2011NTT DATA Corporation Copyright © 2015 NTT DATA Corporation Please Review the Patch.