PostgreSQLモニタリング機能の現状とこれから（Open Developers Conference 2020 Online 発表資料）

© 2020 NTT DATA Corporation
PostgreSQLモニタリング機能の現状とこれから
2020年12月19日
株式会社NTTデータ鳥越淳、池田真洋

© 2020 NTT DATA Corporation 2
自己紹介
• 鳥越淳(とりこしあつし)
2008年頃からオープンソースを扱う業務に従事
PostgreSQLは9.6頃から
『PostgreSQL徹底入門第4版』(翔泳社)8～13章執筆
• 池田真洋(いけだまさひろ)
2016年頃からコネクティッドカー向けの検証支援の業務に従事
2020年5月頃からPostgreSQLの開発業務に参画

本講演について
本講演で紹介する機能や仕様は、開発中のものも含まれています。
そのため、将来的に変更される可能性があることにご注意ください。
その他、記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。

目次
1. モニタリングの概要
2. PostgreSQLの内部情報を用いた性能問題の分析イメージ
3. さらなる安定稼働を目指したモニタリング

モニタリングの概要

モニタリングとは
システムのトラブルを事前に把握したり、トラブルを迅速に解決するためには、データベースの処理状況もモニタリ
ングする必要があります。
モニタリングの実現には、情報を蓄積・加工・可視化する仕組みも必要になりますが、そもそもデータベースが必
要な情報を提供していることが前提となります。
例えば、モニタリング対象の情報としては、下記のようなものがあります。
• 異常な処理の発生状況 (ex. データベースが停止していないか)
• パフォーマンスの状況（ex. キャッシュヒット率が低下していないか、クエリの実行計画が変わっていないか)
• HWリソースの使用状況（ex. Diskの空き領域がなくなっていないか)
• データベース内部の処理状況（ex. ロック待ちが頻発していないか)
これら情報を活用して、トラブル発生時の根本原因を特定し、対策や防止につなげます。

PostgreSQL モニタリング対象情報の取得方法
情報の取得には、様々な方法があり、それぞれ特徴を活かして解析を実施
• 下記以外にもトラブルシュート時などには、EXPLAINコマンドなども使用して調査することがある
① OSのツール
Linuxの場合、ps(1)やiostat(1)などのOSのコマンドを活用して、サーバ全体のHWリソース消費状況などを確認できる。
ただし、データベースの挙動の詳細については把握しづらい。
② ログ
トラブルシュートでは、最初に確認し、ログ情報をもとに分析を始めることが多い。
PostgreSQLのログでは、問題の発生箇所・解決のヒントも記載されており、重要な情報源になる。
③ PostgreSQLの内部情報
データベースの活動状況やそれらの統計情報をビュー、テーブル、関数経由で把握できる。
データベース単位、テーブル単位、プロセス単位、クエリ単位、ロック単位など、細かい情報も取得ができる。
本講演の対象

定期的に情報を取得しておくことが大切
モニタリング時には、平常時の状態を把握しておくことが重要になる
• 平常時とトラブル時の差分を把握 ⇒ 素早い問題解決が実施できる
• 時系列での変化量を把握 ⇒ トラブル発生の検知などにつなげることができる
① 定期的に情報を取得
(pg_statsinfo)
② 平常時との変化を観測
（pg_stats_reporter）
pg_statsinfo, pg_stats_reporterなどの
拡張機能を活用することで簡単に収集可能

PostgreSQLの内部情報を用いた
性能問題の分析イメージ

PostgreSQLの内部情報を活用した分析例
「最近データベースが遅くなった」という場合を想定し、原因を特定をする過程のパターンをご紹介
• トラブルシュートで特によく利用するビューやテーブルを取り上げます
アプリケーション
クエリの応答が全然返ってこない！
スループットが下がった！

Backend
問題特定の進め方
問題を特定していくためには、クエリ処理の流れを把握しておくことが大切
• 確認すべきビューを把握するためにも必要になる
クエリ処理の概要
クライアント
SELECT/INSERT/
UPDATE/DELETE
②クエリの実行
(Query Execution)
①実行計画の作成
(Query Planning)
②では、インデックスやテーブルへのアクセ
スが発生する
共有バッファ上にアクセスし、データが存在
しなければ、Disk上のデータを取得する。
排他制御も実施。
データファイル
共有バッファ
(Buffer IO)
排他
制御
クライアント
クライアント

