Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

PostgreSQLモニタリング機能の現状とこれから
(Open Developers Conference 2020 Online 発表資料)
2020年12月19日

株式会社NTTデータ
鳥越 淳
池田 真洋

  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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

  1. 1. © 2020 NTT DATA Corporation PostgreSQLモニタリング機能の現状とこれから 2020年12月19日 株式会社NTTデータ 鳥越淳、池田真洋
  2. 2. © 2020 NTT DATA Corporation 2 自己紹介 • 鳥越 淳(とりこし あつし) 2008年頃からオープンソースを扱う業務に従事 PostgreSQLは9.6頃から 『PostgreSQL徹底入門 第4版』(翔泳社)8~13章執筆 • 池田真洋(いけだ まさひろ) 2016年頃からコネクティッドカー向けの検証支援の業務に従事 2020年5月頃からPostgreSQLの開発業務に参画
  3. 3. © 2020 NTT DATA Corporation 3 本講演について 本講演で紹介する機能や仕様は、開発中のものも含まれています。 そのため、将来的に変更される可能性があることにご注意ください。 その他、記載されている会社名、商品名、又はサービス名は、 各社の登録商標又は商標です。
  4. 4. © 2020 NTT DATA Corporation 4 目次 1. モニタリングの概要 2. PostgreSQLの内部情報を用いた性能問題の分析イメージ 3. さらなる安定稼働を目指したモニタリング
  5. 5. © 2020 NTT DATA Corporation 5 モニタリングの概要
  6. 6. © 2020 NTT DATA Corporation 6 モニタリングとは システムのトラブルを事前に把握したり、トラブルを迅速に解決するためには、データベースの処理状況もモニタリ ングする必要があります。 モニタリングの実現には、情報を蓄積・加工・可視化する仕組みも必要になりますが、そもそもデータベースが必 要な情報を提供していることが前提となります。 例えば、モニタリング対象の情報としては、下記のようなものがあります。 • 異常な処理の発生状況 (ex. データベースが停止していないか) • パフォーマンスの状況(ex. キャッシュヒット率が低下していないか、クエリの実行計画が変わっていないか) • HWリソースの使用状況(ex. Diskの空き領域がなくなっていないか) • データベース内部の処理状況(ex. ロック待ちが頻発していないか) これら情報を活用して、トラブル発生時の根本原因を特定し、対策や防止につなげます。
  7. 7. © 2020 NTT DATA Corporation 7 PostgreSQL モニタリング対象情報の取得方法 情報の取得には、様々な方法があり、それぞれ特徴を活かして解析を実施 • 下記以外にもトラブルシュート時などには、EXPLAINコマンドなども使用して調査することがある ① OSのツール Linuxの場合、ps(1)やiostat(1)などのOSのコマンドを活用して、サーバ全体のHWリソース消費状況などを確認できる。 ただし、データベースの挙動の詳細については把握しづらい。 ② ログ トラブルシュートでは、最初に確認し、ログ情報をもとに分析を始めることが多い。 PostgreSQLのログでは、問題の発生箇所・解決のヒントも記載されており、重要な情報源になる。 ③ PostgreSQLの内部情報 データベースの活動状況やそれらの統計情報をビュー、テーブル、関数経由で把握できる。 データベース単位、テーブル単位、プロセス単位、クエリ単位、ロック単位など、細かい情報も取得ができる。 本講演の対象
  8. 8. © 2020 NTT DATA Corporation 8 例えば、稼働統計情報に関するビュー PostgreSQLは、内部で蓄積したDBの稼働状況を「稼働統計情報」という形でビューとして提供している • backendやautovacuumなど、サーバプロセスの動的情報を集計・統計化し、稼働統計情報として、ユーザにビュー経 由で提供 ③様々なビューとして提供 statistics collector backend autovacuum checkpointer ・・・ ① 定期的に稼働情報を送信 ② 統計化して管理 運用者 SQLクエリ =# SELECT … FROM pg_stat_activity datname | pid | app | query ---------+-------+---------+-------- pgbench | 12769 | pgbench | UPDATE pgbench | 11323 | psql | SELECT pgbench | 12770 | pgbench | UPDATE pgbench | 12771 | pgbench | UPDATE pgbench | 12772 | pgbench | INSERT 例. PostgreSQLサーバで 実行されているクエリ取得 稼働統計情報
  9. 9. © 2020 NTT DATA Corporation 9 定期的に情報を取得しておくことが大切 モニタリング時には、平常時の状態を把握しておくことが重要になる • 平常時とトラブル時の差分を把握 ⇒ 素早い問題解決が実施できる • 時系列での変化量を把握 ⇒ トラブル発生の検知などにつなげることができる ① 定期的に情報を取得 (pg_statsinfo) ② 平常時との変化を観測 (pg_stats_reporter) pg_statsinfo, pg_stats_reporterなどの 拡張機能を活用することで簡単に収集可能
  10. 10. © 2020 NTT DATA Corporation 10 PostgreSQLの内部情報を用いた 性能問題の分析イメージ
  11. 11. © 2020 NTT DATA Corporation 11 PostgreSQLの内部情報を活用した分析例 「最近データベースが遅くなった」という場合を想定し、原因を特定をする過程のパターンをご紹介 • トラブルシュートで特によく利用するビューやテーブルを取り上げます アプリケーション クエリの応答が全然返ってこない! スループットが下がった!
  12. 12. © 2020 NTT DATA Corporation 12 Backend 問題特定の進め方 問題を特定していくためには、クエリ処理の流れを把握しておくことが大切 • 確認すべきビューを把握するためにも必要になる クエリ処理の概要 クライアント SELECT/INSERT/ UPDATE/DELETE ②クエリの実行 (Query Execution) ①実行計画の作成 (Query Planning) ②では、インデックスやテーブルへのアクセ スが発生する 共有バッファ上にアクセスし、データが存在 しなければ、Disk上のデータを取得する。 排他制御も実施。 データファイル 共有バッファ (Buffer IO) 排他 制御 クライアント クライアント
  13. 13. © 2020 NTT DATA Corporation 13 Backend DB単位で処理状況を確認 “pg_stat_database” ビューで、DB単位(※)で統計情報を確認可能 • まずはマクロな視点(DB単位)から原因を切り分けて、ミクロな視点(クエリ単位など)に詳細化していく クエリ処理の概要 クライアント SELECT/INSERT/ UPDATE/DELETE ②クエリの実行 (Query Execution) ①実行計画の作成 (Query Planning) ②では、インデックスやテーブルへのアクセ スが発生する 共有バッファ上にアクセスし、データが存在 しなければ、Disk上のデータを取得する。 排他制御も実施。 データファイル 共有バッファ (Buffer IO) 排他 制御 クライアント クライアント (※) PostgreSQLは、1つのインスタンスに複数DBを作成できる
  14. 14. © 2020 NTT DATA Corporation 14 pg_stat_databaseの項目 pg_stat_databaseの情報(よく利用する項目を抜粋) ※DB単位で統計情報は出力される # コミット/ロールバック数 xact_commit | 4207296 xact_rollback | 57 # 更新・参照件数など tup_returned | 291951289 tup_fetched | 15978127 tup_inserted | 59411718 tup_updated | 12616512 tup_deleted | 294 # 読み込み時に共有バッファに存在していた/存在していなかったブロック数 blks_hit | 115024816 blks_read | 7071907 # データファイルのブロック読み込み・書き込みに費やされた合計時間(track_io_timingパラメータの有効化が必要) blk_read_time | 14235 blk_write_time | 214
  15. 15. © 2020 NTT DATA Corporation 15 pg_stat_databaseの情報(よく利用する項目を抜粋) ※DB単位で統計情報は出力される # コミット/ロールバック数 xact_commit | 4207296 xact_rollback | 57 # 更新・参照件数など tup_returned | 291951289 tup_fetched | 15978127 tup_inserted | 59411718 tup_updated | 12616512 tup_deleted | 294 # 読み込み時に共有バッファに存在していた・ 存在していなかったブロック数 blks_hit | 115024816 blks_read | 7071907 # データファイルのブロック読み込み・書き込みに費やされた合計時間 blk_read_time | 14235 blk_write_time | 214 pg_stat_databaseで見るべきポイント 共有バッファ上のデータのヒット状況を把握するために利用。 通常時と比較して、ヒット率が低くなっている場合は、 Disk上 のデータにアクセスがより高頻度で発生している可能性がある ⇒ 他のクエリからの大量のINSERTが発生しているなど、共有 バッファ領域が不足している可能性がある データファイル 共有バッファ (Buffer IO) blks_hit (高速) blks_read (低速)
  16. 16. © 2020 NTT DATA Corporation 16 pg_stat_databaseの情報(よく利用する項目を抜粋) ※DB単位で統計情報は出力される # コミット/ロールバック数 xact_commit | 4207296 xact_rollback | 57 # 更新・参照件数など tup_returned | 291951289 tup_fetched | 15978127 tup_inserted | 59411718 tup_updated | 12616512 tup_deleted | 294 # 読み込み時に共有バッファに存在していた/存在していなかったブロック数 blks_hit | 115024816 blks_read | 7071907 # データファイルのブロック読み込み・ 書き込みに費やされた合計時間 blk_read_time | 14235 blk_write_time | 214 pg_stat_databaseで見るべきポイント ブロック情報の読み込み・書き込み時間を知るために利用 (事前に track_io_timing を有効化しておく必要がある) 共有バッファへのキャッシュヒット率が高いにも関わらず、読み込 み時間が増加している場合 ⇒ Disk故障などが原因になっている可能性がある データファイル 共有バッファ (Buffer IO) キャッシュヒット率高い ココが遅い ⇒ Disk故障やDiskへの 多重アクセスなど?
  17. 17. © 2020 NTT DATA Corporation 17 Backend クエリ単位で処理状況を確認 “pg_stat_statements” ビュー(※)で、クエリ単位で統計情報を確認可能 • ミクロな視点(クエリ単位など)で状況を確認できる。特定のクエリだけの問題なのか等を特定可能 クエリ処理の概要 クライアント SELECT/INSERT/ UPDATE/DELETE ②クエリの実行 (Query Execution) ①実行計画の作成 (Query Planning) ②では、インデックスやテーブルへのアクセ スが発生する 共有バッファ上にアクセスし、データが存在 しなければ、Disk上のデータを取得する。 排他制御も実施。 データファイル 共有バッファ (Buffer IO) 排他 制御 クライアント クライアント (※)事前に拡張機能をインストール・有効化しておく必要がある
  18. 18. © 2020 NTT DATA Corporation 18 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
  19. 19. © 2020 NTT DATA Corporation 19 pg_stat_statementsの項目 pg_stat_statementsの情報(一部項目を抜粋) ※クエリ単位で統計情報は出力される # ブロック操作状況 shared_blks_hit | 770183 shared_blks_read | 0 shared_blks_dirtied | 10 shared_blks_written | 22 # ブロック読み込み・書き込みに費やされた合計時間(track_io_timingパラメータの有効化が必要) blk_read_time | 0 blk_write_time | 0 # 生成したWALレコード(v13~) wal_records | 258394 wal_fpi | 0 wal_bytes | 19269318
  20. 20. © 2020 NTT DATA Corporation 20 本資料で深堀りする事象 pg_stat_statementsの情報(一部項目を抜粋) ※クエリ単位で統計情報は出力される # クエリ 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 特定クエリの実行時間が長くなっているかどうかを把握できる 通常時と比較して、特定のクエリの実行時間だけが長くなっている 場合、アプリケーション処理のボトルネックになっている可能性がある ⇒ 本クエリについて詳細に分析を進める必要があるので、 リアルタイムなクエリの実行状態を確認してみる
  21. 21. © 2020 NTT DATA Corporation 21 まさに今実行されている状況を確認できる pg_stat_activityビュー “pg_stat_activity” ビューでクエリ処理を受け付けるBackendの処理状況を確認できる • DBサーバ側のクエリ処理状況をリアルタイムで確認するために利用する Backend クエリ処理の概要 クライアント SELECT/INSERT/ UPDATE/DELETE ②クエリの実行 (Query Execution) ①実行計画の作成 (Query Planning) ②では、インデックスやテーブルへのアクセ スが発生する 共有バッファ上にアクセスし、データが存在 しなければ、Disk上のデータを取得する。 排他制御も実施。 データファイル 共有バッファ (Buffer IO) 排他 制御 クライアント クライアント
  22. 22. © 2020 NTT DATA Corporation 22 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
  23. 23. © 2020 NTT DATA Corporation 23 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 待機イベントは、処理を待っている理由を示す。 ボトルネックとなっている可能性がある事象を確認することができる。 ※ 注意点として、ビューを参照したときの待機状態しか出力されな い。そのため、複数回実行して、傾向を確認した方がよい 例えば、 ・ロックイベントが頻発している場合 ⇒ ロック競合が発生している可能性あり。 ロックの詳細を確認する(次ページ)
  24. 24. © 2020 NTT DATA Corporation 24 ロック待ちが多い場合 システムカタログの “pg_locks” でロック情報の詳細を確認できる • ロックの粒度、ロックを保持しているトランザクション・プロセス、原因の絞り込みが実施できる Backend クエリ処理の概要 クライアント SELECT/INSERT/ UPDATE/DELETE ②クエリの実行 (Query Execution) ①実行計画の作成 (Query Planning) ②では、インデックスやテーブルへのアクセ スが発生する 共有バッファ上にアクセスし、データが存在 しなければ、Disk上のデータを取得する。 排他制御も実施。 データファイル 共有バッファ (Buffer IO) クライアント クライアント 排他 制御
  25. 25. © 2020 NTT DATA Corporation 25 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予定)しているロックモード
  26. 26. © 2020 NTT DATA Corporation 26 (参考)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例)
  27. 27. © 2020 NTT DATA Corporation 27 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 pg_locksで見るべきポイント 本サーバプロセスをブロックしているプロセスのPID
  28. 28. © 2020 NTT DATA Corporation 28 pg_locksなどの情報(よく利用する項目を抜粋) # トランザクションに関する情報 pid | 21060 # ロックを保持(or予定)しているプロセスID database | pgbench # データベース名 relname | pgbench_tellers # リレーションのOID 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で見るべきポイント locktypeはロック対象のオブジェクト。対象オブジェクトによって、想 定される原因が異なる ・locktype=relationの場合 表ロック。競合している場合、ALTER TABLE、CLUSTERなど が並行して走っている可能性が想定される ・locktype=transactionid or tupleの場合 行ロック。競合している場合、同一行に対するUPDATEが並行 して、集中して発生している可能性が想定される ・locktype=extendの場合 テーブル拡張のためのロック。同一テーブルにINSERTが集中し ている可能性が想定される
  29. 29. © 2020 NTT DATA Corporation 29 pg_locksなどの情報(よく利用する項目を抜粋) # トランザクションに関する情報 pid | 21060 # ロックを保持(or予定)しているプロセスID database | pgbench # データベース名 relname | pgbench_tellers # リレーションのOID 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で見るべきポイント modeは、同時アクセスを制御するためのロックモード 例えば、RowExclusiveLockの場合は、 テーブルのデータを変更する場合に獲得される ⇒ UPDATE/DELETE/INSERTなどが並行して走っている可能性 が想定される (※)ロックモードによって、同時制御の可否が決定する https://www.postgresql.org/docs/13/explicit-locking.html
  30. 30. © 2020 NTT DATA Corporation 30 ご紹介した分析事例の一例 「データベースの応答が最近遅くなった」場合を想定し、原因特定をする過程の数パターンをご紹介 • 内部の情報が提供されていることで、トラブル発生時の原因の絞り込みや問題検知が実施しやすくなっている データベースの応答が 最近に遅くなった pg_stat_database pg_stat_activity pg_stat_statements データ更新が大量に発生してい ないかなど、原因を追加調査 全体的にブロック読み込み時間が増加 同一テーブルにINSERTが集中して発 生していないかなど、原因を追加調査 (pg_stat_user_tablesなどを活用) DB単位 クエリ単位 pg_locks 特定のクエリが遅い ⇒ 待機イベントを確認 ロック待ちが多い ⇒ ロックの詳細確認 Diskの故障が発生していない かなど、原因を追加調査 全体的にキャッシュヒット率が低下 状況に応じて、原因を追加調査 その他も事象は多数… (平常時との変化など)
  31. 31. © 2020 NTT DATA Corporation 31 その他の内部情報を取得するための方法 https://pgstats.dev/ 他にも分析に役立つ内部情報は多数存在しており、原因の絞り込みの際には、それらを組み合わせて活用していく必要がある • 処理レイヤごとに内部状態を把握するための方法を一覧化しているサイト(pgstats.dev)がある
  32. 32. © 2020 NTT DATA Corporation 32 最近のバージョンで追加されたメトリクス すでに多数の内部情報が提供されていますが、バージョンアップに伴い、進化し続けている • 社会インフラ系基幹システムなどへの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 の進捗状況が分かるビューが追加 などなど多数…
  33. 33. © 2020 NTT DATA Corporation 33 さらなる安定稼働を目指すためのモニタリング
  34. 34. © 2020 NTT DATA Corporation 34 さらなる安定稼働を目指すためのモニタリング PostgreSQLのモニタリング情報は現在も拡充を続けています。 以下、NTTデータが提案・開発に携わっている2つの機能(※)をご紹介します。 • バックエンドプロセスのメモリ利用状況に関する情報 • DBクラスタ全体のWALに関する統計情報 ※いずれも2020/12/16時点では、masterブランチコミット済。次期メジャーバージョンであるPostgreSQL 14で利用可能になる予定ですが、今後変更などが加わる可能性もあります。
  35. 35. © 2020 NTT DATA Corporation 35 バックエンドプロセスのメモリ利用状況に関する情報 ~MemoryContextの確認~
  36. 36. © 2020 NTT DATA Corporation 36 MemoryContextとは PostgreSQLでは、MemoryContextと呼ばれる単位を使って、Tree構造でメモリを管理 • 用途に応じたMemoryContextを作成し、メモリを割り当て(palloc) • 親のMemoryContextが削除されると、その子孫のMemoryContextも全て削除 ⇒ 構造化されているため、メモリ管理がmalloc()よりも容易に TopMemoryContext CacheMemoryContext TopPortalContext TopTransactionContext … … Context … Context 親は1つ 子は複数可 ※TopMemoryContextは親なし Context … Context …
  37. 37. © 2020 NTT DATA Corporation 37 MemoryContextの情報を取得する必要性 特定のContextが肥大化したり、大量のContextが作成されることで、メモリを逼迫することがある 例) • PostgreSQL内部のキャッシュ(relcacheなど)増加 • 大量のPreparedStatement • メモリリーク OSからはPostgreSQLプロセスのメモリが肥大化していることはわかるが、PostgreSQLが何にメモリを利用して いるかまではわからない 現在のPostgreSQL V13では、 MemoryContextの情報を得るにはデバッガが必要。 商用環境などではデバッガやデバッグシンボルが導入されていないなどの理由で使えないことも 実行例 (gdb) call MemoryContextStats(TopMemoryContext)
  38. 38. © 2020 NTT DATA Corporation 38 V14でできるようになること(予定) pg_backend_memory_contextsビューからローカルプロセスのMemoryContextをSQLで確認可能 • 内容はデバッガ経由で取得した場合と同等 Contextを特定する情報があれば、identに出力される 例) PREPARE文を実行した場合 階層の深さはlevelで表現
  39. 39. © 2020 NTT DATA Corporation 39 DBクラスタ全体のWALに関する統計情報
  40. 40. © 2020 NTT DATA Corporation 40 WALモニタリングの必要性 • WAL(Write Ahead Logging)は、 トランザクションの内容をテーブルなどデータファイルに書き込む前に、 ログとして記録しておく手法 • クラッシュリカバリ、物理バックアップ、レプリケーションでも利用される重要な仕組み • ディスクへの永続化をすることもあり、更新が多いワークロードなどの場合、WAL書き出しがDisk I/Oのボト ルネックになることも
  41. 41. © 2020 NTT DATA Corporation 41 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、オンラインバックアップの仕組み)」が詳しいので、ご興味のある方はご参考ください。
  42. 42. © 2020 NTT DATA Corporation 42 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への書き込みが発生した回数
  43. 43. © 2020 NTT DATA Corporation 43 WALバッファが溢れてDiskへ書き込みが発生、とは バックエンドはWALバッファにWALを書き込み、WALバッファ上のデータは、通常はWAL writerが定期的に Diskに書き出す • バックエンドはメモリ上の操作のみなので高速 • ただし、WAL writerのDisk書き出しが間に合わない場合は... WALファイル Memory Disk WALバッファ バックエンド WAL writer 定期的にバックグラウン ドで書き出し クライアント BEGIN; 操作を記録 INSERT ... INSERT ...
  44. 44. © 2020 NTT DATA Corporation 44 WALバッファが溢れてDiskへ書き込みが発生、とは WALバッファが一杯になっていると、バックエンドがWALバッファを書き出さざるを得ない • Diskへの同期書き込みが発生するため、クエリ処理の性能劣化を生み出す WALファイル Memory Disk WALバッファ バックエンド クライアント BEGIN; INSERT … INSERT … 操作を記録 WAL writer バックエンドが同 期書き込み ※ 間に合っていない (WALバッファが小さい、 書き込み間隔が長いなど)
  45. 45. © 2020 NTT DATA Corporation 45 まとめ • モニタリングは、システムが正常に動作しているか把握したり、トラブルの原因を把握するた めに必要 • データベースのモニタリングでは、稼働統計情報などデータベース内部の状態を観察できる 手段がある • 基本的なモニタリング情報は抑えておくとよい pg_stat_database, pg_stat_statements, pg_stat_activity, pg_locksなど • PostgreSQLのモニタリング情報は現在も進化し続けている 追加したいモニタリング項目などがあれば検討したいので、ぜひ教えてください!
  46. 46. 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
  47. 47. © 2020 NTT DATA Corporation

×