PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能（Open Source Conference 2021 Online Fall 発表資料）

© 2021 NTT DATA Corporation
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能
2021年10月22日 Open Source Conference 2021 Online Fall
株式会社NTTデータ鳥越淳

© 2021 NTT DATA Corporation 2
自己紹介
鳥越淳(とりこしあつし)
2008年頃からオープンソースソフトウェアを扱う業務に従事
PostgreSQLは9.6頃から
『PostgreSQL徹底入門第4版』(翔泳社)8～13章執筆

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

目次
1. モニタリングの概要
2. PostgreSQLの内部情報を用いた性能問題の分析イメージ
3. NTTデータが追加したモニタリング新機能

モニタリングの概要

モニタリングについて
キャパシティプランニング、トラブルの予兆を事前に把握したり、トラブルを迅速に解決するため
には、データベースの処理状況をモニタリングする必要があります
モニタリングの実現には、情報を蓄積・加工・可視化する仕組みも必要になりますが、そもそも
データベースから必要な情報を取得できることが前提となります
例えば、モニタリングのために取得する情報には、下記のようなものがあります
• 異常な処理の発生状況 (例. 長時間化しているクエリがないか)
• パフォーマンスの状況（例. キャッシュヒット率が低下していないか)
• HWリソースの使用状況（例. Diskの空き領域がなくなっていないか)
• データベース内部の処理状況（例. ロック待ちが頻発していないか)

PostgreSQL モニタリング対象情報
情報の取得には、様々な方法があり、それぞれ特徴を活かして解析を実施
① OSのツール
Linuxの場合、top(1)やiostat(1)などのOSのコマンドを活用して、サーバ全体のHWリソース消費状況などを確
認できる
ただし、データベースの挙動の詳細については把握しづらい
② ログ
PostgreSQLのログは、問題の発生箇所・解決のヒントも記載されており、重要な情報源になる
設定からどういう情報を出力させるか詳細な設定が可能
③ PostgreSQLの内部情報
データベースの活動状況やそれらの統計情報をビュー、テーブル、関数経由で把握できる
データベース単位、テーブル単位、プロセス単位、クエリ単位、ロック単位など、様々な粒度で取得ができる
本講演の対象

例えば、稼働統計情報に関するビュー
PostgreSQLは、内部で蓄積したDBの稼働状況を「稼働統計情報」という形でビューとして提供
• backendやautovacuumなど、サーバプロセスの動的情報を集計・統計化、稼働統計情報としてユーザにビュー提供
③様々なビューとして提供
statistics
collector
backend
autovacuum
checkpointer
・・・
① 定期的に稼働情報を送信 ② 統計化して管理
運用者
SQLクエリ
=# SELECT … FROM pg_stat_database
datname | xact_commit | xact_rollback
---------+-------------+--------------
db1 | 100 | 10
db2 | 200 | 20
例. PostgreSQLサーバで
実行されているクエリ取得
稼働統計情報

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

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

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

(参考)PostgreSQLが提供するモニタリング機能一覧
今回ご紹介するもの以外にもPostgreSQLは多数のモニタリング用のビュー・関数を提供している
コンポーネントごとに内部状態を把握するための方法を一覧化しているサイト（pgstats.dev）もある
https://pgstats.dev/

バックエンド
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への
多重アクセスなど？

バックエンド
クエリ単位で処理状況を確認
“pg_stat_statements” ビュー（※）で、SQL文単位の統計情報を確認可能
• 特定の種類のクエリに問題ないか確認する
クライアント
SELECT/INSERT/
UPDATE/DELETE
(Query Execution)
(Query Planning)
②では、インデックスやテーブルへのアクセ
スが発生する
共有バッファ
(Buffer IO)
排他
制御
クライアント
クライアント
（※）事前にpg_stat_statementsをインストール・有効化しておく必要がある

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