Backend
DB単位で処理状況を確認
“pg_stat_database” ビューで、DB単位(※)で統計情報を確認可能
• まずはマクロな視点（DB単位）から原因を切り分けて、ミクロな視点（クエリ単位など）に詳細化していく
クライアント
SELECT/INSERT/
UPDATE/DELETE
(Query Execution)
(Query Planning)
スが発生する
共有バッファ
(Buffer IO)
排他
制御
クライアント
クライアント
(※) PostgreSQLは、1つのインスタンスに複数DBを作成できる

xact_rollback | 57
tup_deleted | 294
# 読み込み時に共有バッファに存在していた・
存在していなかったブロック数
blks_hit | 115024816
blks_read | 7071907
# データファイルのブロック読み込み・書き込みに費やされた合計時間
pg_stat_databaseで見るべきポイント
共有バッファ上のデータのヒット状況を把握するために利用。
通常時と比較して、ヒット率が低くなっている場合は、 Disk上
のデータにアクセスがより高頻度で発生している可能性がある
⇒ 他のクエリからの大量のINSERTが発生しているなど、共有
バッファ領域が不足している可能性がある
共有バッファ
(Buffer IO)
blks_hit
(高速)
blks_read
(低速)

xact_rollback | 57
tup_deleted | 294
# 読み込み時に共有バッファに存在していた/存在していなかったブロック数
blks_hit | 115024816
blks_read | 7071907
# データファイルのブロック読み込み・
書き込みに費やされた合計時間
pg_stat_databaseで見るべきポイント
ブロック情報の読み込み・書き込み時間を知るために利用
（事前に track_io_timing を有効化しておく必要がある）
共有バッファへのキャッシュヒット率が高いにも関わらず、読み込
み時間が増加している場合
⇒ Disk故障などが原因になっている可能性がある
共有バッファ
(Buffer IO)
キャッシュヒット率高い
ココが遅い
⇒ Disk故障やDiskへの
多重アクセスなど？

Backend
クエリ単位で処理状況を確認
“pg_stat_statements” ビュー（※）で、クエリ単位で統計情報を確認可能
• ミクロな視点（クエリ単位など）で状況を確認できる。特定のクエリだけの問題なのか等を特定可能
クライアント
SELECT/INSERT/
UPDATE/DELETE
(Query Execution)
(Query Planning)
スが発生する
共有バッファ
(Buffer IO)
排他
制御
クライアント
クライアント
（※）事前に拡張機能をインストール・有効化しておく必要がある

pg_stat_statementsの項目
pg_stat_statementsの情報（一部項目を抜粋） ※クエリ単位で統計情報は出力される
# クエリ
query | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
# 実行計画を生成した回数・生成時間（v13～）
plans | 250451
mean_plan_time | 17049.87321800001
# クエリの実行回数・実行時間
calls | 250451
mean_exec_time | 0.04684529807427434
# クエリで取得したレコード数
rows | 250451

本資料で深堀りする事象
# クエリ
query | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
# 実行計画を生成した回数・生成時間（v13～）
plans | 250451
total_plan_time | 17049.87321800001
# クエリの実行回数・実行時間
calls | 250451
total_exec_time | 11732.451748000254
# クエリで取得したレコード数
rows | 250451
特定クエリの実行時間が長くなっているかどうかを把握できる
通常時と比較して、特定のクエリの実行時間だけが長くなっている
場合、アプリケーション処理のボトルネックになっている可能性がある
⇒ 本クエリについて詳細に分析を進める必要があるので、
リアルタイムなクエリの実行状態を確認してみる

まさに今実行されている状況を確認できる pg_stat_activityビュー
“pg_stat_activity” ビューでクエリ処理を受け付けるBackendの処理状況を確認できる
• DBサーバ側のクエリ処理状況をリアルタイムで確認するために利用する
Backend
クライアント
SELECT/INSERT/
UPDATE/DELETE
(Query Execution)
(Query Planning)
スが発生する
共有バッファ
(Buffer IO)
排他
制御
クライアント
クライアント

