SlideShare a Scribd company logo
【T2】Vacuum徹底解説
Masahiko Sawada
PostgreSQL Conference Japan 2021
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
2
Vacuumは最も重要な機能の一つ
• PostgreSQL = Vacuumみたいなところもある
• 仕組みや特性を理解する
• トラブル時も慌てなくなるし、応用も効く
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
3
目次
• PostgreSQLのアーキテクチャを簡単に紹介
• なぜVacuumが必要?どうやって動くの?
• ゴミ掃除
• XID周回の防止(FREEZE)
• おすすめの設定パラメータ
• モニタリング
• トラブルシューティング&TIPS
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
4
用語説明
• ページ/ブロック
• テーブル、インデックスを構成するデータ。PostgreSQLのI/Oする単位。デフォルトでは1ページは
8kB。
• トランザクションID(XID)
• 各トランザクションに付与される単調増加する非負整数
• Visibility Map
• 各テーブルに付いているマップ。「ゴミを持つブロック」が簡単にわかる(詳細はあとで説明します)
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
5
2分でわかるPostgreSQLのアーキテクチャ
10 Alice
10
Alice
テーブル
タプル(行)
インデックス
インデックス
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
6
2分でわかるPostgreSQLのアーキテクチャ
Alice→BobにUPDATE
10 Alice
10
Alice
テーブル
タプル(行)
インデックス
10 Bob
インデックス
10
Bob
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
7
2分でわかるPostgreSQLのアーキテクチャ
VacuumでAliceのタプルを回収
テーブル
タプル(行)
インデックス
10 Bob
インデックス
10
Bob
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
8
2分でわかるPostgreSQLのアーキテクチャ
新たにCarolのタプルをINSERT
3 Carol
3
Carol
テーブル
タプル(行)
インデックス
10 Bob
インデックス
10
Bob
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
9
なぜVacuumが必要?
Vacuumが担当している役割は基本的には2つ
1. ゴミの回収
• テーブル、インデックスの肥大化を防ぐ
• Visibility Mapの更新(Vacuumの効率化+Index Only Scanの効率化)
2. XID周回の防止
• 詳しいことは後半で
• Vacuum中は両方(ゴミ回収&XID周回の防止)行う
• 起動する(=必要な)タイミングが2つある
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
10
VACUUMとVACUUM FULL
• 基本的にはVACUUMのみでOK
• 本セッションでもVACUUMに焦点を当てて説明します
ゴミを回収する XID周回の防止 テーブルを小さくする 処理中にテーブルにアクセス可能
VACUUM ○ ○ △ ○
VACUUM
FULL ○ ○ ○ ✕
ゴミ掃除
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
12
PostgreSQLのUPDATE/DELETEはゴミを残す
• UPDATEやDELETEで削除マークを付けたタプルの領域はVacuumしないと再利用できない
• 削除”マーク”なのはまだ他のトランザクションが見る可能性があるため
• ゴミはテーブルにもインデックスにも溜まるのでどちらにもVacuumが必要
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
13
HOT更新が使えるのがベスト
10 Alice
10
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
14
HOT更新が使えるのがベスト
Alice→Bobに通常の更新
10 Alice
10
10 Bob
10
テーブルにもインデックスにも
新しいタプルを挿入する
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
15
HOT更新が使えるのがベスト
10 Alice
10
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
16
HOT更新が使えるのがベスト
Alice→BobにHOT更新
10 Alice
10
10 Bob
インデックスには触らず、

テーブル内でOld→Newにリンクを作る
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
17
HOT更新が使えるのがベスト
さらにBob→CarolにHOT更新
10 Alice
10
10 Bob
インデックスには触らず、

