PostgreSQLで監視する重要事項-ワークロードの分析

コンピュータシステムでは、監視とは、メトリックの収集、分析、統計の計算、システムのパフォーマンスまたは容量に関する要約とグラフの生成、および予期しない問題や障害が発生した場合にアラートを生成するプロセスです。したがって、監視には2つの用途があります。1つはシステム内の中長期的な傾向を特定してアップグレードの計画を立てるのに役立つ履歴データの分析と表示、もう1つは問題が発生した場合の即時アクションです。

監視は、問題を特定し、次のような幅広い分野に関する問題に対応するのに役立ちます。

インフラストラクチャ/ハードウェア（物理または仮想）
ネットワーク
ストレージ
システムソフトウェア
アプリケーションソフトウェア
セキュリティ

監視はDBAの作業の主要な部分です。 PostgreSQLは、その洗練された設計のおかげで、伝統的に「メンテナンスが少ない」ことが知られており、これは、他の代替手段と比較した場合、システムが少ない出席で生きることができることを意味します。ただし、高可用性とパフォーマンスが非常に重要である深刻なインストールの場合、データベースシステムを定期的に監視する必要があります。

PostgreSQL DBAの役割は、厳密に技術的なだけでなく、会社の階層内でより高いレベルにステップアップできます。基本的な監視とパフォーマンス分析とは別に、使用パターンの変化を見つけ、考えられる原因を特定し、仮定を検証し、最後に翻訳する必要があります。ビジネス用語での調査結果。例として、DBAは、セキュリティ上の脅威の可能性に関連している可能性のある特定のアクティビティの突然の変化を識別できなければなりません。したがって、PostgreSQL DBAの役割は社内の重要な役割であり、発生する問題を特定して解決するために、他の部門の責任者と緊密に連携する必要があります。監視はこの責任の大きな部分です。

PostgreSQLには、データの収集と分析に役立つ多くのすぐに使えるツールが用意されています。さらに、その拡張性により、新しいモジュールをコアシステムに開発する手段を提供します。

PostgreSQLは、それが実行されているシステム（ハードウェアとソフトウェア）に大きく依存しています。システムの他の部分の重要なコンポーネントのいずれかに問題がある場合、PostgreSQLサーバーが良好に機能することは期待できません。したがって、PostgreSQLDBAの役割はsysadminの役割と重複しています。以下では、PostgreSQLの監視で何を監視するかを検討しているときに、システムに依存する変数とメトリックの両方、およびPostgreSQLの特定の数値に遭遇します。

モニタリングは無料ではありません。監視プロセス全体を管理および維持することを約束する企業/組織は、それに適切な投資を行う必要があります。また、PostgreSQLサーバーにもわずかな負荷がかかります。これは、すべてが正しく構成されているかどうかを心配することはほとんどありませんが、これはシステムを誤用する別の方法である可能性があることに注意する必要があります。

システム監視の基本

システム監視の重要な変数は次のとおりです。

CPU使用率
ネットワークの使用
ディスク容量/ディスク使用率
RAMの使用法
ディスクIOPS
スワップスペースの使用量
ネットワークエラー

これは、pgbench -c 64 -t 1000 pgbenchを2回実行しているときに、pg_stat_databaseおよびpg_stat_bgwriter（次の段落で説明します）からのいくつかの重要なPostgreSQL変数のグラフを示すClusterControlの例です。

ブロックにピークがあることに気づきました。最初の実行で読み取りましたが、すべてのブロックがshared_buffersにあるため、2回目の実行でゼロに近づきます。

関心のある他の変数は、とりわけ、ページングアクティビティ、割り込み、コンテキストスイッチです。 Linux/BSDやUNIXまたはUNIXライクなシステムで使用できるツールはたくさんあります。それらのいくつかは次のとおりです：

ps：実行中のプロセスのリストについて
top / htop / systat：システム（CPU /メモリ）使用率の監視用
vmstat：一般的なシステムアクティビティ（仮想メモリを含む）の監視用
iostat / iotop / top -mio：IOモニタリング用
ntop：ネットワーク監視用

これは、ディスクの読み取りと計算を必要とするクエリ中のFreeBSDボックスでのvmstatの例です。

