稼動統計情報を活用しよう(3)

稼動統計情報を活用しよう(3)

NTT オープンソースソフトウェアセンタ 笠原 辰仁

 

有用な情報を持つテーブル / ビュー

稼動統計情報を持つテーブルとビューの一部について、どのような情報を蓄積しているかを紹介します。前ページで稼動統計情報の取得方法を述べましたが、紹介したもの以外にも、下記に示すように色々な情報が取得できます。

pg_stat_database

DB単位で、実施された表スキャンやインデックススキャン数などが確認できます。DB単位でざっくりとしたアクティビティ状況を確認するのに便利です。このビューでは下記の項目を確認できます。

pg_stat_database
名前 ver. 説明
datid   データベースのOID
datname   データベース名
numbackends   接続中のバックエンドプロセス数
xact_commit   コミットされた回数
xact_rollback   ロールバック(アボート)された回数
blks_read   ブロックリード数
blks_hit   ブロックのキャッシュヒット数
tup_returned 8.3 表スキャンでの読み取り行数
tup_fetched 8.3 インデックススキャンでの読み取り行数
tup_inserted 8.3 INSERTされた行数
tup_updated 8.3 UPDATEされた行数
tup_deleted 8.3 DELETEされた行数

pg_stat_user_tables / pg_stat_sys_tables / pg_stat_all_tables

各テーブルへ実施された表スキャンやインデックススキャン回数など詳細な情報が確認できます。*_user_tablesはユーザテーブルの情報、*_sys_tablesはシステムカタログの情報、*_all_tablesはユーザテーブルとシステムテーブル双方の情報を、それぞれ出力します。通常はpg_stat_user_tablesを見ておけば良いです。このビューでは下記の項目を確認できます。

pg_stat_*_tables
名前 ver. 説明
relid   テーブルのOID
schemaname   スキーマ名
relname   テーブル名
seq_scan   このテーブルに対する表スキャンの実行回数
seq_tup_read   表スキャンによって読みとられた行数
idx_scan   このテーブルに対するインデックススキャンの実行回数
idx_tup_fetch   インデックススキャンで読み取られた行数
n_tup_ins   INSERTされた行数
n_tup_upd   UPDATEされた行数 (HOT更新されたものも含む)
n_tup_del   DELETEされた行数
n_tup_hot_upd 8.3 HOT更新された行数
n_live_tup 8.3 保持されている有効な行数
n_dead_tup 8.3 不要な(ガベージとなっている)行数
last_vacuum 8.2 このテーブルに対する最後の VACUUM の完了時刻
last_autovacuum 8.2 このテーブルに対する最後の autovacuum (VACUUM) の完了時刻
last_analyze 8.2 このテーブルに対する最後の ANALYZE の完了時刻
last_autoanalyze 8.2 このテーブルに対する最後の autovacuum (ANALYZE) の完了時刻

pg_stat_user_indexes / pg_stat_sys_indexes / pg_stat_all_indexes

各インデックスへ実施されたスキャン回数が確認できます。user_indexes、sys_indexesなどの違いは、pg_stat_*_tablesと同様です。

pg_stat_*_indexes
名前 説明
relid インデックスが付与されているテーブルのOID
indexrelid インデックスのOID
schemaname スキーマ名
relname テーブル名
indexrelname インデックス名
idx_scan インデックススキャン実施回数
idx_tup_read インデックススキャンによって読み取られたインデックスエントリの数
idx_tup_fetch IndexScanによって読み取られたエントリの数 (BitmapScan によるものを除く)

pg_statio_user_tables / pg_statio_sys_tables / pg_statio_all_tables

各テーブルへ実施されたブロックアクセス状況が確認できます。user_tables、sys_tablesなどの違いは、pg_stat_*_tablesと同様です。