テーブル内でOld→Newにリンクを作る
10 Carol
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
18
HOT更新が使えるのがベスト
ページ単位でVacuumが走り、リンク内のいらないタプルを回収できる
10
• インデックスにはゴミは溜まらない
• テーブル内のタプルもVACUUMなしで
(SELECT時等)回収可能
10 Carol
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
19
HOT更新を使うには条件がある
• インデックスを貼っている列を更新しないこと
• 対策:不要なインデックスは削除する
• ページ内に新しいタプルが入る分の空き領域があること
• ページを跨いだリンクは作れない
• 対策:FILLFACTORを利用する
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
20
HOT更新が使えるのがベスト・・・だけど
• HOT更新が使えれば肥大化を防げる
• ただ使える条件が色々ある(インデックスが貼ってある列を更新しないなど)
• 現実的には全ての更新をHOT更新にするのは難しい
• Vacuumも併用してゴミを回収する
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
21
自動Vacuum
• テーブル内のゴミタプル数やその割合を元に(+XID周回防止のタイミングで)自動的に起動する
• 時間帯などで制御することはできない
• 最大でautovacuum_max_workersが同時にVacuumする(Analyzeもする)
• 遅延がかかっている
• FULLじゃない。パラレルじゃない。
• 特別な要件がなければ自動Vacuumに任せるのがおすすめ
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
22
自動Vacuumのパラメータ
ゴミタプルの数や割合で自動Vacuumを起動する
• autovacuum_vacuum_threshold/scale_factor (50/0.2)
• (threshold + (全タプル数 * scale_factor))以上のゴミタプルがあるときに自動Vacuumを
起動する
• autovaucum_vacuum_insert_threshold (0.2)
• ゴミタプル数ではなく、INSERTタプル数を元に自動Vacuumを起動する
• パラメータはテーブルごとにも設定可能
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
23
ロングトランザクション
ゴミ回収の一番の敵
• 全てのトランザクションが見ないことが分かっているデータのみをゴミとして扱える
• 1つでも見る可能性のあるトランザクションがあればそれはゴミではない
• あるトランザクションが長時間実行中だと、そのトランザクションが開始以降に削除されたタプルは回収できない
• ”ロングトランザクション”とみなされるもの
• 長時間実行中のクエリ
• 次のクエリを待っているトランザクション (idle in transaction)
• 準備済み(PREPARE済み)の2相コミット
• レプリケーション(物理・論理)のスタンバイサーバで開始されたロングトランザクション
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
24
ここまでのまとめ
• HOT更新のために不要なインデックスは削除する
• 特別な要件がなければ自動Vacuumに任せる
• ゴミタプルが回収されない?と思ったら”ロングトランザクション”の存在を確認する
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
25
(すこし脱線)UNDOログとの違い
PostgreSQL Database X
UNDO
• ゴミはページ内に放置
• Vacuumは各部屋を回っ
てゴミを回収(ゴミがあ
る部屋が事前にわかる=
Visibility Map)
• ゴミじゃなかった
(ROLLBACK)場合もそ
のままでOK
• ゴミはゴミ捨て場
(UNDOログ)へ自分で
持っていく
• ゴミ捨て場にあるゴミを
捨てるだけ
• ゴミじゃなかった
(ROLLBACK)場合は部
屋に戻す必要がある
Vacuumの動き
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
27
Vacuumの動き
FULLじゃない方のVacuum
• テーブルの先頭からゴミタプルを探す
• 見つけたゴミタプルのタプルID(TID)をメモリに保存 (Scanning
heap)
• maintenance_work_mem、autovacuum_work_mem
• テーブルを見終わったら、インデックスを1つずつVacuumしてい
く (Vacuuming indexes)
• テーブルをVacuum (Vacuuming heap)
• テーブルの末尾を切り詰める (Truncating heap)
Scanning heap
Vacuuming indexes
Vacuuming heap
Cleaning up indexes
Truncating heap
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
28
最適化やオプション
• Visibility Map
• 各テーブルが持っているマップ
• ゴミを持つページが分かる
• パラレルVacuum (PostgreSQL 13 ~ )
• 複数のインデックスを並列でVacuumする
• VACUUMコマンドのオプション
• INDEX_CLEANUP, TRUNCATEなど
• インデックスVacuumやTruncateフェーズをスキップできる
Scanning heap
Vacuuming indexes
Vacuuming heap
Cleaning up indexes
Truncating heap
モニタリング
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
30
log_autovacuum_min_duration
長時間実行した自動Vacuumの活動をログに出す(デフォルト無効)
LOG: automatic vacuum of table "postgres.public.tbl": index scans: 1
pages: 0 removed, 8850 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 1000000 removed, 1000000 remain, 0 are dead but not yet removable, oldest xmin: 737
index scan needed: 4425 pages from table (50.00% of total) had 1000000 dead item identifiers removed
index "tbl_pkey": pages: 5486 in total, 0 newly deleted, 0 currently deleted, 0 reusable
index "tbl_b_idx": pages: 5486 in total, 0 newly deleted, 0 currently deleted, 0 reusable
avg read rate: 7.576 MB/s, avg write rate: 13.567 MB/s
buffer usage: 27981 hits, 5184 misses, 9283 dirtied
WAL usage: 28638 records, 6 full page images, 15077678 bytes
system usage: CPU: user: 2.81 s, system: 0.15 s, elapsed: 5.34 s
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
31
log_autovacuum_min_duration
長時間実行した自動Vacuumの活動をログに出す(デフォルト無効)
LOG: automatic vacuum of table "postgres.public.tbl": index scans: 1
pages: 0 removed, 8850 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 1000000 removed, 1000000 remain, 0 are dead but not yet removable, oldest xmin: 737
index scan needed: 4425 pages from table (50.00% of total) had 1000000 dead item identifiers removed
index "tbl_pkey": pages: 5486 in total, 0 newly deleted, 0 currently deleted, 0 reusable
index "tbl_b_idx": pages: 5486 in total, 0 newly deleted, 0 currently deleted, 0 reusable
avg read rate: 7.576 MB/s, avg write rate: 13.567 MB/s
buffer usage: 27981 hits, 5184 misses, 9283 dirtied
WAL usage: 28638 records, 6 full page images, 15077678 bytes
system usage: CPU: user: 2.81 s, system: 0.15 s, elapsed: 5.34 s
理想は常に「1」
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
32
log_autovacuum_min_duration
長時間実行した自動Vacuumの活動をログに出す(デフォルト無効)
LOG: automatic vacuum of table "postgres.public.tbl": index scans: 1
pages: 0 removed, 8850 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 1000000 removed, 1000000 remain, 0 are dead but not yet removable, oldest xmin: 737
index scan needed: 4425 pages from table (50.00% of total) had 1000000 dead item identifiers removed
index "tbl_pkey": pages: 5486 in total, 0 newly deleted, 0 currently deleted, 0 reusable
index "tbl_b_idx": pages: 5486 in total, 0 newly deleted, 0 currently deleted, 0 reusable
avg read rate: 7.576 MB/s, avg write rate: 13.567 MB/s
buffer usage: 27981 hits, 5184 misses, 9283 dirtied
WAL usage: 28638 records, 6 full page images, 15077678 bytes
system usage: CPU: user: 2.81 s, system: 0.15 s, elapsed: 5.34 s
ロングトランザクション等で
「ゴミになりきれないタプル」は
ここにカウントされる。
少ない方が良い。
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
33
pg_stat_progress_vacuumビュー
Vacuumが今何をしているかが確認できるビュー
=# SELECT * FROM pg_stat_progress_vacuum;
-[ RECORD 1 ]———+--------------
pid | 9130
datid | 13238
datname | postgres
relid | 16384
phase | scanning heap
heap_blks_total | 8850
heap_blks_scanned | 6530
heap_blks_vacuumed | 0
index_vacuum_count | 0
max_dead_tuples | 2575350
num_dead_tuples | 475731
Scanning heap
Vacuuming indexes
Vacuuming heap
Cleaning up indexes
Truncating heap
// 現在のフェーズ
// テーブルの総ブロック数
// 何ブロックまでスキャンしたか
// 何ブロックまでVacuumしたか
// Index Vacuumの回数
// 格納できる最大のゴミタプルの数
// 現在のゴミタプルの数
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
34
pg_stat_all_tables
テーブル毎の稼働統計情報が入っている
• n_tup_upd, n_tup_hot_upd : 通常の更新とHOT更新の数
• n_dead_tup : ゴミタプルの数
• last_autovacuum, last_vacuum : 最後に(自動)Vacuumした時刻
• vacuum_count : Vacuumした回数
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
35
ここまでのまとめ
• ログはできるだけ出しておいた方が良い
• ちゃんとゴミタプルが回収されているか?
• インデックスVacuumが複数回走っていないか?
• 十分な頻度でVacuumが実行されているか?
• HOT更新はどれくらい使われているか?
XID周回の防止 ~ Freeze ~
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
37
XID周回問題
• XIDは32-bit 非負整数値(最大2^32 - 1 = 4,294,967,295)
• XIDはタプルの可視性判断に使っている
• 例)XID=100はXID=90がINSERTしたタプルは見える
• XIDが周回するとタプルの可視性判断が壊れる
• 例)XID=100はXID=(周回した後の)90のタプルは見えてはいけない
• タプル(のXIDに)Freezeマークを付けることで「XIDの値に関係なく過去」とする(=Freeze処理)
• Freezeは定期的(約21億トランザクション毎)にテーブル単位で必要
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
38
Freeze
一定量のトランザクションを消費する度にテーブル毎に定期的に必要な処理
• ゴミ回収とは別のタイミングで自動Vacuumが起動される
• 「積極的なバキューム」「aggressive vacuum」
• 通常のVacuumよりも重い
• autovacuum_freeze_xxxパラメータ等で起動タイミングを制御する
• もしFreezeがずっとされなかったら?
• 新しいXIDの払い出しが停止=データベース全体がRead-onlyになる
• DBデータが壊れる、ということはない
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
39
PostgreSQLの基本的なFreeze戦略
1.5億
2億
21億
16億
0
• テーブル毎の年齢(テーブルが作られてか
ら/FreezeされてからどれくらいXIDが消費
されたか)を管理
• テーブルが作られた直後は0歳
• トランザクションが生成されるたびに歳を
取る(約21億歳が上限)
• どれくらい古くなったかによって、Freeze
するために自動的にVacuumが起動される
• Freezeされれば若返る
Tbl1
Tbl2
Tbl3
Tbl4
次Vacuumすると
きには積極的に
Freezeするよ
Freezeするため
にVacuumを起動
するよ
Failsafeモードに
入るよ
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
40
PostgreSQLの基本的なFreeze戦略
1.5億
2億
21億
16億
0
• テーブル毎の年齢(テーブルが作られてか
ら/FreezeされてからどれくらいXIDが消費
されたか)を管理
• テーブルが作られた直後は0歳
• トランザクションが生成されるたびに歳を
取る(約21億歳が上限)
• どれくらい古くなったかによって、Freeze
するために自動的にVacuumが起動される
• Freezeされれば若返る
Tbl1
Tbl2
Tbl3
Tbl4
次Vacuumすると
きには積極的に
Freezeするよ
Freezeするため
にVacuumを起動
するよ
Failsafeモードに
入るよ
vacuum_freeze_table_age
autovacuum_freeze_max_age
vacuum_failsafe_age
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
41
Failsafeモード
PostgreSQL 14からの新機能
• 最悪な状況(Read-only化)を防ぐ機能
• 16億トランザクション消費する間に全てのテーブルの
Freeze処理が完了しなかった場合、Failsafeモードと呼ば
れるモードに入る
• Freezeすることを最優先する
• インデックスVacuumやTruncateのスキップ、遅延しない、
など
Scanning heap
Vacuuming indexes
Vacuuming heap
Cleaning up indexes
Truncating heap
トラブルシューティング&
TIPS
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
43
Vacuumしてもゴミが回収されない
• ロングトランザクションを確認する
• 長時間実行中のクエリ(pg_stat_activityのquery_start等)
• 途中で止まっているトランザクション(pg_stat_activityのstate等)
• 未完了の2相コミット(pg_prepared_xacts)
• レプリケーションのスタンバイサーバ(pg_stat_replication)
• 原因を取り除いて再度Vacuumを実行
• それでもテーブルサイズが大きくなり続ける場合は自動Vacuumが間に合ってないので、より頻度を高くするか遅延を弱くする
• テーブル・パーティショニングを検討しても良いかも
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
44
Vacuumが終わらない
• pg_stat_progress_vacuumでどこで止まっているか、なぜ遅いかを確認
• ディスクがボトルネック?遅延が効きすぎている?
• テーブルが大きすぎる→テーブル・パーティショニングを検討する
• インデックスVacuumに時間がかかっている→不要なインデックスを削除
• インデックスVacuumが何度も実行されている→maintenance_work_memが足りていない
• パラメータを設定し直して再度Vacuumをやり直すのもあり(maintenance_work_memを増やしても実行中のVacuumには効
果がない)
• 実行中のVacuumはpg_cancel_backend()でキャンセル可能(またはpg_terminate_backend())
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
45
“最速”でVacuumするには
• 遅延を無効にする(手動Vacuumではデフォルトで無効)
• maintenance_work_memを1GBに設定
• VACUUMコマンドのオプションで処理を制御
• PARALLEL N、もしくはINDEX_CLEANUP OFF
• Nはインデックス数-1。max_parallel_maintenance_workersに注意
• TRUNCATE OFF
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
46
テーブルが肥大化しすぎた
• VACUUM FULLやCLUSTERを使ってテーブルの物理サイズを小さくすることが可能
• ただし、排他ロックを取る&全インデックス再作成するので長時間なにもできなくなる
• pg_repackを使うことも検討する
• https://github.com/reorg/pg_repack
• 同時アクセスを許しながらVACUUM FULL相当のことができる
まとめ
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
48
おすすめパラメータ
• log_autovacuum_min_duration:数分くらい。ログが出すぎないよう
に
• autovacuum_max_workers:最低でも(大きいテーブルの数+2,3)はほ
しい
• max_parallel_maintenance_workers:多めでもOK。
max_worker_processesを上げるのも忘れずに
• maintenance_work_mem:デフォルトでもOK。最大で
autovacuum_max_workers個が並列で走ることに注意。巨大なテーブ
ルには大きい値を指定してもOK。
maintenance_work_mem 格納できるゴミタプル数
64MB(default) 約1100万行
256MB 約4400万行
512MB 約8900万行
1GB 約1億2000万行
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
49
今回触れていない話題
• ANALYZE、自動ANALYZE
• 遅延Vacuumのパラメータ
• マルチトランザクションID
• 各処理の細かい最適化
• Vacuumの今後の改善
© Copyright EnterpriseDB Corporation, 2021. All rights reserved.
50
最後に
• Vacuumにはゴミ掃除&XID周回の防止の2つの役割がある(起動するタイミングも2つ)
• まずはHOT更新を意識して不要なインデックスは削除する
• モニタリグしながら適宜調整していくべし
• 殆どのパラメータはテーブル単位で設定が可能
• 状況が悪くなっていることを把握する&そうなったときの対処法を用意する
• Vacuumの改善点も募集中です!
Thank you