procs  memory      page                         disks      faults          cpu
r b w  avm   fre   flt   re  pi  po   fr    sr  ad0 ad1  in     sy    cs us sy id
0 0 0  98G  666M   421   0   0   0   170  2281    5  0  538   6361  2593  1  1 97
0 0 0  98G  665M   141   0   0   0     0  2288   13  0  622  11055  3748  3  2 94
--- query starts here ---
0 0 0  98G  608M   622   0   0   0   166  2287 1072  0 1883  16496 12202  3  2 94
0 0 0  98G  394M   101   0   0   0     2  2284 4578  0 5815  24236 39205  3  5 92
2 0 0  98G  224M  4861   0   0   0  1711  2287 3588  0 4806  24370 31504  4  6 91
0 0 0  98G  546M    84 188   0   0 39052 41183 2832  0 4017  26007 27131  5  7 88
2 0 0  98G  469M   418   0   0   1   397  2289 1590  0 2356  11789 15030  2  2 96
0 0 0  98G  339M   112   0   0   0   348  2300 2852  0 3858  17250 25249  3  4 93
--- query ends here ---
1 0 0  98G  332M  1622   0   0   0   213  2289    4  0  531   6929  2502  3  2 95

クエリを繰り返すと、ディスクのこれらのブロックはすでにOSのキャッシュにあるため、ディスクアクティビティの新しいバーストは発生しません。 PostgreSQL DBAは、データベースが実行されている基盤となるインフラストラクチャで何が起こっているかを完全に理解できる必要がありますが、これはそれ自体が大きなトピックであるため、通常、より複雑なシステム監視がシステム管理者の仕事です。

Linuxでは、トップの非常に便利なショートカットユーティリティは「C」を押しています。これにより、プロセスのコマンドラインの表示が切り替わります。 PostgreSQLはデフォルトで、バックエンドのコマンドラインを、バックエンドが現在実行している実際のSQLアクティビティとユーザーで書き換えます。

PostgreSQLモニタリングの基本

PostgreSQLモニタリングの重要な変数は次のとおりです。

バッファキャッシュのパフォーマンス（キャッシュヒットとディスク読み取り）
コミット数
接続数
セッション数
チェックポイントとbgwriter統計
掃除機
ロック
レプリケーション
最後になりましたが、間違いなく重要なのは、クエリです

一般に、データ収集を実行するための監視設定には2つの方法があります。

ログを介してデータを取得するには
PostgreSQLシステムにクエリを実行してデータを取得するには

ログファイルベースのデータ取得は、（適切に構成された）PostgreSQLログに依存します。この種のロギングは、データの「オフライン」処理に使用できます。ログファイルベースの監視は、PostgreSQLサーバーへの最小限のオーバーヘッドが必要な場合、およびライブデータやライブアラートの取得を気にしない場合に最適です（ただし、ログファイルデータを使用したライブ監視は、postgresqlログをsyslogに送信することで可能です。次に、syslogをログ処理専用の別のサーバーにストリーミングします。

今日のホワイトペーパーをダウンロードするClusterControlを使用したPostgreSQLの管理と自動化PostgreSQLの導入、監視、管理、スケーリングを行うために知っておくべきことについて学ぶホワイトペーパーをダウンロードする

PostgreSQL統計コレクター

PostgreSQLは、StatisticsCollectorサブシステムを介してすぐに利用できる豊富なビューと機能のセットを提供します。ここでも、これらのデータは2つのカテゴリに分類されます。

システムが現在実行していることに関する動的な情報。
統計コレクタサブシステムが最後にリセットされてから蓄積された統計。

動的統計ビュー プロセスごとの現在のアクティビティ（pg_stat_activity）、物理レプリケーションのステータス（pg_stat_replication）、物理スタンバイのステータス（pg_stat_wal_receiver）または論理（pg_stat_subscription）、ssl（pg_stat_ssl）、およびバキューム（pg_stat_progress_vacuum）に関する情報を提供します。

収集された統計ビュー walアーカイバ、bgwriter、データベースオブジェクト（ユーザーまたはシステムテーブル、インデックス、シーケンス、関数、データベース自体）などの重要なバックグラウンドプロセスに関する情報を提供します。

監視に関連するデータを分類する方法が複数あることは、今ではかなり明白になっているはずです。

ソース別：
- システムツール（ps、top、iotopなど）
- PgSQLログファイル
- データベース
  - 動的
  - 収集済み