pg_stat_activityで見るべきポイント
pg_stat_activityビュー（よく利用する項目を抜粋）
# 基本情報
datname | pgbench
pid | 34195
application_name | pgbench
client_addr |
query | UPDATE pgbench_branches SET bbalance = bbalance …
# 接続・トランザクション・クエリの開始時間
backend_start | 2020-12-10 11:14:40.251874+09
xact_start | 2020-12-10 11:14:40.249069+09
query_start | 2020-12-10 11:14:40.249069+09
# 待機イベント
wait_event_type | Lock
wait_event | tuple
待機イベントは、処理を待っている理由を示す。
ボトルネックとなっている可能性がある事象を確認することができる。
※ 注意点として、ビューを参照したときの待機状態しか出力されな
い。そのため、複数回実行して、傾向を確認した方がよい
例えば、
・ロックイベントが頻発している場合
⇒ ロック競合が発生している可能性あり。
ロックの詳細を確認する（次ページ）

ロック待ちが多い場合
システムカタログの “pg_locks” でロック情報の詳細を確認できる
• ロックの粒度、ロックを保持しているトランザクション・プロセス、原因の絞り込みが実施できる
Backend
クライアント
SELECT/INSERT/
UPDATE/DELETE
(Query Execution)
(Query Planning)
スが発生する
共有バッファ
(Buffer IO)
クライアント
クライアント
排他
制御

pg_locksの項目
pg_locksではロック情報を参照可能
• 単体では解析しずらいため、他のビューと合わせて分析されることが多い（具体的なSQLクエリは次ページ）
pg_locksなどの情報（よく利用する項目を抜粋）
# トランザクションに関する情報
pid | 21060 # ロックを保持(or予定)しているプロセスID
database | pgbench # データベース名
relname | pgbench_tellers # リレーション名
query | UPDATE pgbench_branches … # プロセスが実行しているクエリ文
wait_event_type | Lock # 待機イベントタイプ
wait_event | tuple # 待機イベント
state_change | 2020-12-10 13:12:13.820967+09 # stateが最後に変更された時間
xact_start | 2020-12-10 13:12:13.820276+09 # トランザクションの開始時間
# ロックに関する情報
pg_blocking_pids | {34623,34628,34631,34622} # ブロックしているプロセスID
locktype | relation # ロック対象のオブジェクト
mode | RowExclusiveLock # 獲得(or予定)しているロックモード

（参考）pg_locksを分析するときのクエリ例
SELECT
l.pid, l.locktype, d.datname, c.relname,
l.transactionid, l.virtualxid,
l.mode, s.query, s.wait_event_type, s.wait_event,
s.state, s.state_change, s.xact_start
FROM
pg_locks l LEFT JOIN pg_stat_activity s USING (pid)
LEFT JOIN pg_class c ON l.relation = c.oid
LEFT JOIN pg_stat_database d ON l.database = d.datid
WHERE l.pid <> pg_backend_pid()
ORDER BY l.pid;
pg_stat_activity, pg_classビューと組み合わせて、実行中のクエリやロック対象のテーブル情報と
合わせて分析することが多い（v13の場合のSQL例）

relname | pgbench_tellers # リレーション名
locktype | relation
mode | RowExclusiveLock
pg_locksで見るべきポイント
本サーバプロセスをブロックしているプロセスのPID

relname | pgbench_tellers # リレーションのOID
locktypeはロック対象のオブジェクト。対象オブジェクトによって、想
定される原因が異なる
・locktype=relationの場合
表ロック。競合している場合、ALTER TABLE、CLUSTERなど
が並行して走っている可能性が想定される
・locktype=transactionid or tupleの場合
行ロック。競合している場合、同一行に対するUPDATEが並行
して、集中して発生している可能性が想定される
・locktype=extendの場合
テーブル拡張のためのロック。同一テーブルにINSERTが集中し
ている可能性が想定される

relname | pgbench_tellers # リレーションのOID
modeは、同時アクセスを制御するためのロックモード
例えば、RowExclusiveLockの場合は、
テーブルのデータを変更する場合に獲得される
⇒ UPDATE/DELETE/INSERTなどが並行して走っている可能性
が想定される
（※）ロックモードによって、同時制御の可否が決定する
https://www.postgresql.org/docs/13/explicit-locking.html

ご紹介した分析事例の一例
「データベースの応答が最近遅くなった」場合を想定し、原因特定をする過程の数パターンをご紹介
• 内部の情報が提供されていることで、トラブル発生時の原因の絞り込みや問題検知が実施しやすくなっている
データベースの応答が
最近に遅くなった
pg_stat_database
pg_stat_activity
pg_stat_statements
データ更新が大量に発生してい
ないかなど、原因を追加調査
全体的にブロック読み込み時間が増加
同一テーブルにINSERTが集中して発
生していないかなど、原因を追加調査
（pg_stat_user_tablesなどを活用）
DB単位
クエリ単位
pg_locks
特定のクエリが遅い
⇒ 待機イベントを確認
ロック待ちが多い
⇒ ロックの詳細確認
Diskの故障が発生していない
かなど、原因を追加調査
全体的にキャッシュヒット率が低下
状況に応じて、原因を追加調査
その他も事象は多数…
（平常時との変化など）