E-mail: masahiko.sawada@enterprisedb.com

Twitter: @masahiko_sawada

More Related Content

What's hot

オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
NTT DATA Technology & Innovation
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
Masahiko Sawada
 
pg_bigmで全文検索するときに気を付けたい5つのポイント(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_bigmで全文検索するときに気を付けたい5つのポイント(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)pg_bigmで全文検索するときに気を付けたい5つのポイント(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_bigmで全文検索するときに気を付けたい5つのポイント(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
PostgreSQL 9.6 新機能紹介
PostgreSQL 9.6 新機能紹介PostgreSQL 9.6 新機能紹介
PostgreSQL 9.6 新機能紹介
Masahiko Sawada
 
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
NTT DATA Technology & Innovation
 
PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)
NTT DATA Technology & Innovation
 
pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
 
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界
Yoshinori Nakanishi
 
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
 
Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会Masahiko Sawada
 
Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
NTT DATA Technology & Innovation
 
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説
Masahiko Sawada
 
PostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめPostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめ
Ohyama Masanori
 
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
NTT DATA Technology & Innovation
 
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
NTT DATA Technology & Innovation
 
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
NTT DATA Technology & Innovation
 

What's hot (20)

オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
 
pg_bigmで全文検索するときに気を付けたい5つのポイント(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_bigmで全文検索するときに気を付けたい5つのポイント(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)pg_bigmで全文検索するときに気を付けたい5つのポイント(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_bigmで全文検索するときに気を付けたい5つのポイント(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
PostgreSQL 9.6 新機能紹介
PostgreSQL 9.6 新機能紹介PostgreSQL 9.6 新機能紹介
PostgreSQL 9.6 新機能紹介
 
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
 
PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)
 
pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
 
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界
 
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
 
Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会
 
Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
Memoizeの仕組み(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
 
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説
 
PostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめPostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめ
 
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
 
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
 
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
 

Similar to Vacuum徹底解説

HandlerSocket plugin for MySQL
HandlerSocket plugin for MySQLHandlerSocket plugin for MySQL
HandlerSocket plugin for MySQLakirahiguchi
 
C16 45分でわかるPostgreSQLの仕組み by 山田努
C16 45分でわかるPostgreSQLの仕組み by 山田努C16 45分でわかるPostgreSQLの仕組み by 山田努
C16 45分でわかるPostgreSQLの仕組み by 山田努Insight Technology, Inc.
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Yoshinori Matsunobu
 
Chugoku db 17th-postgresql-9.6
Chugoku db 17th-postgresql-9.6Chugoku db 17th-postgresql-9.6
Chugoku db 17th-postgresql-9.6
Toshi Harada
 
Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)
Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)
Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
Oracle Cloud Infrastructure:2021年5月度サービス・アップデート
Oracle Cloud Infrastructure:2021年5月度サービス・アップデートOracle Cloud Infrastructure:2021年5月度サービス・アップデート
Oracle Cloud Infrastructure:2021年5月度サービス・アップデート
オラクルエンジニア通信
 
YAPC::Asia 2008 Tokyo - Pathtraq - building a computation-centric web service
YAPC::Asia 2008 Tokyo - Pathtraq - building a computation-centric web serviceYAPC::Asia 2008 Tokyo - Pathtraq - building a computation-centric web service
YAPC::Asia 2008 Tokyo - Pathtraq - building a computation-centric web service
Kazuho Oku
 
Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14Masahiro Nagano
 
[DI15] Build 2017 Updates ~ Azure Database for MySQL/PostgreSQL 最速紹介
[DI15] Build 2017 Updates ~ Azure Database for MySQL/PostgreSQL 最速紹介[DI15] Build 2017 Updates ~ Azure Database for MySQL/PostgreSQL 最速紹介
[DI15] Build 2017 Updates ~ Azure Database for MySQL/PostgreSQL 最速紹介
de:code 2017
 
オンプレのDbaがazureのデータベースを使ってみた
オンプレのDbaがazureのデータベースを使ってみたオンプレのDbaがazureのデータベースを使ってみた
オンプレのDbaがazureのデータベースを使ってみたMasayuki Ozawa
 
システムパフォーマンス勉強会#5
システムパフォーマンス勉強会#5システムパフォーマンス勉強会#5
システムパフォーマンス勉強会#5
shingo suzuki
 
PostgreSQL 12の話
PostgreSQL 12の話PostgreSQL 12の話
PostgreSQL 12の話
Masahiko Sawada
 
Intel TSX HLE を触ってみた x86opti
Intel TSX HLE を触ってみた x86optiIntel TSX HLE を触ってみた x86opti
Intel TSX HLE を触ってみた x86opti
Takashi Hoshino
 
Handlersocket 20110517
Handlersocket 20110517Handlersocket 20110517
Handlersocket 20110517akirahiguchi
 
AWSのデータベースサービス全体像
AWSのデータベースサービス全体像AWSのデータベースサービス全体像
AWSのデータベースサービス全体像
Amazon Web Services Japan
 
Nginx
NginxNginx
NGS解析を始めた時にぶつかりがちな小さい壁あれこれ
NGS解析を始めた時にぶつかりがちな小さい壁あれこれNGS解析を始めた時にぶつかりがちな小さい壁あれこれ
NGS解析を始めた時にぶつかりがちな小さい壁あれこれ
DNA Data Bank of Japan center
 
[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~
[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~
[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~
Naoki (Neo) SATO
 
db tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとは
db tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとはdb tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとは
db tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとはKoji Shinkubo
 

Similar to Vacuum徹底解説 (20)

HandlerSocket plugin for MySQL
HandlerSocket plugin for MySQLHandlerSocket plugin for MySQL
HandlerSocket plugin for MySQL
 
C16 45分でわかるPostgreSQLの仕組み by 山田努
C16 45分でわかるPostgreSQLの仕組み by 山田努C16 45分でわかるPostgreSQLの仕組み by 山田努
C16 45分でわかるPostgreSQLの仕組み by 山田努
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
 
Chugoku db 17th-postgresql-9.6
Chugoku db 17th-postgresql-9.6Chugoku db 17th-postgresql-9.6
Chugoku db 17th-postgresql-9.6
 
Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)
Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)
Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
Oracle Cloud Infrastructure:2021年5月度サービス・アップデート
Oracle Cloud Infrastructure:2021年5月度サービス・アップデートOracle Cloud Infrastructure:2021年5月度サービス・アップデート
Oracle Cloud Infrastructure:2021年5月度サービス・アップデート
 
YAPC::Asia 2008 Tokyo - Pathtraq - building a computation-centric web service
YAPC::Asia 2008 Tokyo - Pathtraq - building a computation-centric web serviceYAPC::Asia 2008 Tokyo - Pathtraq - building a computation-centric web service
YAPC::Asia 2008 Tokyo - Pathtraq - building a computation-centric web service
 
Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14
 
[DI15] Build 2017 Updates ~ Azure Database for MySQL/PostgreSQL 最速紹介
[DI15] Build 2017 Updates ~ Azure Database for MySQL/PostgreSQL 最速紹介[DI15] Build 2017 Updates ~ Azure Database for MySQL/PostgreSQL 最速紹介
[DI15] Build 2017 Updates ~ Azure Database for MySQL/PostgreSQL 最速紹介
 
オンプレのDbaがazureのデータベースを使ってみた
オンプレのDbaがazureのデータベースを使ってみたオンプレのDbaがazureのデータベースを使ってみた
オンプレのDbaがazureのデータベースを使ってみた
 
システムパフォーマンス勉強会#5
システムパフォーマンス勉強会#5システムパフォーマンス勉強会#5
システムパフォーマンス勉強会#5
 
PostgreSQL 12の話
PostgreSQL 12の話PostgreSQL 12の話
PostgreSQL 12の話
 
Intel TSX HLE を触ってみた x86opti
Intel TSX HLE を触ってみた x86optiIntel TSX HLE を触ってみた x86opti
Intel TSX HLE を触ってみた x86opti
 
Handlersocket 20110517
Handlersocket 20110517Handlersocket 20110517
Handlersocket 20110517
 
AWSのデータベースサービス全体像
AWSのデータベースサービス全体像AWSのデータベースサービス全体像
AWSのデータベースサービス全体像
 
Nginx
NginxNginx
Nginx
 
NGS解析を始めた時にぶつかりがちな小さい壁あれこれ
NGS解析を始めた時にぶつかりがちな小さい壁あれこれNGS解析を始めた時にぶつかりがちな小さい壁あれこれ
NGS解析を始めた時にぶつかりがちな小さい壁あれこれ
 
20150630_MySQL勉強会
20150630_MySQL勉強会20150630_MySQL勉強会
20150630_MySQL勉強会
 
[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~
[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~
[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~
 
db tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとは
db tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとはdb tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとは
db tech showcase_2014_A14_Actian Vectorで得られる、BIにおける真のパフォーマンスとは
 

More from Masahiko Sawada

PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説
Masahiko Sawada
 
行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...
行ロックと「LOG:  process 12345 still waiting for ShareLock on transaction 710 afte...行ロックと「LOG:  process 12345 still waiting for ShareLock on transaction 710 afte...
行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...
Masahiko Sawada
 
Transparent Data Encryption in PostgreSQL
Transparent Data Encryption in PostgreSQLTransparent Data Encryption in PostgreSQL
Transparent Data Encryption in PostgreSQL
Masahiko Sawada
 
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -
Masahiko Sawada
 
Transparent Data Encryption in PostgreSQL and Integration with Key Management...
Transparent Data Encryption in PostgreSQL and Integration with Key Management...Transparent Data Encryption in PostgreSQL and Integration with Key Management...
Transparent Data Encryption in PostgreSQL and Integration with Key Management...
Masahiko Sawada
 
Bloat and Fragmentation in PostgreSQL
Bloat and Fragmentation in PostgreSQLBloat and Fragmentation in PostgreSQL
Bloat and Fragmentation in PostgreSQL
Masahiko Sawada
 
Database Encryption and Key Management for PostgreSQL - Principles and Consid...
Database Encryption and Key Management for PostgreSQL - Principles and Consid...Database Encryption and Key Management for PostgreSQL - Principles and Consid...
Database Encryption and Key Management for PostgreSQL - Principles and Consid...
Masahiko Sawada
 
Vacuum more efficient than ever
Vacuum more efficient than everVacuum more efficient than ever
Vacuum more efficient than ever
Masahiko Sawada
 
Vacuumとzheap
VacuumとzheapVacuumとzheap
Vacuumとzheap
Masahiko Sawada
 
Parallel Vacuum
Parallel VacuumParallel Vacuum
Parallel Vacuum
Masahiko Sawada
 
PostgreSQLでスケールアウト
PostgreSQLでスケールアウトPostgreSQLでスケールアウト
PostgreSQLでスケールアウト
Masahiko Sawada
 
OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~
OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~
OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~
Masahiko Sawada
 
PostgreSQL10徹底解説
PostgreSQL10徹底解説PostgreSQL10徹底解説
PostgreSQL10徹底解説
Masahiko Sawada
 
FDW-based Sharding Update and Future
FDW-based Sharding Update and FutureFDW-based Sharding Update and Future
FDW-based Sharding Update and Future
Masahiko Sawada
 
What’s new in 9.6, by PostgreSQL contributor
What’s new in 9.6, by PostgreSQL contributorWhat’s new in 9.6, by PostgreSQL contributor
What’s new in 9.6, by PostgreSQL contributor
Masahiko Sawada
 
pg_bigmと類似度検索
pg_bigmと類似度検索pg_bigmと類似度検索
pg_bigmと類似度検索
Masahiko Sawada
 
pg_bigmを触り始めた人に伝えたいこと
pg_bigmを触り始めた人に伝えたいことpg_bigmを触り始めた人に伝えたいこと
pg_bigmを触り始めた人に伝えたいこと
Masahiko Sawada
 
Introduction VAUUM, Freezing, XID wraparound
Introduction VAUUM, Freezing, XID wraparoundIntroduction VAUUM, Freezing, XID wraparound
Introduction VAUUM, Freezing, XID wraparound
Masahiko Sawada
 
XID周回問題に潜む別の問題
XID周回問題に潜む別の問題XID周回問題に潜む別の問題
XID周回問題に潜む別の問題
Masahiko Sawada
 
PostgreSQL共有バッファと関連ツール
PostgreSQL共有バッファと関連ツールPostgreSQL共有バッファと関連ツール
PostgreSQL共有バッファと関連ツール
Masahiko Sawada
 

More from Masahiko Sawada (20)

PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説
 
行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...
行ロックと「LOG:  process 12345 still waiting for ShareLock on transaction 710 afte...行ロックと「LOG:  process 12345 still waiting for ShareLock on transaction 710 afte...
行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...
 
Transparent Data Encryption in PostgreSQL
Transparent Data Encryption in PostgreSQLTransparent Data Encryption in PostgreSQL
Transparent Data Encryption in PostgreSQL
 
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -
 
Transparent Data Encryption in PostgreSQL and Integration with Key Management...
Transparent Data Encryption in PostgreSQL and Integration with Key Management...Transparent Data Encryption in PostgreSQL and Integration with Key Management...
Transparent Data Encryption in PostgreSQL and Integration with Key Management...
 
Bloat and Fragmentation in PostgreSQL
Bloat and Fragmentation in PostgreSQLBloat and Fragmentation in PostgreSQL
Bloat and Fragmentation in PostgreSQL
 
Database Encryption and Key Management for PostgreSQL - Principles and Consid...
Database Encryption and Key Management for PostgreSQL - Principles and Consid...Database Encryption and Key Management for PostgreSQL - Principles and Consid...
Database Encryption and Key Management for PostgreSQL - Principles and Consid...
 
Vacuum more efficient than ever
Vacuum more efficient than everVacuum more efficient than ever
Vacuum more efficient than ever
 
Vacuumとzheap
VacuumとzheapVacuumとzheap
Vacuumとzheap
 
Parallel Vacuum
Parallel VacuumParallel Vacuum
Parallel Vacuum
 
PostgreSQLでスケールアウト
PostgreSQLでスケールアウトPostgreSQLでスケールアウト
PostgreSQLでスケールアウト
 
OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~
OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~
OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~
 
PostgreSQL10徹底解説
PostgreSQL10徹底解説PostgreSQL10徹底解説
PostgreSQL10徹底解説
 
FDW-based Sharding Update and Future
FDW-based Sharding Update and FutureFDW-based Sharding Update and Future
FDW-based Sharding Update and Future
 
What’s new in 9.6, by PostgreSQL contributor
What’s new in 9.6, by PostgreSQL contributorWhat’s new in 9.6, by PostgreSQL contributor
What’s new in 9.6, by PostgreSQL contributor
 
pg_bigmと類似度検索
pg_bigmと類似度検索pg_bigmと類似度検索
pg_bigmと類似度検索
 
pg_bigmを触り始めた人に伝えたいこと
pg_bigmを触り始めた人に伝えたいことpg_bigmを触り始めた人に伝えたいこと
pg_bigmを触り始めた人に伝えたいこと
 
Introduction VAUUM, Freezing, XID wraparound
Introduction VAUUM, Freezing, XID wraparoundIntroduction VAUUM, Freezing, XID wraparound
Introduction VAUUM, Freezing, XID wraparound
 
XID周回問題に潜む別の問題
XID周回問題に潜む別の問題XID周回問題に潜む別の問題
XID周回問題に潜む別の問題
 
PostgreSQL共有バッファと関連ツール
PostgreSQL共有バッファと関連ツールPostgreSQL共有バッファと関連ツール
PostgreSQL共有バッファと関連ツール
 

Recently uploaded

ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMMハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
osamut
 
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
iPride Co., Ltd.
 
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
sugiuralab
 
iMacwoSu_Gong_de_barabaranishitaHua_.pptx
iMacwoSu_Gong_de_barabaranishitaHua_.pptxiMacwoSu_Gong_de_barabaranishitaHua_.pptx
iMacwoSu_Gong_de_barabaranishitaHua_.pptx
kitamisetagayaxxx
 
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
Yuki Miyazaki
 
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライドHumanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
tazaki1
 
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT vol112 発表資料)
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT  vol112 発表資料)ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT  vol112 発表資料)
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT vol112 発表資料)
Takuya Minagawa
 
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
Shinichi Hirauchi
 
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
ARISE analytics
 
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
Osaka University
 
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobodyロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
azuma satoshi
 
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
Osaka University
 
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
Seiya Shimabukuro
 
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDDなぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
ssuserfcafd1
 

Recently uploaded (14)

ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMMハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
 
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
 
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
 
iMacwoSu_Gong_de_barabaranishitaHua_.pptx
iMacwoSu_Gong_de_barabaranishitaHua_.pptxiMacwoSu_Gong_de_barabaranishitaHua_.pptx
iMacwoSu_Gong_de_barabaranishitaHua_.pptx
 
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
 
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライドHumanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
 
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT vol112 発表資料)
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT  vol112 発表資料)ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT  vol112 発表資料)
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT vol112 発表資料)
 
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
 
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
 
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
 
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobodyロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
 
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
 
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
 
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDDなぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
 