特定のデータベース操作による：
- バッファキャッシュ
- コミット
- クエリ
- セッション
- チェックポイント
- その他

この記事を読み、提示された概念、概念、および用語を試してみると、考えられるすべての組み合わせで2Dマトリックスを作成できるはずです。例として、特定のPostgreSQLアクティビティ（SQLコマンド）は、psまたはtop（システムユーティリティ）、PostgreSQLログファイル、pg_stat_activity（動的ビュー）を使用して見つけることができますが、contrib（収集された統計ビュー）で見つかった拡張機能pg_stat_statementsも使用します。。同様に、ロックに関する情報はPostgreSQLログファイル pg_locksにあります。およびpg_stat_activity （すぐ下に表示） wait_eventを使用およびwait_event_type 。このため、監視の広大な領域を一次元的に線形にカバーすることは困難であり、著者はこれのために読者に混乱を引き起こす危険性があります。これを回避するために、公式ドキュメントのコースに従い、必要に応じて関連情報を追加することにより、監視について大まかに説明します。

動的統計ビュー

pg_stat_activityの使用さまざまなバックエンドプロセスによる現在のアクティビティを確認できます。たとえば、約300万行のテーブルパーツに対して次のクエリを実行するとします。

testdb=# \d parts
                         Table "public.parts"
   Column   |          Type          | Collation | Nullable | Default
------------+------------------------+-----------+----------+---------
 id         | integer                |           |          |
 partno     | character varying(20)  |           |          |
 partname   | character varying(80)  |           |          |
 partdescr  | text                   |           |          |
 machine_id | integer                |           |          |
 parttype   | character varying(100) |           |          |
 date_added | date                   |           |          |

そして、次のクエリを実行してみましょう。完了するまでに数秒かかります。

testdb=# select avg(age(date_added)) FROM parts;

新しいターミナルを開き、前のターミナルがまだ実行されている間に次のクエリを実行すると、次のようになります。

testdb=# select pid,usename,application_name,client_addr,backend_start,xact_start,query_start,state,backend_xid,backend_xmin,query,backend_type from pg_stat_activity where datid=411547739 and usename ='achix' and state='active';
-[ RECORD 1 ]----+----------------------------------------
pid              | 21305
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.833677+02
xact_start       | 2018-03-02 18:04:35.832564+02
query_start      | 2018-03-02 18:04:35.832564+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker
-[ RECORD 2 ]----+----------------------------------------
pid              | 21187
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:02:06.834787+02
xact_start       | 2018-03-02 18:04:35.826065+02
query_start      | 2018-03-02 18:04:35.826065+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | client backend
-[ RECORD 3 ]----+----------------------------------------
pid              | 21306
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.837829+02
xact_start       | 2018-03-02 18:04:35.836707+02
query_start      | 2018-03-02 18:04:35.836707+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker

pg_stat_activityビューは、バックエンドプロセス、ユーザー、クライアント、トランザクション、クエリ、状態に関する情報、およびクエリの待機ステータスに関する包括的な情報を提供します。

しかし、なぜ3行なのですか？バージョン>=9.6では、クエリを並列で実行できる場合、またはクエリの一部を並列で実行でき、オプティマイザが並列実行が最速の戦略であると判断した場合、収集を作成します。またはGatherMerge ノード、そして最大で max_parallel_workers_per_gatherをリクエストしますバックグラウンドワーカープロセス（デフォルトでは2）、したがって上記の出力に表示される3行。 backend_type を使用すると、クライアントのバックエンドプロセスとバックグラウンドワーカーを区別できます。桁。 pg_stat_activityビューを有効にするには、システム構成パラメーター track_activitiesを確認する必要があります。オンになっています。 pg_stat_activityは、wait_event_type列とwait_event列を使用して、ブロックされたクエリを判別するための豊富な情報を提供します。

ステートメントを監視するためのより洗練された方法は、 pg_stat_statementsを使用することです。前述のcontrib拡張。最近のLinuxシステム（Ubuntu 17.10、PostgreSQL 9.6）では、これはかなり簡単にインストールできます：

testdb=# create extension pg_stat_statements ;
CREATE EXTENSION
testdb=# alter system set shared_preload_libraries TO 'pg_stat_statements';
ALTER SYSTEM
testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# \d pg_stat_statements

