Performance Snapshot Report の仕組み
Performance Snapshot Report は、パフォーマンス データをキャプチャして分析し、パフォーマンスの問題の原因を特定しやすくする AlloyDB Omni の組み込みツールです。
Performance Snapshot Report では、2 つのタイムスタンプ間のデータベース指標が 1 つのレポートに表示されます。Performance Snapshot Report の情報を使用して、Performance Snapshot Report インスタンスのパフォーマンスの問題（特定の時間帯のデータベース パフォーマンスの低下や特定の期間のパフォーマンスの低下など）を特定できます。
Performance Snapshot Report を使用して指標をパフォーマンス ベースラインと比較することで、ワークロードのパフォーマンス指標に関する分析情報を取得できます。この分析情報は、データベースのパフォーマンスの最適化やトラブルシューティングに使用できます。ベースラインは、特定の構成とワークロードでデータベースの標準的なパフォーマンスと動作を測定する、カスタマイズされた一連のデータベース スナップショットです。
Performance Snapshot Report の待機イベントについては、データベースの Performance Snapshot Report のリファレンスをご覧ください。
必要なロール
pg_monitor ロールがあることを確認します。このロールはスーパーユーザーに付与され、スーパーユーザーは他のユーザーに pg_monitor を付与できます。
たとえば、postgres はデフォルトでスーパーユーザーです。GRANT pg_monitor TO my_user を postgres として実行すると、my_user がこのドキュメントで説明するパフォーマンス スナップショット ツールを使用できるようになります。
Performance Snapshot Report をインストールする
perfsnap は、ユーザーがスナップショットのキャプチャやレポートの生成を行える SQL 関数を含むスキーマ名です。このスキーマは、AlloyDB Omni の g_stats 拡張機能の一部です。Performance Snapshot Report をインストールするには、スーパーユーザーのロールを使用します。
perfsnap API を使用するには、ユーザーが拡張機能をインストールする任意のデータベースに接続し、次のコマンドを使用して g_stats 拡張機能を作成します。
CREATE EXTENSION IF NOT EXISTS g_stats;
システム指標のスナップショットを作成する
対象のワークロードの開始時と終了時にスナップショットを作成します。2 つのスナップショット間の時間間隔は、ワークロードが進行するのに十分な時間であるため、システムはワークロードを反映する指標を蓄積できます。生成された Performance Snapshot Report から指標を取得したら、別の一連のスナップショットを取得してプロセスを繰り返すことができます。
psqlクライアントを AlloyDB インスタンスに接続します。SELECT perfsnap.snap()を実行します。出力は次のようになります。postgres=# select perfsnap.snap(); snap ------ 1 (1 row)
スナップショットのリストを表示する
psqlクライアントを AlloyDB インスタンスに接続します。SELECT * FROM perfsnap.g$snapshotsを実行します。出力は次のようになります。postgres=# select * from perfsnap.g$snapshots; snap_id | snap_time | instance_id | node_id | snap_description | snap_type | is_baseline ---------+-------------------------------+-------------+---------+--------------------+-----------+------------- 1 | 2023-11-13 22:13:43.159237+00 | sr-primary | | Manual snapshot | Manual | f 2 | 2023-11-13 22:53:40.49565+00 | sr-primary | | Automatic snapshot | Automatic | f (2 rows)
スナップショット レポートを生成する
スナップショット 1 と 2 の差異をキャプチャするレポートを生成するには、たとえば SELECT perfsnap.report(1,2) を実行します。
差分オペレーションの 2 番目のスナップショットは、最初のスナップショットの直後に続く必要はありません。ただし、差分内の 2 番目のスナップショットは、最初のスナップショットの後にキャプチャしてください。
生成された Performance Snapshot Report は、次の例（簡略版）のようになります。
Performance Snapshot Report の例
$ psql -d postgres -U alloydbsuperuser
postgres=> select perfsnap.report(22, 23);
report
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PGSNAP DB Report for:
Snapshot details
--------------------------------------
Host i841-sr-primary-2a34f46e-06bc
Release 14.12
Startup Time 2024-10-08 03:23:15+00
Snap Id Snap Time
------------ ---------- ------------------------
Begin Snap: 22 24.10.2024 04:33:56 (UTC) Automatic snapshot
End Snap: 23 25.10.2024 04:38:56 (UTC) Automatic snapshot
Elapsed: 1 day 00:04:59.979321
Database Cache sizes
~~~~~~~~~~~~~
Shared Buffers: 31 GB Block Size: 8192
Effective Cache Size: 25 GB WAL Buffers: 16384
Host CPU
~~~~~~~~~~
%User %Nice %System %Idle %WIO %IRQ %SIRQ %Steal %Guest
------- ------- ------- ------- ------- ------- ------- ------- -------
1.07 0.22 0.91 97.40 0.09 0.00 0.31 0.00 0.00
Host Memory
~~~~~~~~~~~~
Total Memory: 63 GB
Available Memory: 11 GB
Free Memory: 726 MB
Buffers Memory: 3706 MB
Load profile (in bytes)
~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
------------ ---------------
Redo size: 63083.64 4489.93
Logical reads: 1961.21 139.59
...
Response Time Profile (in s)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CPU time: 5399 ( 0.39%)
Wait time: 1386906 ( 99.61%)
Total time: 1392306
Backend Processes Wait Class Breakdown (in s)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IO 119.300 ( 98.91%)
LWLock 1.305 ( 1.08%)
IPC .010 ( 0.01%)
Lock .000 ( 0.00%)
Backend Processes Wait Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Class Waits Time (us) Avg (us)
-------------------------------------- ------------- ------------- -------------- -------------
CPU 1995948632
WALInsert LWLock 1 6656 6656
Vacuum Information
~~~~~~~~~~~~~~~~~~~
Num Analyze operations: 1976
Num Vacuum operations: 3435
Per Database Information
~~~~~~~~~~~~~~~~~~~~~~~~~
Name Commits Rollbacks BlkRds Blkhits TempFiles TempBytes
------------------------- ------------- ------------- ------------- ------------- ------------- -------------
bench 27939 0 0 7823038 0 0 bytes
postgres 39792 0 7 11089243 0 0 bytes
Per Database DML & DQL Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Tuples returned Tuples fetched Tuples inserted Tuples updated Tuples deleted Index splits Index Only heap fetches HOT updates
------------------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ------------------------- ----------------
bench 16119481 4843262 0 0 0 0 16 0
postgres 25415473 6327188 0 10 0 0 0 8
Per Database Conflict Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Lock Timeout Old Snapshot Buffer Pins Deadlock
------------------------- ------------- ------------- ------------- -------------
bench 0 0 0 0
postgres 0 0 0 0
Per Database Vacuum Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Frozen XID % Consumed Aggregate Vacuum Gap
------------------------- ------------- ------------- --------------------
bench 179460916 9.00% 20539084
postgres 179339239 9.00% 20660761
Per Database Sizing Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Conn.
Name Collation Limit Tablespace DB Size Growth
-------------------- ------------- ------- -------------------- ---------- ----------
bench C.UTF-8 -1 pg_default 80 GB 0 bytes
postgres C.UTF-8 -1 pg_default 135 MB 0 bytes
Backend Wait Event Histogram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Class Waits <= 1us <= 2us <= 4us <= 8us <= 16us <= 32us <= 64us <= 128us <= 256us <= 512us
-------------------------------------- ------------- ----------- --------- --------- --------- --------- --------- --------- --------- --------- --------- --------
WALInsert LWLock 1 0 0 0 0 0 0 0 0 0 0
Background Wait Event Histogram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Class Waits <= 1us <= 2us <= 4us <= 8us <= 16us <= 32us <= 64us <= 128us <= 256us <= 512us
-------------------------------------- ------------- ----------- --------- --------- --------- --------- --------- --------- --------- --------- --------- --------
WALInsert LWLock 542 107 174 39 113 93 8 1 1 0 1
Write Ahead Log (WAL) Statistics
--------------------------------
Records Full Page Images Bytes Buffers Full Write Sync Write Time Sync Time
----------- ---------------- ----------- ------------ ----------- ----------- ----------- -----------
2936305 100 805989345 0 0 0 0 0
Summary Stats (across all databases)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Value
-------------------------------- ----------------------------------
Buffers evicted 0
Commits 1216693
...
Parameter Settings
~~~~~~~~~~~~~~~~~~~
Parameter Value
--------------------------------- --------------------------------------------------------------
DateStyle ISO, MDY
TimeZone UTC
autovacuum on
work_mem 4096
Columnar Engine available size Columnar Engine configured size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
14959MB 19293MB
Columnar Engine Statistics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
name count
---------------------------------------------------------- ------------
CU Populations/Refreshes 13197
CU Auto Refreshes 10975
...
Columnar Engine Ultra-fast Cache Statistics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ultra-fast Cache Size (MB): 19200
Ultra-fast Cache Used Size (MB): 0
Ultra-fast Cache Block Size (MB): 80
----------------------------------------------------
Created by G_STATS v1.0.100
----------------------------------------------------
(xxx rows)
レポート フィールドとパフォーマンス最適化の推奨事項については、データベース パフォーマンス最適化に関する推奨事項をご覧ください。Performance Snapshot Report の待機イベントの詳細については、データベースの Performance Snapshot Report のリファレンスをご覧ください。
スナップショットを削除する
既存のベースラインに含まれるスナップショットを削除する前に、ベースラインを消去する必要があります。
スナップショットを削除するには、SELECT perfsnap.delete(n) を実行します。削除したスナップショットは復元できません。
スナップショットをパフォーマンス ベースラインとしてマークする
たとえば ID が 1～3 のすべてのスナップショットをシステム パフォーマンスのベースラインとしてマークするには、SELECT perfsnap.make_baseline(1, 3) を実行します。
パフォーマンス ベースラインを消去する
たとえば ID が 1～3 のすべてのベースラインを消去するには、SELECT perfsnap.clear_baseline(1, 3) を実行します。
スナップショット レポートの結果を使用してデータベースのパフォーマンスを最適化する
AlloyDB データベースのパフォーマンスを最適化する手順は次のとおりです。
- ベースライン スナップショットは、データベースがアイドル状態の場合や、データベースに平均的な負荷が発生している場合に作成します。
- パフォーマンスを改善するワークロードまたはクエリを開始します。
- ワークロードまたはクエリがリソース使用量のピークに達したら、別のスナップショット セットを作成します。両方のレポートに同じ期間を使用することをおすすめします。
- 作成したレポートを両方のスナップショット セットと比較し、パフォーマンスを向上させる可能性のある変化を特定します。パフォーマンスに関する推奨事項の詳細については、データベース パフォーマンスの最適化に関する推奨事項をご覧ください。
データベース パフォーマンスの最適化に関する推奨事項
次の表に、Performance Snapshot Report のセクションと、各レポート セクションで推奨される改善策を示します。Performance Snapshot Report のセクションと待機イベントの詳細については、データベースの Performance Snapshot Report のリファレンスをご覧ください。
| セクション | レポートの項目 | レポートの項目の説明 | おすすめの最適化案 |
|---|---|---|---|
| スナップショットの詳細 | スナップショットの詳細 | ホスト、PostgreSQL 対応のリリース バージョン、マシンが稼働している時刻を指定します。 | 該当なし |
| スナップショット ID | このレポートの作成に使用されたスナップショットの ID と特定の時点が一覧表示されます。 | 該当なし | |
| システム分析情報 | ホスト CPU | ホストの CPU 使用率の詳細。 | CPU 使用率が 80% を超える場合は、vCPU 数のより多いシステムに移行することをおすすめします。 |
| ホストメモリ | ホストメモリ使用率の詳細。 | 空きメモリが 15% 未満の場合は、使用可能な次のサイズにスケールアップすることをおすすめします。 | |
| 負荷プロファイル | 生成された write-ahead log 書き込み（WAL）、I/O 要件、接続管理の観点からワークロードの特性の把握に役立つカウンタを一覧表示します。 | 物理読み取りが論理読み取りよりも大きい場合は、使用可能な次のサイズにスケールアップして、より大きなデータ キャッシュをサポートすることを検討してください。 | |
| 応答時間と待ち時間クラスの内訳 | ワークロードの実行中に Postgres プロセスが費やした時間の内訳。 | たとえば、プロセスのほとんどが待機状態にある場合は、I/O 待機時間の短縮に重点を置いて調整します。 | |
| データベース ワークロード情報 | データベースごとのワークロード情報 | 各データベースの主要な指標（commit、ロールバック、ヒット率、一時テーブルと並べ替えオペレーションに関する情報など）。 | ロールバックが多い場合は、アプリの診断を検討してください。 |
| データベースごとの DML と DQL の情報 | クエリ オペレーションのカウンタ。 | ワークロードを読み取り負荷が高いか書き込み負荷が高いかに分類します。 | |
| データベースの競合情報 | アプリケーションとデータベースに関する一般的な問題のカウンタ。 | デッドロックがある場合は、アプリケーションの問題を特定します。 | |
| データベース サイズ情報 |
2 つのスナップショット間の期間にデータベースがどれだけ拡大したかを示します。このフィールドには、データベースに接続上限が設定されているかどうかも示されます。 | データベースの拡大が大きすぎる場合は、アプリケーションの問題を特定します。 | |
| バキュームに関する情報 | バキュームに関する情報 | バキューム オペレーションの I/O とカウンタの詳細。 | デフォルトでは、AlloyDB は適応型バキュームを実行します。一部のバキューム設定は、ワークロードに合わせてオーバーライドできます。たとえば、これらのリクエストに過剰な I/O が費やされている場合は、バキューム オペレーションを減らします。 |
| データベースごとのバキューム情報 | 次の情報が表示されます。
|
凍結された XID フィールドの経過時間が古すぎる場合や、消費されたトランザクションの割合が 90% に近い場合は、バキュームを検討してください。集計バキューム ギャップが減少すると、ラップアラウンドを防ぐために Postgres によってバキュームが適用されることを示します。 | |
| データベース プロセスの待機の詳細 | バックエンドと バックグラウンド プロセスの詳細情報 |
レポート期間内のバックエンド プロセスとバックグラウンド プロセスによるすべての待機の詳細。情報には、累積待機時間、CPU 時間、待機タイプごとの平均時間が含まれます。 | WALWrite の待ち時間を短縮するには、データベースで使用可能な wal_buffers の数を増やします。 |
| バックエンドとバックグラウンドの待機イベントの詳細なヒストグラム | これは、デフォルトで Performance Snapshot Report に含まれています。このリストには、バックエンド プロセスとバックグラウンド プロセスの待機イベントのヒストグラムが含まれます。このヒストグラムは、1 マイクロ秒から 16 秒を超える 32 個のバケットに分割されています。 | 待機イベントを特定して、より大きな待ち時間バケットであまりに多くの待機イベントが存在していないかを判断します。待機イベントが多すぎるか、消費された各待機時間に問題がある可能性があります。 | |
| その他の統計情報 | write-ahead log（WAL）の統計情報 | WAL の統計情報の概要。 | 同期時間が長すぎる場合は、関連するデータベース フラグ（GUC）を調整してワークロードを改善します。GUC は、サーバー構成を処理する PostgreSQL サブシステムです。 |
| 集約統計情報（全データベース分） | スナップショット期間中に発生したすべてのデータベース オペレーションの概要。 | 該当なし | |
| パラメータの設定 | パラメータの設定 | 終了スナップショット時の主な Postgres 構成パラメータ。 | GUC パラメータ設定（Postgres データベース フラグ）を確認し、値が想定されていないか、推奨されていないかを判断します。 |
制限事項
スペースの肥大化を防ぐため、1 つのインスタンスで手動的に作成できるスナップショットは最大 2,500 個です。スペースの肥大化により、スナップショットがデータベースの保存容量を過度に占有しないようになっています。
スナップショットの数がスナップショットの上限を超えると、AlloyDB Omni は 90 日より古い手動スナップショットをすべて削除します。スナップショットの上限内に収めるには、新しいスナップショットを取得する前に不要なスナップショットをクリーンアップする必要があります。
AlloyDB Omni は、90 日より古い手動スナップショットを定期的にクリーンアップします。
次のステップ
- Performance Snapshot Report の待機イベントについて学習する。