本資料で深堀りする事象
pg_stat_statementsの情報（一部項目を抜粋） ※クエリ単位で統計情報は出力される
# SQL文
query | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
# 実行計画を生成した回数・生成時間
plans | 250451
total_plan_time | 17049.87321800001
# 本SQL文の実行回数・実行時間
calls | 250451
total_exec_time | 11732.451748000254
# 本SQL文で取得した/影響を受けたレコード数
rows | 250451
特定クエリの実行時間が長くなっているかどうかを把握できる
通常時と比較して、特定のクエリの実行時間だけが長くなっている
場合、本SQL文の実行がボトルネックになっている可能性がある
⇒ 本クエリについて詳細に分析を進める必要があるので、
リアルタイムなクエリの実行状態を確認してみる

バックエンドなどの現在の状況を確認できる pg_stat_activityビュー
“pg_stat_activity” ビューでバックエンドなどPostgreSQLプロセスの現在の状況を確認できる
• DBサーバ側のクエリ処理状況をリアルタイムで確認するために利用する
バックエンド
クライアント
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 | 2021-12-10 11:14:40.251874+09
xact_start | 2021-12-10 11:14:40.249069+09
query_start | 2021-12-10 11:14:40.249069+09
# 待機イベント
wait_event_type | Lock
wait_event | tuple
待機イベントは、処理を待っている理由を示す。
ボトルネックとなっている可能性がある事象を確認することができる。
※ 注意点として、ビューを参照したタイミングの待機状態しか出力
されない。そのため、複数回実行して、傾向を確認した方がよい
例えば、
・ロックイベントが頻発している場合
⇒ ロック競合が発生している可能性あり。
ロックの詳細を確認する（次ページ）

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

pg_locksの項目
pg_locksではロック情報を参照可能。pg_blocking_pids()関数から指定のPIDをブロックしているプロセス
群が把握可能。
• なお、単体では解析しずらいため、pg_stat_activityやpg_classなどとそれぞれpid, relationでJOINして分析する
ことも多い
pg_locksなどの情報（よく利用する項目を抜粋）
# トランザクションに関する情報
pid | 21060 # ロックを保持(or予定)しているプロセスID
database | 13027 # データベースのOID
relation | 3455 # リレーションのOID
# ロックに関する情報
locktype | relation # ロック対象のオブジェクト
mode | RowExclusiveLock # 獲得(or予定)しているロックモード
waitStart | 2021-10-10 13:12:14.820276+09 # ロック待ち開始時刻
pg_blocking_pids(pg_locks.pid)の情報
pg_blocking_pids | {34623,34628,34631,34622} # ブロックしているプロセスID

waitStart | 2021-10-10 13:12:14.820276+09 # ロック待ち開始時刻
pg_locksで見るべきポイント
ロック待ち開始時刻
待ち時間が長いほど影響が大きくなりやすい

waitstart | 2021-10-10 13:12:14.820276+09 # ロック待ち開始時刻
本サーバプロセスをブロックしているプロセスのPID

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

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

ご紹介した分析事例に利用した情報のまとめ
「データベースの応答が遅くなった」場合を想定し、ドリルダウンする形で分析
• いつもこのやり方がよいわけではないが、問題が曖昧な場合や、見落としの確認などに有効
データベースの応答が
最近に遅くなった
pg_stat_database
pg_stat_activity
pg_stat_statements
データ更新が大量に発生してい
ないかなど、原因を追加調査
全体的にブロック読み込み時間が増加
同一テーブルにINSERTが集中して発
生していないかなど、原因を追加調査
（pg_stat_user_tablesなどを活用）
DB単位
クエリ単位
pg_locks
特定のクエリが遅い
⇒ 待機イベントなどを確認
ロック待ちが多い
⇒ ロックの詳細確認
Diskの故障が発生していない
かなど、原因を追加調査
全体的にキャッシュヒット率が低下
状況に応じて、原因を追加調査
その他も事象は多数…
（平常時との変化など）
実行計画の確認

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

さらなる安定稼働を目指すためのモニタリング
PostgreSQLのモニタリング情報は現在も拡充を続けています
以下、赤枠で囲んだNTTデータが提案・開発したPostgreSQL 14のモニタリング機能をご紹介します
• バックエンドプロセスのメモリ利用状況に関する情報
• DBクラスタ全体のWALに関する統計情報
• pg_locksビューへのwaitstart列追加
• pg_stat_statementsの改善※
※pg_stat_statements_infoビューの新規導入、処理対象行数を出力できるSQLコマンドの追加がされました。
詳細は資料をご参照ください。
https://www.slideshare.net/nttdata-tech/postgresql-14-pg-stat-statements-
improvements-pgunconf23-nttdata

