他のバージョンの文書 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

第 23章データベース活動状況の監視

目次
23.1. 標準的な Unix ツール
23.2. 統計情報収集器
23.2.1. 統計情報収集のための設定
23.2.2. 収集した統計情報の表示
23.3. ロックの表示

データベース管理者はよく、"システムは今現在正しく動作しているか" を気にします。 本章では監視方法について説明します。

データベース活動状況の監視と性能解析用のツールは多く存在します。 この章の大部分はPostgreSQL の統計情報収集器の説明に費やされていますが、pstop などの通常の Unix 監視プログラムを無視すべきではありません。 また、性能が悪い問い合わせであると認知された問い合わせは、その後、PostgreSQLEXPLAIN コマンドを使用して調査を行なう必要が発生します。 項13.1では、個々の問い合わせの振舞いを理解するための、EXPLAIN やその他の方法について記載しています。

23.1. 標準的な Unix ツール

ほとんどのプラットホームでは、PostgreSQL は、個々のサーバプロセスが容易に識別できるように、ps によって報告されるコマンドタイトル部分を変更します。 以下に表示例を示します。

$ ps auxww | grep ^postgres
postgres   960  0.0  1.1  6104 1480 pts/1    SN   13:17   0:00 postmaster -i
postgres   963  0.0  1.1  7084 1472 pts/1    SN   13:17   0:00 postgres: stats buffer process   
postgres   965  0.0  1.1  6152 1512 pts/1    SN   13:17   0:00 postgres: stats collector process   
postgres   998  0.0  2.3  6532 2992 pts/1    SN   13:18   0:00 postgres: tgl runbug 127.0.0.1 idle
postgres  1003  0.0  2.4  6532 3128 pts/1    SN   13:19   0:00 postgres: tgl regression [local] SELECT waiting
postgres  1016  0.1  2.4  6532 3080 pts/1    SN   13:19   0:00 postgres: tgl regression [local] idle in transaction

(ps の適切な呼び出し方はプラットホームによって異なります。 同様に、何が詳細に表示されるのかも異なります。 この例は最近の Linux システムのものです。) この一覧の最初のプロセスはpostmasterであり、マスタサーバプロセスです。 表示されているコマンド引数は、起動時に指定したものと同じものです。 次の 2 つのプロセスは、次節で詳細を説明する統計情報収集器を行なうものです。 (システムを統計情報収集器を起動しないように設定していた場合はこれらはありません。) 残るプロセスはそれぞれ、1 つのクライアント接続を取り扱うサーバプロセスです。 それぞれのプロセスは、次の形式のコマンドライン表示を設定します。

postgres: user database host activity

ユーザ、データベース、接続元ホストという項目はクライアントの存続期間中変更されることはありませんが、活動状況を示す部分は変わります。 活動状況は、idle (つまり、クライアントからのコマンド待ち状態)、idle in transaction (BEGIN ブロックの内側でのクライアントの待ち状態)、または SELECT のようなコマンド種類名のいずれかとなります。 また、そのサーバプロセスが他のサーバプロセスによって保持されたロックを待っている状態の場合は、waiting が付与されます。 上の例では、1003 プロセスは 1016 プロセスにおけるトランザクションの完了とそれに伴うロックなどの解放を待っていると推測することができます。

ティップ: Solaris では特別な取り扱いが必要です。 /bin/ps ではなく、/usr/ucb/ps を使用しなければなりません。 また、w フラグを 1 つではなく 2 つ使用しなければなりません。 更に、元の postmaster の呼び出しに関する ps のステータス表示は、各サーバプロセスに関するステータス表示よりも短くなければなりません。 この 3条件を全て満たさないと、各サーバプロセスの ps の出力は、元の postmaster のコマンドラインのものになってしまいます。