Vacuum徹底解説

  • 2. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 2 Vacuumは最も重要な機能の一つ • PostgreSQL = Vacuumみたいなところもある • 仕組みや特性を理解する • トラブル時も慌てなくなるし、応用も効く
  • 3. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 3 目次 • PostgreSQLのアーキテクチャを簡単に紹介 • なぜVacuumが必要?どうやって動くの? • ゴミ掃除 • XID周回の防止(FREEZE) • おすすめの設定パラメータ • モニタリング • トラブルシューティング&TIPS
  • 4. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 4 用語説明 • ページ/ブロック • テーブル、インデックスを構成するデータ。PostgreSQLのI/Oする単位。デフォルトでは1ページは 8kB。 • トランザクションID(XID) • 各トランザクションに付与される単調増加する非負整数 • Visibility Map • 各テーブルに付いているマップ。「ゴミを持つブロック」が簡単にわかる(詳細はあとで説明します)
  • 5. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 5 2分でわかるPostgreSQLのアーキテクチャ 10 Alice 10 Alice テーブル タプル(行) インデックス インデックス
  • 6. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 6 2分でわかるPostgreSQLのアーキテクチャ Alice→BobにUPDATE 10 Alice 10 Alice テーブル タプル(行) インデックス 10 Bob インデックス 10 Bob
  • 7. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 7 2分でわかるPostgreSQLのアーキテクチャ VacuumでAliceのタプルを回収 テーブル タプル(行) インデックス 10 Bob インデックス 10 Bob
  • 8. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 8 2分でわかるPostgreSQLのアーキテクチャ 新たにCarolのタプルをINSERT 3 Carol 3 Carol テーブル タプル(行) インデックス 10 Bob インデックス 10 Bob
  • 9. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 9 なぜVacuumが必要? Vacuumが担当している役割は基本的には2つ 1. ゴミの回収 • テーブル、インデックスの肥大化を防ぐ • Visibility Mapの更新(Vacuumの効率化+Index Only Scanの効率化) 2. XID周回の防止 • 詳しいことは後半で • Vacuum中は両方(ゴミ回収&XID周回の防止)行う • 起動する(=必要な)タイミングが2つある
  • 10. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 10 VACUUMとVACUUM FULL • 基本的にはVACUUMのみでOK • 本セッションでもVACUUMに焦点を当てて説明します ゴミを回収する XID周回の防止 テーブルを小さくする 処理中にテーブルにアクセス可能 VACUUM ○ ○ △ ○ VACUUM FULL ○ ○ ○ ✕
  • 12. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 12 PostgreSQLのUPDATE/DELETEはゴミを残す • UPDATEやDELETEで削除マークを付けたタプルの領域はVacuumしないと再利用できない • 削除”マーク”なのはまだ他のトランザクションが見る可能性があるため • ゴミはテーブルにもインデックスにも溜まるのでどちらにもVacuumが必要
  • 13. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 13 HOT更新が使えるのがベスト 10 Alice 10
  • 14. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 14 HOT更新が使えるのがベスト Alice→Bobに通常の更新 10 Alice 10 10 Bob 10 テーブルにもインデックスにも 新しいタプルを挿入する
  • 15. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 15 HOT更新が使えるのがベスト 10 Alice 10
  • 16. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 16 HOT更新が使えるのがベスト Alice→BobにHOT更新 10 Alice 10 10 Bob インデックスには触らず、
 テーブル内でOld→Newにリンクを作る
  • 17. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 17 HOT更新が使えるのがベスト さらにBob→CarolにHOT更新 10 Alice 10 10 Bob インデックスには触らず、
 テーブル内でOld→Newにリンクを作る 10 Carol
  • 18. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 18 HOT更新が使えるのがベスト ページ単位でVacuumが走り、リンク内のいらないタプルを回収できる 10 • インデックスにはゴミは溜まらない • テーブル内のタプルもVACUUMなしで (SELECT時等)回収可能 10 Carol
  • 19. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 19 HOT更新を使うには条件がある • インデックスを貼っている列を更新しないこと • 対策:不要なインデックスは削除する • ページ内に新しいタプルが入る分の空き領域があること • ページを跨いだリンクは作れない • 対策:FILLFACTORを利用する
  • 20. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 20 HOT更新が使えるのがベスト・・・だけど • HOT更新が使えれば肥大化を防げる • ただ使える条件が色々ある(インデックスが貼ってある列を更新しないなど) • 現実的には全ての更新をHOT更新にするのは難しい • Vacuumも併用してゴミを回収する
  • 21. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 21 自動Vacuum • テーブル内のゴミタプル数やその割合を元に(+XID周回防止のタイミングで)自動的に起動する • 時間帯などで制御することはできない • 最大でautovacuum_max_workersが同時にVacuumする(Analyzeもする) • 遅延がかかっている • FULLじゃない。パラレルじゃない。 • 特別な要件がなければ自動Vacuumに任せるのがおすすめ
  • 22. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 22 自動Vacuumのパラメータ ゴミタプルの数や割合で自動Vacuumを起動する • autovacuum_vacuum_threshold/scale_factor (50/0.2) • (threshold + (全タプル数 * scale_factor))以上のゴミタプルがあるときに自動Vacuumを 起動する • autovaucum_vacuum_insert_threshold (0.2) • ゴミタプル数ではなく、INSERTタプル数を元に自動Vacuumを起動する • パラメータはテーブルごとにも設定可能
  • 23. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 23 ロングトランザクション ゴミ回収の一番の敵 • 全てのトランザクションが見ないことが分かっているデータのみをゴミとして扱える • 1つでも見る可能性のあるトランザクションがあればそれはゴミではない • あるトランザクションが長時間実行中だと、そのトランザクションが開始以降に削除されたタプルは回収できない • ”ロングトランザクション”とみなされるもの • 長時間実行中のクエリ • 次のクエリを待っているトランザクション (idle in transaction) • 準備済み(PREPARE済み)の2相コミット • レプリケーション(物理・論理)のスタンバイサーバで開始されたロングトランザクション
  • 24. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 24 ここまでのまとめ • HOT更新のために不要なインデックスは削除する • 特別な要件がなければ自動Vacuumに任せる • ゴミタプルが回収されない?と思ったら”ロングトランザクション”の存在を確認する
  • 25. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 25 (すこし脱線)UNDOログとの違い PostgreSQL Database X UNDO • ゴミはページ内に放置 • Vacuumは各部屋を回っ てゴミを回収(ゴミがあ る部屋が事前にわかる= Visibility Map) • ゴミじゃなかった (ROLLBACK)場合もそ のままでOK • ゴミはゴミ捨て場 (UNDOログ)へ自分で 持っていく • ゴミ捨て場にあるゴミを 捨てるだけ • ゴミじゃなかった (ROLLBACK)場合は部 屋に戻す必要がある
  • 27. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 27 Vacuumの動き FULLじゃない方のVacuum • テーブルの先頭からゴミタプルを探す • 見つけたゴミタプルのタプルID(TID)をメモリに保存 (Scanning heap) • maintenance_work_mem、autovacuum_work_mem • テーブルを見終わったら、インデックスを1つずつVacuumしてい く (Vacuuming indexes) • テーブルをVacuum (Vacuuming heap) • テーブルの末尾を切り詰める (Truncating heap) Scanning heap Vacuuming indexes Vacuuming heap Cleaning up indexes Truncating heap
  • 28. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 28 最適化やオプション • Visibility Map • 各テーブルが持っているマップ • ゴミを持つページが分かる • パラレルVacuum (PostgreSQL 13 ~ ) • 複数のインデックスを並列でVacuumする • VACUUMコマンドのオプション • INDEX_CLEANUP, TRUNCATEなど • インデックスVacuumやTruncateフェーズをスキップできる Scanning heap Vacuuming indexes Vacuuming heap Cleaning up indexes Truncating heap
  • 30. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 30 log_autovacuum_min_duration 長時間実行した自動Vacuumの活動をログに出す(デフォルト無効) LOG: automatic vacuum of table "postgres.public.tbl": index scans: 1 pages: 0 removed, 8850 remain, 0 skipped due to pins, 0 skipped frozen tuples: 1000000 removed, 1000000 remain, 0 are dead but not yet removable, oldest xmin: 737 index scan needed: 4425 pages from table (50.00% of total) had 1000000 dead item identifiers removed index "tbl_pkey": pages: 5486 in total, 0 newly deleted, 0 currently deleted, 0 reusable index "tbl_b_idx": pages: 5486 in total, 0 newly deleted, 0 currently deleted, 0 reusable avg read rate: 7.576 MB/s, avg write rate: 13.567 MB/s buffer usage: 27981 hits, 5184 misses, 9283 dirtied WAL usage: 28638 records, 6 full page images, 15077678 bytes system usage: CPU: user: 2.81 s, system: 0.15 s, elapsed: 5.34 s
  • 31. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 31 log_autovacuum_min_duration 長時間実行した自動Vacuumの活動をログに出す(デフォルト無効) LOG: automatic vacuum of table "postgres.public.tbl": index scans: 1 pages: 0 removed, 8850 remain, 0 skipped due to pins, 0 skipped frozen tuples: 1000000 removed, 1000000 remain, 0 are dead but not yet removable, oldest xmin: 737 index scan needed: 4425 pages from table (50.00% of total) had 1000000 dead item identifiers removed index "tbl_pkey": pages: 5486 in total, 0 newly deleted, 0 currently deleted, 0 reusable index "tbl_b_idx": pages: 5486 in total, 0 newly deleted, 0 currently deleted, 0 reusable avg read rate: 7.576 MB/s, avg write rate: 13.567 MB/s buffer usage: 27981 hits, 5184 misses, 9283 dirtied WAL usage: 28638 records, 6 full page images, 15077678 bytes system usage: CPU: user: 2.81 s, system: 0.15 s, elapsed: 5.34 s 理想は常に「1」
  • 32. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 32 log_autovacuum_min_duration 長時間実行した自動Vacuumの活動をログに出す(デフォルト無効) LOG: automatic vacuum of table "postgres.public.tbl": index scans: 1 pages: 0 removed, 8850 remain, 0 skipped due to pins, 0 skipped frozen tuples: 1000000 removed, 1000000 remain, 0 are dead but not yet removable, oldest xmin: 737 index scan needed: 4425 pages from table (50.00% of total) had 1000000 dead item identifiers removed index "tbl_pkey": pages: 5486 in total, 0 newly deleted, 0 currently deleted, 0 reusable index "tbl_b_idx": pages: 5486 in total, 0 newly deleted, 0 currently deleted, 0 reusable avg read rate: 7.576 MB/s, avg write rate: 13.567 MB/s buffer usage: 27981 hits, 5184 misses, 9283 dirtied WAL usage: 28638 records, 6 full page images, 15077678 bytes system usage: CPU: user: 2.81 s, system: 0.15 s, elapsed: 5.34 s ロングトランザクション等で 「ゴミになりきれないタプル」は ここにカウントされる。 少ない方が良い。
  • 33. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 33 pg_stat_progress_vacuumビュー Vacuumが今何をしているかが確認できるビュー =# SELECT * FROM pg_stat_progress_vacuum; -[ RECORD 1 ]———+-------------- pid | 9130 datid | 13238 datname | postgres relid | 16384 phase | scanning heap heap_blks_total | 8850 heap_blks_scanned | 6530 heap_blks_vacuumed | 0 index_vacuum_count | 0 max_dead_tuples | 2575350 num_dead_tuples | 475731 Scanning heap Vacuuming indexes Vacuuming heap Cleaning up indexes Truncating heap // 現在のフェーズ // テーブルの総ブロック数 // 何ブロックまでスキャンしたか // 何ブロックまでVacuumしたか // Index Vacuumの回数 // 格納できる最大のゴミタプルの数 // 現在のゴミタプルの数
  • 34. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 34 pg_stat_all_tables テーブル毎の稼働統計情報が入っている • n_tup_upd, n_tup_hot_upd : 通常の更新とHOT更新の数 • n_dead_tup : ゴミタプルの数 • last_autovacuum, last_vacuum : 最後に(自動)Vacuumした時刻 • vacuum_count : Vacuumした回数
  • 35. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 35 ここまでのまとめ • ログはできるだけ出しておいた方が良い • ちゃんとゴミタプルが回収されているか? • インデックスVacuumが複数回走っていないか? • 十分な頻度でVacuumが実行されているか? • HOT更新はどれくらい使われているか?
  • 37. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 37 XID周回問題 • XIDは32-bit 非負整数値(最大2^32 - 1 = 4,294,967,295) • XIDはタプルの可視性判断に使っている • 例)XID=100はXID=90がINSERTしたタプルは見える • XIDが周回するとタプルの可視性判断が壊れる • 例)XID=100はXID=(周回した後の)90のタプルは見えてはいけない • タプル(のXIDに)Freezeマークを付けることで「XIDの値に関係なく過去」とする(=Freeze処理) • Freezeは定期的(約21億トランザクション毎)にテーブル単位で必要
  • 38. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 38 Freeze 一定量のトランザクションを消費する度にテーブル毎に定期的に必要な処理 • ゴミ回収とは別のタイミングで自動Vacuumが起動される • 「積極的なバキューム」「aggressive vacuum」 • 通常のVacuumよりも重い • autovacuum_freeze_xxxパラメータ等で起動タイミングを制御する • もしFreezeがずっとされなかったら? • 新しいXIDの払い出しが停止=データベース全体がRead-onlyになる • DBデータが壊れる、ということはない
  • 39. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 39 PostgreSQLの基本的なFreeze戦略 1.5億 2億 21億 16億 0 • テーブル毎の年齢(テーブルが作られてか ら/FreezeされてからどれくらいXIDが消費 されたか)を管理 • テーブルが作られた直後は0歳 • トランザクションが生成されるたびに歳を 取る(約21億歳が上限) • どれくらい古くなったかによって、Freeze するために自動的にVacuumが起動される • Freezeされれば若返る Tbl1 Tbl2 Tbl3 Tbl4 次Vacuumすると きには積極的に Freezeするよ Freezeするため にVacuumを起動 するよ Failsafeモードに 入るよ
  • 40. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 40 PostgreSQLの基本的なFreeze戦略 1.5億 2億 21億 16億 0 • テーブル毎の年齢(テーブルが作られてか ら/FreezeされてからどれくらいXIDが消費 されたか)を管理 • テーブルが作られた直後は0歳 • トランザクションが生成されるたびに歳を 取る(約21億歳が上限) • どれくらい古くなったかによって、Freeze するために自動的にVacuumが起動される • Freezeされれば若返る Tbl1 Tbl2 Tbl3 Tbl4 次Vacuumすると きには積極的に Freezeするよ Freezeするため にVacuumを起動 するよ Failsafeモードに 入るよ vacuum_freeze_table_age autovacuum_freeze_max_age vacuum_failsafe_age
  • 41. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 41 Failsafeモード PostgreSQL 14からの新機能 • 最悪な状況(Read-only化)を防ぐ機能 • 16億トランザクション消費する間に全てのテーブルの Freeze処理が完了しなかった場合、Failsafeモードと呼ば れるモードに入る • Freezeすることを最優先する • インデックスVacuumやTruncateのスキップ、遅延しない、 など Scanning heap Vacuuming indexes Vacuuming heap Cleaning up indexes Truncating heap
  • 43. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 43 Vacuumしてもゴミが回収されない • ロングトランザクションを確認する • 長時間実行中のクエリ(pg_stat_activityのquery_start等) • 途中で止まっているトランザクション(pg_stat_activityのstate等) • 未完了の2相コミット(pg_prepared_xacts) • レプリケーションのスタンバイサーバ(pg_stat_replication) • 原因を取り除いて再度Vacuumを実行 • それでもテーブルサイズが大きくなり続ける場合は自動Vacuumが間に合ってないので、より頻度を高くするか遅延を弱くする • テーブル・パーティショニングを検討しても良いかも
  • 44. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 44 Vacuumが終わらない • pg_stat_progress_vacuumでどこで止まっているか、なぜ遅いかを確認 • ディスクがボトルネック?遅延が効きすぎている? • テーブルが大きすぎる→テーブル・パーティショニングを検討する • インデックスVacuumに時間がかかっている→不要なインデックスを削除 • インデックスVacuumが何度も実行されている→maintenance_work_memが足りていない • パラメータを設定し直して再度Vacuumをやり直すのもあり(maintenance_work_memを増やしても実行中のVacuumには効 果がない) • 実行中のVacuumはpg_cancel_backend()でキャンセル可能(またはpg_terminate_backend())
  • 45. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 45 “最速”でVacuumするには • 遅延を無効にする(手動Vacuumではデフォルトで無効) • maintenance_work_memを1GBに設定 • VACUUMコマンドのオプションで処理を制御 • PARALLEL N、もしくはINDEX_CLEANUP OFF • Nはインデックス数-1。max_parallel_maintenance_workersに注意 • TRUNCATE OFF
  • 46. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 46 テーブルが肥大化しすぎた • VACUUM FULLやCLUSTERを使ってテーブルの物理サイズを小さくすることが可能 • ただし、排他ロックを取る&全インデックス再作成するので長時間なにもできなくなる • pg_repackを使うことも検討する • https://github.com/reorg/pg_repack • 同時アクセスを許しながらVACUUM FULL相当のことができる
  • 48. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 48 おすすめパラメータ • log_autovacuum_min_duration:数分くらい。ログが出すぎないよう に • autovacuum_max_workers:最低でも(大きいテーブルの数+2,3)はほ しい • max_parallel_maintenance_workers:多めでもOK。 max_worker_processesを上げるのも忘れずに • maintenance_work_mem:デフォルトでもOK。最大で autovacuum_max_workers個が並列で走ることに注意。巨大なテーブ ルには大きい値を指定してもOK。 maintenance_work_mem 格納できるゴミタプル数 64MB(default) 約1100万行 256MB 約4400万行 512MB 約8900万行 1GB 約1億2000万行
  • 49. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 49 今回触れていない話題 • ANALYZE、自動ANALYZE • 遅延Vacuumのパラメータ • マルチトランザクションID • 各処理の細かい最適化 • Vacuumの今後の改善
  • 50. © Copyright EnterpriseDB Corporation, 2021. All rights reserved. 50 最後に • Vacuumにはゴミ掃除&XID周回の防止の2つの役割がある(起動するタイミングも2つ) • まずはHOT更新を意識して不要なインデックスは削除する • モニタリグしながら適宜調整していくべし • 殆どのパラメータはテーブル単位で設定が可能 • 状況が悪くなっていることを把握する&そうなったときの対処法を用意する • Vacuumの改善点も募集中です!