その他の内部情報を取得するための方法
https://pgstats.dev/
他にも分析に役立つ内部情報は多数存在しており、原因の絞り込みの際には、それらを組み合わせて活用していく必要がある
• 処理レイヤごとに内部状態を把握するための方法を一覧化しているサイト（pgstats.dev）がある

最近のバージョンで追加されたメトリクス
すでに多数の内部情報が提供されていますが、バージョンアップに伴い、進化し続けている
• 社会インフラ系基幹システムなどへのPostgreSQLの適用が本格化してきている背景もあり、より高度な
データベース内部の情報も提供できる仕組みが整えられてきている
■ PostgreSQL v12～
・ pg_stat_database ビューにチェックサムの誤り検出されたブロック数が追加
・ CREATE INDEX, REINDEX, CLUSTER, VACCUM FULLの進捗状況が分かるビューが追加
■ PostgreSQL v13～
・ pg_stat_activity ビューにパラレルクエリ実行時のparallel workerのLeaderのpidが追加
・ pg_stat_statements ビューに各クエリごとのWAL生成量（合計レコード数・バイト数・FPI数）
・ ANALYZE, BASE_BACKUP の進捗状況が分かるビューが追加
などなど多数…

さらなる安定稼働を目指すためのモニタリング

さらなる安定稼働を目指すためのモニタリング
PostgreSQLのモニタリング情報は現在も拡充を続けています。
以下、NTTデータが提案・開発に携わっている２つの機能(※)をご紹介します。
• バックエンドプロセスのメモリ利用状況に関する情報
• DBクラスタ全体のWALに関する統計情報
※いずれも2020/12/16時点では、masterブランチコミット済。次期メジャーバージョンであるPostgreSQL
14で利用可能になる予定ですが、今後変更などが加わる可能性もあります。

バックエンドプロセスのメモリ利用状況に関する情報
～MemoryContextの確認～

MemoryContextとは
PostgreSQLでは、MemoryContextと呼ばれる単位を使って、Tree構造でメモリを管理
• 用途に応じたMemoryContextを作成し、メモリを割り当て(palloc)
• 親のMemoryContextが削除されると、その子孫のMemoryContextも全て削除
⇒ 構造化されているため、メモリ管理がmalloc()よりも容易に
TopMemoryContext
CacheMemoryContext TopPortalContext
TopTransactionContext … …
Context
…
Context
親は１つ
子は複数可
※TopMemoryContextは親なし
Context
…
Context
…

MemoryContextの情報を取得する必要性
特定のContextが肥大化したり、大量のContextが作成されることで、メモリを逼迫することがある
例)
• PostgreSQL内部のキャッシュ(relcacheなど)増加
• 大量のPreparedStatement
• メモリリーク
OSからはPostgreSQLプロセスのメモリが肥大化していることはわかるが、PostgreSQLが何にメモリを利用して
いるかまではわからない
現在のPostgreSQL V13では、 MemoryContextの情報を得るにはデバッガが必要。
商用環境などではデバッガやデバッグシンボルが導入されていないなどの理由で使えないことも
実行例
(gdb) call MemoryContextStats(TopMemoryContext)

V14でできるようになること(予定)
pg_backend_memory_contextsビューからローカルプロセスのMemoryContextをSQLで確認可能
• 内容はデバッガ経由で取得した場合と同等
Contextを特定する情報があれば、identに出力される
例) PREPARE文を実行した場合
階層の深さはlevelで表現

DBクラスタ全体のWALに関する統計情報

WALモニタリングの必要性
• WAL(Write Ahead Logging)は、トランザクションの内容をテーブルなどデータファイルに書き込む前に、
ログとして記録しておく手法
• クラッシュリカバリ、物理バックアップ、レプリケーションでも利用される重要な仕組み
• ディスクへの永続化をすることもあり、更新が多いワークロードなどの場合、WAL書き出しがDisk I/Oのボト
ルネックになることも

