こんにちは！
ITエンジニアのYukiです。
PostgreSQLのpg_stat_bgwriterビューで確認できる統計情報がいくつかありますが、覚えるのに苦労しませんか？ （私はしました。）
図に描いて整理したので、それを元に説明します。
なお、pg_stat_bgwriterビューは、OSS-DB Goldの試験範囲に入っています。（Ver. 3.0でも引き続き試験範囲です）
性能監視に必要な知識となるので、しっかり理解しておきましょう。
Photo by Richard Jacobs on Unsplash
pg_stat_bgwriterビューとは
pg_stat_bgwriterビューは、PostgreSQLの統計情報ビューの一つで、バックグラウンドライタやチェックポインタなどのプロセスの活動状況を取得できます。
同様の統計情報ビューとしては、pg_stat_activity, pg_stat_database, pg_stat_all_tables, pg_statio_all_tables, pg_stat_archiverなどがあります。どれもPostgreSQLの性能状況のビューとして重要です。
DBクラスタ単位で情報を収集しているので、pg_stat_bgwriterビューは1行のみです。
以下のようなデータが取得できます。
postgres=# select * from pg_stat_bgwriter; -[ RECORD 1 ]---------+------------------------------ checkpoints_timed | 73 checkpoints_req | 0 checkpoint_write_time | 7146 checkpoint_sync_time | 176 buffers_checkpoint | 1725 buffers_clean | 0 maxwritten_clean | 0 buffers_backend | 1685 buffers_backend_fsync | 0 buffers_alloc | 3100 stats_reset | 2021-12-12 23:20:13.843488+09
バッファ数についての項目
pg_stat_bgwriterビューのバッファ数が確認できる項目
まずは、バッファの割り当て、データファイルへの書き出しについて確認できる項目について説明します。
buffers_alloc
共有メモリに割り当てられたバッファ数をbuffers_allocで確認できます。
buffers_clean, buffers_checkpoint, buffers_backend
一方でデータファイルに書き出されたバッファ数は、書き込んだプロセスごとに、buffers_clean, buffers_checkpoint, buffers_backendで確認できます。
性能的に理想なのは、バックグラウンドライタやチェックポインタにより、ダーティバッファがデータファイルに書き出されることです。その際に書き出されたバッファ数が、それぞれbuffers_clean, buffers_checkpointに加算されます。
新しいバッファを割り当てる際に空きがないと、バックエンドプロセスが自分でダーティバッファを書き出します。その際は、buffers_backendに加算されます。
buffers_backendとbuffers_allocの対比による性能確認
buffers_backendがbuffers_allocに対して大きい場合は、共有メモリのサイズが足りていない可能性があります。足りていない場合は、shared_buffersパラメータを増やして共有メモリを大きくすることを検討します。（もちろん、増やす際、サーバの物理メモリが足りているかなどは、十分な確認が必要です。）
処理回数についての項目
pg_stat_bgwriterビューの処理回数が確認できる項目
上記の各項目で確認できるのは、各プロセスで各処理が行われた回数です。
checkpoints_timedとcheckpoints_req
checkpoints_timedとcheckpoints_reqでは、チェックポイントの回数が確認できます。
checkpoints_timedは、時間経過が契機となったチェックポイントの回数です。
一方、checkpoints_reqは、WALファイル書き出しがmax_wal_sizeパラメータで設定したサイズに達することを契機としたチェックポイントの回数です。
性能的に理想なのは、時間経過が契機となってチェックポイントが行われることです。
checkpoints_reqが多い場合、WALサイズが足りていないために、頻繫にチェックポイントが発生している可能性があります。足りていない場合、max_wal_sizeパラメータを増やしてWALサイズを大きくすることで、チェックポイントの頻度を下げることを検討します。（もちろん、WALを出力する領域が十分にあるかなどは、確認が必要です）
maxwritten_clean
maxwritten_cleanは、バックグラウンドライタにおいて、整理用スキャンを停止した回数です。
バックグラウンドライタが書き出したバッファ数が多過ぎたために、整理用スキャンを停止した回数です。
（PostgreSQL文書 14.5 > 表28.21 pg_stat_bgwriterビュー より）
「整理用スキャンを停止」というのは、バックグラウンドライタで書き込まれるバッファ数がbgwriter_lru_maxpagesパラメータの設定値を超える際に停止するというものです。
buffers_backend_fsync
buffers_backend_fsyncは、バックエンドで独自にfsyncを実行した回数です。
こちらもPostgreSQLのマニュアルから引用させてもらいます。
バックエンドが独自にfsync呼び出しを実行しなければならなかった回数です。 （通常は、バックエンドが独自に書き込んだ場合であっても、バックグラウンドライタがこれらを扱います。）
（PostgreSQL文書 14.5 > 表28.21 pg_stat_bgwriterビュー より）
例題
各項目の意味を一通り理解したところで、OSS-DBの公式サイトから例題を引用させてもらいます。
3.14
buffers_backendに関する説明として適切なものをすべて選びなさい。～略～
C. buffers_backendの値がbuffers_allocに対して大きい場合は、shared_buffersの値のチューニングを検討する必要がある
～略～
（Goldの例題解説 – G3 パフォーマンスチューニング（Ver.3.0） > G3.1 性能に関係するパラメータ ）
buffers_backendとbuffers_allocは、割当・書込バッファ数がわかるpg_bgwriterビューの項目でしたね。
buffers_backend 対 buffers_alloc
buffers_backendがbuffers_allocに対して大きい場合は、バックグラウンドライタやチェックポインタによる書き出しが間に合っていないので、バックエンドプロセスが自分で書き出しを行っており、性能が劣化しています。
共有メモリサイズが足りていない可能性があるため、shared_buffersパラメータのサイズを大きくすることは、チューニングとして考えられます。
つまり、Cの選択肢は適切ですね。
ほかの選択肢も気になる方は、公式の例題解説ページをご覧ください。
まとめ
buffers_backend, chekpoints_timed, chekpoints_reqなど、pg_stat_bgwriterビューで取得できる項目を図にまとめて解説しました。
pg_stat_bgwriterビューからは、バッファの割り当て書き出しや、チェックポイントなど、PostgreSQLのバックグラウンドライタプロセスの活動状況を取得できます。
絵にかいてみるとわかりやすいですね。
この記事を読んで、pg_stat_bgwriterビューで確認できる項目が整理できましたら幸いです。
最後までご覧いただき、ありがとうございました。
こんなことも知りたいといったご質問や間違ってるよといったご指摘、ご感想などありましたら、ページ一番下からお気軽にコメントください。
この記事が役に立ちましたら、下のボタンからシェアしていただけると嬉しいです。
それでは。
｜ 目次 ｜
コメント