pg_statio_*_tables
名前 説明
relid テーブルのOID
schemaname スキーマ名
relname テーブル名
heap_blks_read テーブルブロックの読み込み数
heap_blks_hit キャッシュヒットしたテーブルブロック数
idx_blks_read インデックスブロックの読み込み数
idx_blks_hit キャッシュヒットしたインデックスブロック数
toast_blks_read TOASTテーブルのブロックの読み込み数
toast_blks_hit キャッシュヒットしたTOASTテーブルのブロック数
tidx_blks_read TOASTインデックスのブロックの読み込み数
tidx_blks_hit キャッシュヒットしたTOASTインデックスのブロック数

pg_statio_user_indexes / pg_statio_sys_indexes / pg_statio_all_indexes

各インデックスへ実施されたブロックアクセス状況が確認できます。user_indexes、sys_indexesなどの違いは、pg_stat_*_tablesと同様です。

pg_statio_*_indexes
名前 説明
relid インデックスの付与されているテーブルのOID
indexrelid インデックスのOID
schemaname スキーマのOID
relname テーブル名
indexrelname インデックス名
idx_blks_read インデックスブロックの読み込み数
idx_blks_hit キャッシュヒットしたインデックスのブロック数

pg_stat_activity

現在実施中の処理内容や開始時間を確認できます。

pg_stat_activity
名前 ver. 説明
datid   処理が実施されているDBのOID
datname   DB名
procpid   プロセスID
usesysid   処理を実施しているユーザのOID
usename   ユーザ名
current_query   現在実施されている問い合わせ
  • IDLE: 接続しているだけでアイドル
  • IDLE in transaction: トランザクション中でアイドル
waiting 8.2 処理がロック待ちかどうか (tならロック待ち)
query_start   現在実施されている処理の開始時刻
xact_start 8.3 トランザクションの開始時刻
backend_start 8.1 接続しているバックエンドの開始時刻
client_addr 8.1 クライアントのIPアドレス (localhostの場合はNULL)
client_port 8.1 現在接続しているポート番号 (UNIXのドメインソケットの場合は-1)

pg_locks

PostgreSQLで現在実施されている処理のロック状況を確認できます。pg_stat_activityなどと組み合わせると、ロックを保持している処理などが把握できます。

テーブルの内容はJPUGのマニュアルを参考にして下さい。(PostgreSQL 文書: pg_locks)

pg_class

DB内のテーブルやインデックスのメタ情報を管理するテーブルです。稼動統計情報やシステムカタログと組み合わせて使用することが多いです。典型的には、OID (PostgreSQLインスタンスで一意となるオブジェクトID) とオブジェクト名 (テーブル名やインデックス名) を結びつける際に pg_class が用いられます。OID は下記の様に pg_class のシステムカラム oid (隠しカラム) を指定することで確認できます。同じ名前のテーブルが異なるスキーマにある場合などは、テーブル名ではなくOIDで判別/結合すると安心です。

-- 2つのスキーマに 'test' テーブルがある場合
=# SELECT oid, relname, relnamespace FROM pg_class WHERE relname='test';
  oid  | relname | relnamespace
-------+---------+--------------
 24958 | test    |         2200
 24965 | test    |        24964
(2 rows)

テーブルの内容はJPUGのマニュアルを参考にして下さい。(PostgreSQL 文書: pg_class)

稼動統計情報に関する注意点

稼動統計情報を扱う上で、以下の注意点を覚えておいて下さい。

PostgreSQLのクラッシュ発生時に情報がクリアされる

稼動統計情報は常時メモリ上に存在しており、PostgreSQLの停止時にはファイルに書き出され、再び起動された際にそのファイルを読み込んでメモリ上に展開されます。そのため、PostgreSQLのクラッシュ時は統計情報のダンプが適切にされないため、稼動統計情報がクリアされます。

外部リンク

稼動統計情報については、JPUGオンラインマニュアルの「統計情報収集のための設定」や「収集した統計情報の表示」に詳細な情報が記載されています。

さて、いかがでしたでしょうか？ここで紹介したもの以外にも、PostgreSQLはたくさんの情報を収集・保持しています。これらを使いこなせると、チューニングやトラブルシューティングを効果的に行うことができます。是非、活用してみてください。