バックエンドプロセスのメモリ利用状況に関する情報
～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 13までは、 MemoryContextの情報を得るにはデバッガが必要
商用環境などではデバッガやデバッグシンボルが導入されていないなどの理由で使えないことも
実行例
(gdb) call MemoryContextStats(TopMemoryContext)

V14でできるようになったこと
pg_backend_memory_contextsビュー、pg_log_backend_memory_contexts()関数から、それぞ
れローカルプロセス、指定のバックエンドのMemoryContextを確認可能
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バッファが溢れてDisk書き込みが発生すると性能は劣化するが、WALバッファが溢れた回数を取得する方
法がなかった
頻繁に発生してる場合、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への書き込みが発生した回数

ロック取得待ち時間の確認
～pg_locksビューへのwaitstart列追加～

V13までのpg_locks
• pg_locksビューは、PostgreSQLプロセスによって取得されているロックの情報を表示するビュー
• PostgreSQL 13以前では、ロック待ちを開始した時刻や、ロック待ちしている時間を取得する方法は提
供されていなかった
• pg_stat_activityとpidで結合してquery_startやstate_changeで時刻を取得できるが、これら
はクエリの開始時刻や状態が変化した時刻
…

V14のpg_locks
• ロック待ちを開始した時刻を表示するwaitstart列を追加
• 現在時刻との差分を見れば、ロック待ち時間が取得可能
…
=# SELECT relation, pid, mode, granted, waitstart FROM pg_locks; _
=# SELECT relation, pid, mode, granted, now() – waitstart AS durtation FROM pg_locks; _

V14のpg_locks
• ロック待ちを開始した時刻を表示するwaitstart列を追加
• ロックを保持している場合はNULL
• 現在時刻との差分を見れば、ロック待ち時間が取得可能
…
=# SELECT relation, pid, mode, granted, waitstart FROM pg_locks; _
=# SELECT relation, pid, mode, granted, now() – waitstart AS durtation FROM pg_locks; _

V14のpg_locksの注意点
• タイミングによってはロック取得待ち状態(grantedがfalse)なのに、waitstartがNULLになるケースがある
点に一応注意
• これは、オーバーヘッドを増やさないよう、waitstart更新時にロック取得しないようにしたために発生
• この状況はごく短時間しか発生しない、かつwaitstartが必要になるのは長時間ロックが解放されな
い場合なので、実質的な影響はないはず
…

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

We‘re Hiring!(1/2)
https://nttdata.jposting.net/u/job.phtml?job_code=666
一緒に働く仲間を募集しています！
データ活用プロフェッショナル
(OSSエンジニア)＜384＞
こんな方を募集しています！
 NTTデータが関わる様々な案件で技術力を発揮し社会
に貢献したい方
 自らの専門性も高めながら専門家集団で働きたい方
 OSSのコミュニティ活動で世界と繋がっていきたい方、etc.
若手が中心の
活発な職場です
※2021年6月現在
(IoT基盤エンジニア)＜497＞
※上記写真2枚はコロナ禍前に撮影したものです。

We‘re Hiring!(2/2)
(DataOpsエンジニア）＜498＞
JDK/JVMの高難度技術課題の解決と技術開発を担う
Javaスペシャリスト<368>
データベースミドルウェア
(PostgreSQL)の高度化・機能
拡充を実現する開発者<394>
※2021年6月現在
一緒に働く仲間を募集しています！

YouTubeチャンネル “NTT DATA Tech”
技術取り組み、活用情報を中心にお届けします
https://www.youtube.com/NTTDATATech

PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能（Open Source Conference 2021 Online Fall 発表資料）

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能（Open Source Conference 2021 Online Fall 発表資料）

Semelhante a PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能（Open Source Conference 2021 Online Fall 発表資料） (20)

Mais de NTT DATA Technology & Innovation

Mais de NTT DATA Technology & Innovation (20)

PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能（Open Source Conference 2021 Online Fall 発表資料）

Notas do Editor