バージョン17からのpg_stat_bgwriter (第48回 PostgreSQLアンカンファレンス 発表資料)
- 1. © 2024 NTT DATA Group Corporation © 2024 NTT DATA Group Corporation 第48回PostgreSQLアンカンファレンス バージョン17からの pg_stat_bgwriter 2024年8月29日 NTTデータグループ 鳥越 淳
- 2. © 2024 NTT DATA Group Corporation 2 自己紹介 • 鳥越 淳(とりこし あつし) • 2008年頃からオープンソースを扱う業務に従事 • PostgreSQLは9.6頃から • 『PostgreSQL徹底入門 第4版』(翔泳社) 8～13章執筆
- 3. © 2024 NTT DATA Group Corporation 3 本講演について • 今秋リリース予定のPostgreSQL 17に関連する話です。2024年8月時点の情報なので、将来的に変更 される可能性がある点ご了承ください • その他、記載されている会社名、商品名、又はサービス名は、 各社の登録商標又は商標です
- 4. © 2024 NTT DATA Group Corporation 4 background writerってなんだっけ？
- 5. © 2024 NTT DATA Group Corporation 5 前提: 共有バッファの使い方超概要 • PostgreSQLでは、基本的にバックエンド※からの読み書きいずれも共有バッファを経由する • 参照クエリの場合: • 共有バッファ上にデータがあればそれを読み込む(キャッシュヒット) • 共有バッファ上にデータがなければ、ストレージにアクセスし共有バッファ上に展開(キャッシュミス) 共有バッファ バックエンド バックエンド ストレージ キャッシュ ヒット キャッシュ ミス ※バックエンド: クライアントのクエリを処理するプロセス
- 6. © 2024 NTT DATA Group Corporation 6 前提: 共有バッファの使い方超概要 • PostgreSQLでは、基本的にバックエンドからの読み書きいずれも共有バッファを経由する • 更新クエリの場合: • バックエンドは共有バッファに書き込むだけで、ストレージへの永続化はしない 一方でWALは通常ストレージに永続化して、データが失われないようにする • まだ永続化されていない共有バッファのデータ(dirty)は、基本的にcheckpointerプロセスがあとでま とめて永続化 共有バッファ バックエンド ストレージ あとで checkpointer などが書き込み 共有バッファに 書き込むだけ 高速 checkpointer
- 7. © 2024 NTT DATA Group Corporation 7 バックエンドが自らdirtyなデータを書き込むケース • checkpointerによる永続化が間に合わず、バックエンドが利用可能な共有バッファ領域がない場合、 バックエンドは自らdirtyなデータをストレージに書き込む • この処理はストレージへの永続化を伴うので高負荷。できるだけ避けたい 共有バッファ dirty dirty dirty dirty dirty dirty バックエンド ストレージ 書き込みが間に合 わない.. 使えるbufferがない！ クエリ返すのが遅くなるが、 自分でストレージに書き込 むしかない.. checkpointer
- 8. © 2024 NTT DATA Group Corporation 8 background writerの出番 • checkpointerによる永続化が間に合わず、バックエンドが利用可能な共有バッファ領域がない場合、 バックエンドは自らdirtyなデータをストレージに書き込む • この処理はストレージへの永続化を伴うので高負荷。できるだけ避けたい • background writerは、dirtyなページを定期的に書き込み、バックエンドが利用可能な共有バッファを 事前に作る 共有バッファ dirty dirty dirty clean dirty clean バックエンド ストレージ cleanなバッファがあった ので、自分でストレージ に書き込まずに済んだ♪ backgground writerも加勢。 Checkpointに関係なくじわじ わとストレージへ永続化 checkpointer background writer
- 9. © 2024 NTT DATA Group Corporation 9 pg_stat_bgwriterのv17での変更
- 10. © 2024 NTT DATA Group Corporation 10 pg_stat_bgwriterの17での変更 • background writerの活動をモニタリングするビュー バージョン16:
- 11. © 2024 NTT DATA Group Corporation 11 pg_stat_bgwriterの17での変更 • background writerの活動をモニタリングするビュー バージョン16 バージョン17
- 12. © 2024 NTT DATA Group Corporation 12 pg_stat_bgwriterで削除されたカラム① • checkpointer関連の情報は、17で新しく作成されたpg_stat_checkpointerビューへ移動 • かなり昔(~9.2)はcheckpointerとbackground writerは同じプロセスだったので、その名残で pg_stat_bgwriterしかなかった バージョン16 pg_stat_checkpointer へ移動
- 13. © 2024 NTT DATA Group Corporation 13 pg_stat_bgwriterで削除されたカラム② • バックエンドが自らdirtyなデータをストレージに書き込んだ件数(buffers_backend, buffers_backend_fsync)も削除 → 17ではどこを参照すればよい？ バージョン16 p.7再掲
- 14. © 2024 NTT DATA Group Corporation 14 pg_stat_bgwriterで削除されたカラム② • バックエンドが自らdirtyなデータをストレージに書き込んだ件数(buffers_backend, あああ buffers_backend_fsync)も削除 → 17ではどこを参照すればよい？ • pg_stat_ioのbackend_type = client backend, object = relation, context = normal がpg_stat_bgwriter.buffers_backendで見たかった情報に相当 バージョン17 リリースノートより
- 15. © 2024 NTT DATA Group Corporation 15 pg_stat_bgwriterで削除されたカラム② • バックエンドが自らdirtyなデータをストレージに書き込んだ件数(buffers_backend, あああ buffers_backend_fsync)も削除 → 17ではどこを参照すればよい？ • pg_stat_ioのbackend_type = client backend, object = relation, context = normal がpg_stat_bgwriter.buffers_backendで見たかった情報に相当 バージョン17 リリースノートより なぜ’similar’?
- 16. © 2024 NTT DATA Group Corporation 16 pg_stat_bgwriter.buffers_backendから pg_stat_ioへ
- 17. © 2024 NTT DATA Group Corporation 17 pg_stat_bgwriter.buffers_backend*とpg_stat_ioの違い • buffers_backendはいろいろなもののI/Oが混ざっていて、誰が何のためにI/Oしているのか区別でき ず、チューニングなどする上で必ずしも有益な情報ではなかった
- 18. © 2024 NTT DATA Group Corporation 18 ストレージ pg_stat_bgwriter.buffers_backend*とpg_stat_ioの違い① • buffers_backendはいろいろなもののI/Oが混ざっていて、誰が何のためにI/Oしているのか区別でき ず、チューニングなどする上で必ずしも有益な情報ではなかった • ファイルサイズを拡張するI/O(extend)もbuffers_backendに含まれるが、このI/Oはバックエンドが 実施する必要がある • 例えば、extend起因でbuffers_backendが大きい場合に、background writerのチューニングを 実施しても効果は見込めない 共有バッファ バックエンド ストレージ上のブロックに 空き領域がない場合は、 ファイルを拡張する background writer ファイルサイズ拡張は 私の仕事じゃない..
- 19. © 2024 NTT DATA Group Corporation 19 pg_stat_bgwriter.buffers_backend*とpg_stat_ioの違い① • buffers_backendはいろいろなもののI/Oが混ざっていて、誰が何のためにI/Oしているのか区別でき ず、チューニングなどする上で必ずしも有益な情報ではなかった • ファイルサイズを拡張するI/O(extend)もbuffers_backendに含まれるが、このI/Oはバックエンドが 実施する必要がある • 例えば、extend起因でbuffers_backendが大きい場合に、background writerのチューニングを 実施しても効果は見込めない データを挿入し、extend を発生させる buffers_backendは 12190 writesは5363 そこまで大きくない extendも5406 かなり多い
- 20. © 2024 NTT DATA Group Corporation 20 pg_stat_bgwriter.buffers_backend*とpg_stat_ioの違い② • buffers_backendはいろいろなもののI/Oが混ざっていて、誰が何のためにI/Oしているのか区別でき ず、チューニングなどする上で必ずしも有益な情報ではなかった • バックエンド以外のプロセスによって発生したI/Oについてもbuffers_backendに含まれていた • 例えば、vacuumのworkerプロセスが発生させるI/Oについてもbuffers_backendにカウントしてい たが、こちらはvacuum_buffer_usage_limitなどvacuum専用の共有バッファアクセス戦略をチュー ニングするパラメータがあるので、区別されるのが望ましい データを削除し、vacuumが 動作するのを待つ buffers_backendは 26971 backendのwritesは 5358とそこまで大きくない vacuumのwritesが10894 と大きい値
- 21. © 2024 NTT DATA Group Corporation 21 まとめ • pg_stat_bgwriterは、バージョン17から名前どおりbackground writerの情報だけになる予定 • checkpointerの情報はpg_stat_checkpointerに移動 • バックエンドによる直接の書き込みは、pg_stat_ioのbackend_type = ‘client backend‘を参照 。以前より粒度の細かい適切な情報が取得可能
- 22. © 2024 NTT DATA Group Corporation 22 おまけ • 今回pg_stat_bgwriter、pg_stat_ioをリセットするためにpg_stat_reset_shared()を利用しま した。本関数は16までは引数でリセットする対象を指定する必要がありました: • 17からは、引数を指定しない場合、各種統計情報をすべて※削除することが可能になる予定です: ※具体的には、pg_stat_archiver, pg_stat_bgwriter, pg_stat_checkpointer, pg_stat_io, pg_stat_recovery_prefetch, pg_stat_slru, pg_stat_wal