Parallel Vacuum
•
1 like•1,096 views
PostgreSQL アンカンファレンス2017での発表資料です。PostgreSQLでパラレルにVacuumする再善策を模索中ですので、アイディアがあれば連絡ください。
Recommended
Recommended
More Related Content
More from Masahiko Sawada
More from Masahiko Sawada (20)
Recently uploaded
Recently uploaded (9)
Parallel Vacuum
- 3. タプル 1 タプル 2 タプル 4 タプル 3( 新 ) Vacuum とは？ 削除、更新で発生したゴミタプル（不要領域）を再利用可能に する タプル 1 タプル 2 タプル 3 タプル 4 タプル 1 タプル 2 タプル 3( 旧 ) タプル 4 タプル 3( 新 ) タプル 3 を 更新 VACUUM 空き領域マ ップ（ FSM) 可視性 マップ（ VM) 可視性 マップ（ VM) 更新 ※VACUUM はその他統計情報の更新、末尾の切り詰めも行
- 5. Vacuum の挙動（インデックスあり） テーブルスキャン テーブル VACUUM インデックス VACUUM テーブルスキャン中にゴミタプルが一定量 (maintenance_work_mem) 溜まったら、テーブルとインデックス を Vacuum とする Scan(Collect) Phase Vacuum Phase maintenance_work_mem に 入るだけの量が対象 ※ インデックスが 2 つあるとき
- 6. Vacuum の挙動（インデックスあり） • maintenance_work_mem 内にはゴミタプルを TID が入る • テーブル Vacuum ではゴミタプル情報を 1 つずつ取り出して Vacuum を実行 • インデックス Vacuum では、インデックスを先頭から見ていき、各 リーフが指すタプルがゴミタプル情報内にあるかどうかを確認する (1,4) (1,12) (3,4) (14,5) (14,7) (15,4) (16,4) (16,6) (17,5) (17,6) テーブルのゴミタプル情報 ■ テーブル Vacuum 「 TID を取ってき Vacuum する」の繰り返し （シーケンシャルアクセスになる） ■ インデックス Vacuum インデックスが指す先が上記にあれば回収する （シーケンシャルアクセスになる） （ゴミタプル情報がちゃんと揃っている必要が ある）
- 7. Vacuum の挙動（インデックスなし） テーブルスキャン テーブル VACUUM テーブルスキャン→テーブル Vacuum をひたすら繰り返す。 maintenance_work_mem は使わない。
- 8. Vacuum をパラレル化したい • Visibility Map があるからとはいえ巨大テーブルの VACUUM は きつい • パラレルクエリ機構を使って VACUUM もパラレル化したい • ディスク I/O をより消費するのでそこが注意点
- 9. どのように並列化するか • 並列化できる箇所は色々ある • テーブルのスキャン（ゴミ集め） • テーブルの VACUUM • インデックスの VACUUM • 複数インデックスの VACUUM など
- 10. どのように並列化するか：案① テーブルをスキャンするワーカ、 Vacuum するワーカに分ける （役割別にして、バケツリレー） • 分かりやすい • 並列数をどのように割り当てるか • ランダムアクセスになりそう • 転送コスト W1 W2 W3 W4 テーブルスキャ ン テーブル VACUUM インデックス VACUUM
- 11. どのように並列化するか：案② テーブルを範囲で分割して、各ワーカがスキャン、 Vacuum のど ちらもやる （担当領域を分けて、独立して作業） 各ワーカは独立して、スキャン、 • Vacuum の処理が可能 • ランダムアクセスがすごいことになりそう W1 W2 W3 W4 400 番～ 500 番ブロックを 担当する！ テーブルスキャ ン テーブル VACUUM インデックス VACUUM
- 12. どのように並列化するか：案③ 先頭からパラレルスキャンして、ゴミタプル情報を共有する （各作業単位で並列化する） • ディスクアクセスはシーケンシャルになる • VACUUM する時、再度スキャンに戻る時に • 同期をとる必要がある • ( 元のテーブルサイズ )/( 並列度 ) の • テーブルを VACUUM しているのと • 同じ W1 W2 W3 W4 テーブルスキャ ン テーブル VACUUM インデックス VACUUM
- 13. 今のところ「案③」を実装 • Parallel Seq Scan 的にページを先 頭から読む • ゴミタプルを共有領域に記録する • ゴミタプルが”揃ったら”次へ ゴミタプ ル情報 ゴミタプ ル情報 • 全員でテーブル VACUUM をする • ゴミタプル情報は各ワーカーが取り合う • 1 インデックスを 1 ワーカが担当 • “ 全員のインデックス VACUUM が完了し たら”、ゴミタプル情報をクリアゴミタプ ル情報 以下繰り返し テーブルスキャ ン テーブル VACUUM インデックス VACUUM • ゴミタプル情報を共有し、各ワーカーが排他的に格納 • インデックス Vacuum は 1 インデックスを 1 ワーカに割当
- 14. 今のところ「案③」を実装
- 15. が、スライドを書いていたら気づいた • Parallel Seq Scan 的にページを先頭 から読む • ゴミタプルを共有領域に記録する • ゴミタプルが”揃ったら”次へ • テーブル VACUUM までは各々やって良 い（たぶん）ゴミタプ ル情報 ゴミタプ ル情報 • 全員でテーブル VACUUM をする • ゴミタプル情報は各ワーカーが取り合う • 1 インデックスを 1 ワーカが担当 • パラレルインデックススキャンがあるの で、そこもパラレルにできるかも • 全員のインデックス VACUUM が完了した ら、ゴミタプル情報をクリア ゴミタプ ル情報 以下繰り返し
- 16. 最後にもう一つ
- 17. Group Locking でも競合してほしい問題 • Group Locking とは？ • パラレルクエリ用に開発された Regular Lock(Heavyweight Lock) に関 連する機能 • パラレルクエリのグループ内のワーカー達は Regular Lock が競合しな い • 例）同じパラレルクエリのワーカーたちは同時に AccessExclusiveLock が取得で きる • これまでのパラレルクエリには便利！ • ただ、パラレル DML 、パラレル Vacuum を考えるとリレーショ ンの拡張に問題がある
- 18. Group Locking でも競合してほしい問題 • リレーションの拡張ロックはパラレルワーカー同士でも競合す る必要がある • INSERT 、 UPDATE 時に新しいテーブルのページを確保する時 • Visibility Map 更新時に新しいページを確保する時 • CREATE INDEX で新しいインデックスのページを確保する時 • 「パラレル Vacuum の前にそこを改善しようね」 by PostgreSQL コミュニティ
- 19. 現在のステータス • 拡張ロック専用のロックマネージャを開発 ←いまここ • パラレル Vacuum の実装
- 20. 拡張ロック専用のロックマネージャを開 発中 • そんなことしていいの？ • そもそも拡張ロックについては、 Heavyweight Lock である必要性はない • デッドロック検知とか必要ないし、もっとシンプルで良い • なぜ拡張ロックだけ？ • 他にも同じようなロック（ Heavyweight Lock じゃなくても良い）を探したけ ど、他のは全部デッドロック検知は必要だった • 良いところもある • 拡張ロック専用なので、それだけに最適化できる • メモリ使用量、速度 • その結果、 Heavyweight Lock の時の 10 倍の速度で取得、解放が可能！！ • 将来他の用途向けに機能拡張することも可能
- 21. まとめ • Vacuum をパラレル化したいです • より効率的なアイディア募集中！！ • 拡張ロックの改善はそろそろコミットされるかも ? • パラレル Vacuum 開発が解禁！！