V13で確認できるWALの統計情報
PostgreSQL V13では、以下のWALに関するメトリクスが取得可能に
• pg_stat_statements, EXPLAN: クエリ単位で生成したWALレコード数など
• Autovacuum: バキューム時に生成したWALレコード数など
pg_stat_statementsビュー
postgres=# SELECT query, wal_records, wal_fpi, wal_bytes FROM pg_stat_statements;
query | UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2
wal_records | 206328 # 本クエリによって、生成された合計WAL数
wal_fpi | 3807 # 本クエリによって、生成された合計full page images数(※)
wal_bytes | 43960467 # 本クエリによって、生成された合計WALバイト数
(※) 通常書き出されるWALと比較して、サイズが大きく、Disk書き込みの負荷が高いWALレコード。鈴木啓修さんのslideshare
「PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)」が詳しいので、ご興味のある方はご参考ください。

V14でできるようになること(予定)
DBクラスタ全体のWALに関する活動をモニタリングするpg_stat_walビューを導入
V13のpg_stat_statementsなどでモニタリング可能になった項目のDBクラスタ全体の情報に加え、WAL
バッファが溢れてDiskへ書き込みが発生した回数をカウントするwal_buffers_fullを導入。頻繁に発生して
る場合、WALバッファのサイズ(パラメータwal_buffersで設定可能)を増やすなどのチューニングにつなげること
ができる
pg_stat_walビュー
wal_records | 36960 # DBクラスタ全体で、生成された合計WAL数
wal_fpi | 2785 # DBクラスタ全体で、生成された合計full page images数
wal_bytes | 128434288 # DBクラスタ全体で、合計WALバイト数
wal_buffers_full | 2826 # WALバッファが一杯でDiskへの書き込みが発生した回数

WALバッファが溢れてDiskへ書き込みが発生、とは
バックエンドはWALバッファにWALを書き込み、WALバッファ上のデータは、通常はWAL writerが定期的に
Diskに書き出す
• バックエンドはメモリ上の操作のみなので高速
• ただし、WAL writerのDisk書き出しが間に合わない場合は...
WALファイル
Memory
Disk
WALバッファ
バックエンド
WAL writer
定期的にバックグラウン
ドで書き出し
クライアント
BEGIN;
操作を記録
INSERT ...
INSERT ...

WALバッファが溢れてDiskへ書き込みが発生、とは
WALバッファが一杯になっていると、バックエンドがWALバッファを書き出さざるを得ない
• Diskへの同期書き込みが発生するため、クエリ処理の性能劣化を生み出す
WALファイル
Memory
Disk
WALバッファ
バックエンド
クライアント
BEGIN;
INSERT …
INSERT …
操作を記録
WAL writer
バックエンドが同
期書き込み
※ 間に合っていない
（WALバッファが小さい、
書き込み間隔が長いなど）

まとめ
• モニタリングは、システムが正常に動作しているか把握したり、トラブルの原因を把握するた
めに必要
• データベースのモニタリングでは、稼働統計情報などデータベース内部の状態を観察できる
手段がある
• 基本的なモニタリング情報は抑えておくとよい
pg_stat_database, pg_stat_statements, pg_stat_activity, pg_locksなど
• PostgreSQLのモニタリング情報は現在も進化し続けている
追加したいモニタリング項目などがあれば検討したいので、ぜひ教えてください！

We‘re Hiring!
先進的基盤技術に関する技術開発を担う
ITスペシャリスト/ミドルウェア開発者
<395>
https://nttdata.jposting.net/u/job.phtml?job_code=676
一緒に働く仲間を募集しています！
データベースミドルウェア（PostgreSQL）の高度化・
機能拡充を実現する開発者
<394>
こんな方を募集しています！
 NTTデータが関わる様々な案件で技術力を発揮し社会
に貢献したい方
 自らの専門性も高めながら専門家集団で働きたい方
 OSSのコミュニティ活動で世界と繋がっていきたい方、
etc.
若手が中心の
活発な職場です
https://nttdata.jposting.net/u/job.phtml?job_code=677

PostgreSQLモニタリング機能の現状とこれから（Open Developers Conference 2020 Online 発表資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to PostgreSQLモニタリング機能の現状とこれから（Open Developers Conference 2020 Online 発表資料）

Similar to PostgreSQLモニタリング機能の現状とこれから（Open Developers Conference 2020 Online 発表資料） (20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

Recently uploaded

Recently uploaded (9)

PostgreSQLモニタリング機能の現状とこれから（Open Developers Conference 2020 Online 発表資料）

Editor's Notes