100000行のテーブルを作成してから、pg_stat_statementsをリセットし、PostgreSQLサーバーを再起動し、（まだコールドな）システムでこのテーブルに対して選択を実行してから、選択のpg_stat_statementsの内容を確認します。

testdb=# select 'descr '||gs as descr,gs as id into medtable from  generate_series(1,100000) as gs;
SELECT 100000
testdb=# select pg_stat_statements_reset();
 pg_stat_statements_reset
--------------------------
 
(1 row)

testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
               0 |              541
(1 row)

testdb=#

次に、select *をもう一度実行してから、このクエリのpg_stat_statementsの内容をもう一度確認します。

[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
             541 |              541
(1 row)

したがって、2回目にselectステートメントがPostgreSQL共有バッファー内の必要なすべてのブロックを検出し、pg_stat_statementsが shared_blks_hitを介してこれを報告します。。 pg_stat_statementsは、ステートメントの呼び出しの総数、total_time、min_time、max_time、mean_timeに関する情報を提供します。これは、システムのワークロードを分析するときに非常に役立ちます。非常に頻繁に実行される低速のクエリには、すぐに注意を払う必要があります。同様に、ヒット率が一貫して低い場合は、 shared_buffersを確認する必要があることを示している可能性があります。設定。

pg_stat_replication 各wal_senderのレプリケーションの現在のステータスに関する情報を提供します。プライマリと1つのホットスタンバイを使用して単純なレプリケーショントポロジを設定したとすると、プライマリでpg_stat_replicationをクエリできます（カスケードレプリケーションを設定し、この特定のスタンバイがアップストリームとして機能しない限り、スタンバイで同じことを行っても結果は得られません）他のダウンストリームスタンバイへ）レプリケーションの現在のステータスを確認するには：

testdb=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/3029DB8
write_lsn        | 0/3029DB8
flush_lsn        | 0/3029DB8
replay_lsn       | 0/3029DB8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async

4列のsent_lsn 、 write_lsn 、 flush_lsn 、 replay_lsn リモートスタンバイでのレプリケーションプロセスの各段階での正確なWAL位置を教えてください。次に、次のようなコマンドを使用して、プライマリに大量のトラフィックを作成します。

testdb=# insert into foo(descr) select 'descr ' || gs from generate_series(1,10000000) gs;

そして、pg_stat_replicationをもう一度見てください：

postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/D5E0000
write_lsn        | 0/D560000
flush_lsn        | 0/D4E0000
replay_lsn       | 0/C5FF0A0
write_lag        | 00:00:04.166639
flush_lag        | 00:00:04.180333
replay_lag       | 00:00:04.614416
sync_priority    | 0
sync_state       | async

これで、 send_lsnに示されているプライマリとスタンバイの間に遅延があることがわかります。、 write_lsn 、 flush_lsn 、 replay_lsn 値。 PgSQL 10.0以降、pg_stat_replicationは、最近ローカルでフラッシュされたWALと、リモートでの書き込み、フラッシュ、および再生にそれぞれかかった時間との間のラグも示しています。これらの3つの列にヌルが表示されている場合は、プライマリとスタンバイが同期していることを意味します。

pg_stat_replicationに相当しますスタンバイ側は次のように呼び出されます： pg_stat_wal_receiver：

testdb=# select * from pg_stat_wal_receiver ;
-[ RECORD 1 ]---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid                   | 17867
status                | streaming
receive_start_lsn     | 0/F000000
receive_start_tli     | 1
received_lsn          | 0/3163F210
received_tli          | 1
last_msg_send_time    | 2018-03-03 13:32:42.516551+00
last_msg_receipt_time | 2018-03-03 13:33:28.644394+00
latest_end_lsn        | 0/3163F210
latest_end_time       | 2018-03-03 13:32:42.516551+00
slot_name             | fbsdclone
conninfo              | user=postgres passfile=/usr/local/var/lib/pgsql/.pgpass dbname=replication host=10.0.2.2 port=20432 fallback_application_name=walreceiver sslmode=disable sslcompression=1 target_session_attrs=any

testdb=#

アクティビティがなく、スタンバイがすべてを再生した場合、 latest_end_lsn send_lsnと同じである必要がありますプライマリ（およびすべての中間ログシーケンス番号）

物理レプリケーションと同様に、プライマリの役割がパブリッシャーによって引き継がれ、スタンバイの役割がサブスクライバーによって引き継がれる論理レプリケーションの場合、当然、 pg_stat_wal_receiver pg_stat_subscriptionによって取得されます。 pg_stat_subscriptionをクエリできます次のように：

testdb=# select * from pg_stat_subscription ;
-[ RECORD 1 ]---------+------------------------------
subid                 | 24615
subname               | alltables_sub
pid                   | 1132
relid                 |
received_lsn          | 0/33005498
last_msg_send_time    | 2018-03-03 17:05:36.004545+00
last_msg_receipt_time | 2018-03-03 17:05:35.990659+00
latest_end_lsn        | 0/33005498
latest_end_time       | 2018-03-03 17:05:36.004545+00

パブリッシャー側では、対応するビューは物理レプリケーションの場合と同じであることに注意してください： pg_stat_replication 。

収集された統計ビュー

pg_stat_archiver ビューには、walアーカイバに関する情報を提供する1つの行があります。この行のスナップショットを一定の間隔で保持すると、それらの間隔の間のWALトラフィックのサイズを計算できます。また、WALファイルのアーカイブ中の障害に関する情報も提供します。

pg_stat_bgwriter ビューは、以下の動作に関する非常に重要な情報を提供します：

チェックポインター
バックグラウンドライター
（クライアントサービング）バックエンド

このビューは最後のリセット以降の累積データを提供するため、 pg_stat_bgwriterの定期的なスナップショットを使用して別のタイムスタンプ付きテーブルを作成すると非常に便利です。、2つのスナップショット間の増分パースペクティブを簡単に取得できるようにします。チューニングは科学（または魔法）であり、良好な結果を得るには、広範なロギングとモニタリング、および基礎となる概念とPostgreSQL内部の明確な理解が必要です。このビューは、次のようなものを探すための出発点です。

checkpoints_timedですか総チェックポイントの大部分？そうでない場合は、アクションを実行し、結果を測定し、改善が見つからなくなるまでプロセス全体を繰り返す必要があります。
buffers_checkpointですか他の2種類（ buffers_clean しかし、最も重要なのは buffers_backend ）？ buffers_backendが高い場合は、ここでも、特定の構成パラメーターを変更し、新しい測定値を取得して再評価する必要があります。

Pg_stat_ [user | sys | all] _tables

これらのビューの最も基本的な使用法は、バキューム戦略が期待どおりに機能することを確認することです。生きているタプルに比べて死んだタプルの値が大きいということは、バキュームが非効率的であることを意味します。これらのビューは、seq vs indexのスキャンとフェッチに関する情報、挿入、更新、削除された行数に関する情報、およびHOT更新も提供します。パフォーマンスを向上させるために、HOT更新の数をできるだけ多く保つようにする必要があります。

Pg_stat_ [user | sys | all] _indexes

ここで、システムは個々のインデックスの使用に関する情報を保存して表示します。覚えておくべきことの1つは、idx_tup_readはidx_tup_fetchよりも正確であるということです。 idx_scanが低い非PK/非一意インデックス HOTの更新を妨げるだけなので、削除を検討する必要があります。前のブログで述べたように、過剰なインデックス作成は避ける必要があります。インデックス作成にはコストがかかります。

Pg_statio_ [user | sys | all] _tables

これらのビューでは、テーブルヒープの読み取り、インデックスの読み取り、およびTOASTの読み取りに関するキャッシュのパフォーマンスに関する情報を見つけることができます。ヒットのパーセンテージをカウントする簡単なクエリと、テーブル全体でのヒットの分布は次のようになります。

with statioqry as (select relid,heap_blks_hit,heap_blks_read,row_number() OVER (ORDER BY 100.0*heap_blks_hit::numeric/(heap_blks_hit+heap_blks_read) DESC),COUNT(*) OVER () from pg_statio_user_tables where heap_blks_hit+heap_blks_read >0)
select relid,row_number,100.0*heap_blks_hit::float8/(heap_blks_hit+heap_blks_read) as "heap block hits %", 100.0 * row_number::real/count as "In top %" from statioqry order by row_number;
   relid   | row_number | heap block hits % |     In top %      
-----------+------------+-------------------+-------------------
     16599 |          1 |  99.9993058404502 | 0.373134328358209
     18353 |          2 |  99.9992251425738 | 0.746268656716418
     18338 |          3 |    99.99917566565 |  1.11940298507463
     17269 |          4 |  99.9990617323798 |  1.49253731343284
     18062 |          5 |  99.9988021889522 |  1.86567164179104
     18075 |          6 |  99.9985334109273 |  2.23880597014925
     18365 |          7 |  99.9968070500335 |  2.61194029850746
………..
     18904 |        127 |  97.2972972972973 |  47.3880597014925
     18801 |        128 |  97.1631205673759 |  47.7611940298507
     16851 |        129 |  97.1428571428571 |   48.134328358209
     17321 |        130 |  97.0043198249512 |  48.5074626865672
     17136 |        131 |                97 |  48.8805970149254
     17719 |        132 |  96.9791612263018 |  49.2537313432836
     17688 |        133 |   96.969696969697 |  49.6268656716418
     18872 |        134 |  96.9333333333333 |                50
     17312 |        135 |  96.8181818181818 |  50.3731343283582
……………..
     17829 |        220 |  60.2721026527734 |   82.089552238806
     17332 |        221 |  60.0276625172891 |  82.4626865671642
     18493 |        222 |                60 |  82.8358208955224
     17757 |        223 |  59.7222222222222 |  83.2089552238806
     17586 |        224 |  59.4827586206897 |  83.5820895522388

これは、テーブルの少なくとも50％のヒット率が96.93％を超えており、テーブルの83.5％のヒット率が59.4％を超えていることを示しています

Pg_statio_ [user | sys | all] _indexes

このビューには、インデックスのブロック読み取り/ヒット情報が含まれています。

Pg_stat_database

このビューには、データベースごとに1つの行が含まれます。これは、データベース全体に集約された前述のビューの情報の一部（読み取りブロック、ヒットブロック、タップに関する情報）、データベース全体に関連する情報（xactionsの合計、一時ファイル、競合、デッドクロック、読み取り/書き込み時間）を示します。、そして最後に現在のバックエンドの数。

ここで探すべきことは、 blks_hit /（blks_hit + blks_read）の比率です。：値が高いほど、システムのI/Oに適しています。ただし、ミスはOSのfilesysキャッシュによって十分に処理されている可能性があるため、必ずしもディスク読み取りの原因となる必要はありません。

上記の他の収集された統計ビューと同様に、 pg_stat_databaseのタイムスタンプ付きバージョンを作成する必要があります。 2つの連続するスナップショットの違いを表示して表示します：

ロールバックの数は増えていますか？
またはコミットされたxactionの数？
昨日よりもはるかに多くの競合が発生していますか（これはスタンバイに適用されます）？
デッドロックの数が異常に多いですか？

これらはすべて非常に重要なデータです。最初の2つは、説明が必要な使用パターンの変更を意味する場合があります。競合の数が多いということは、レプリケーションに何らかの調整が必要であることを意味している可能性があります。デッドロックの数が多いと、多くの理由で問題が発生します。トランザクションがロールバックされるためにパフォーマンスが低下するだけでなく、アプリケーションがシングルマスタートポロジでデッドロックに陥った場合、マルチマスターに移行した場合にのみ問題が増幅されます。この場合、ソフトウェアエンジニアリング部門は、デッドロックの原因となるコードの一部を書き直す必要があります。

ロック

関連リソースClusterControlforPostgreSQL既存のPostgresサーバーを管理および監視する方法PostgreSQLのパフォーマンスをベンチマークする方法

ロックはPostgreSQLの非常に重要なトピックであり、独自のブログに値します。それでも、基本的なロックの監視は、上記の監視の他の側面と同じ方法で実行する必要があります。 pg_locks ビューは、システムの現在のロックに関するリアルタイムの情報を提供します。 log_lock_waits を設定することで、長時間待機しているロックをキャッチできます。、その後、長時間待機に関する情報がPgSQLログに記録されます。上記のデッドロックの場合のように、異常に高いロックが発生して長時間待機することに気付いた場合、ソフトウェアエンジニアは、長時間保持されたロックを引き起こす可能性のあるコードを確認する必要があります。アプリケーションでの明示的なロック（LOCKTABLEまたはSELECT…FORUPDATE）。

デッドロックの場合と同様に、ロックが短いシステムは、マルチマスターセットアップに簡単に移行できます。