このドキュメントでは、パフォーマンス スナップショット レポートを手動で生成する方法について説明します。このレポートを使用すると、2 つの時点のシステム指標のスナップショットを比較できます。パフォーマンス スナップショット レポートを使用して、AlloyDB for PostgreSQL データベースのパフォーマンスの問題を特定して軽減できます。各スナップショットでキャプチャされるシステム指標には、仮想 CPU（vCPU）使用量、メモリ使用量、ディスク I/O、トランザクション数、待機イベントなどがあります。
自動スナップショットと手動スナップショット
AlloyDB は、次のスナップショットをサポートしています。
自動スナップショット: デフォルトでは、AlloyDB は 1 日に 1 回スナップショットを自動的にキャプチャし、スナップショットを 7 日間保存します。自動スナップショットは、ワークロードの粒度を日単位でレポートを生成するのに役立ちます。自動スナップショットの保持は変更できませんが、頻度を構成することはできます。
手動スナップショット: スナップショットを手動でキャプチャしてレポートを生成できます。
自動スナップショットと手動スナップショットを組み合わせて、パフォーマンス レポートを生成できます。たとえば、手動で生成したスナップショットと自動スナップショットを比較するパフォーマンス スナップショット レポートを生成できます。
このドキュメントでは、パフォーマンス スナップショット レポートを手動で生成する方法について説明します。
Performance Snapshot Report の仕組み
パフォーマンス スナップショット レポートは、パフォーマンス データをキャプチャして分析し、パフォーマンスの問題の原因を特定しやすくする AlloyDB の組み込みツールです。このツールは、インスタンスに関するリアルタイム指標を提供するシステム分析情報、Query Insights、Metrics Explorer などの AlloyDB オブザーバビリティ機能と連携します。
Performance Snapshot Report では、2 つのタイムスタンプ間のデータベース指標が 1 つのレポートに表示されます。Performance Snapshot Report の情報を使用して、Performance Snapshot Report インスタンスのパフォーマンスの問題（特定の時間帯のデータベース パフォーマンスの低下や特定の期間のパフォーマンスの低下など）を特定できます。
Performance Snapshot Report を使用して指標をパフォーマンス ベースラインと比較することで、ワークロードのパフォーマンス指標に関する分析情報を取得できます。この分析情報は、データベースのパフォーマンスの最適化やトラブルシューティングに使用できます。ベースラインは、特定の構成とワークロードでデータベースの標準的なパフォーマンスと動作を測定する、カスタマイズされた一連のデータベース スナップショットです。
Performance Snapshot Report の待機イベントについては、データベースの Performance Snapshot Report のリファレンスをご覧ください。
必要なロール
alloydbsuperuser ロールがあることを確認します。デフォルトでは、AlloyDB は alloydbsuperuser に pg_monitor ロールを付与します。詳細については、PostgreSQL の事前定義ロールをご覧ください。
他の自己定義ロールを使用する場合は、まず alloydbsuperuser として GRANT pg_monitor TO my_user を実行します。詳細については、適切なロールを使用して Identity and Access Management（IAM）アカウントを更新するをご覧ください。
スナップショットの作成
パフォーマンス スナップショットは、データベースのパフォーマンスを把握して最適化するための強力なツールです。特定の時点での主要なシステム指標をキャプチャし、2 つの時点間でデータベースのパフォーマンスを比較できます。AlloyDB は、次の 2 種類のスナップショットをサポートしています。
- システム指標のスナップショット: これらのスナップショットは、vCPU 使用率、メモリ使用量、ディスク I/O などの主要なシステム指標をキャプチャします。
- システム指標と SQL 実行統計のスナップショット: これらのスナップショットには、標準スナップショットのすべてのシステム指標と、
pg_stat_statements拡張機能の詳細な SQL 実行統計が含まれています。
これにより、分析に必要な詳細レベルを柔軟に選択できます。
システム指標のスナップショットを作成する
対象のワークロードの開始時と終了時にスナップショットを作成します。2 つのスナップショット間の時間間隔は、ワークロードの代表的なサンプルをキャプチャするのに十分な長さにする必要があります。
AlloyDB データベースのパフォーマンスを最適化する手順は次のとおりです。
- ベースライン スナップショットは、データベースがアイドル状態の場合や、データベースに平均的な負荷が発生している場合に作成します。
psqlクライアントを AlloyDB インスタンスに接続します。SELECT perfsnap.snap()を実行します。出力は次のようになります。postgres=# select perfsnap.snap(); snap ------ 1 (1 row)このコマンドの出力は、スナップショット ID（
snap_id）を返します。この例では1です。この ID は、後でパフォーマンス スナップショット レポートを生成するために必要になります。実際の環境のsnap_idは異なる可能性があります。作成したレポートを両方のスナップショット セットと比較し、パフォーマンスを向上させる可能性のある変化を特定します。パフォーマンスに関する推奨事項の詳細については、データベース パフォーマンスの最適化に関する推奨事項をご覧ください。
生成された Performance Snapshot Report から指標を取得したら、別の一連のスナップショットを取得してプロセスを繰り返すことができます。
SQL 実行の統計情報を含むスナップショットを作成する
デフォルトでは、AlloyDB は pg_stat_statements 拡張機能を使用して SQL ステートメントを追跡します。パフォーマンス レポートに詳細な SQL 実行統計を含めるには、まず postgres データベースに pg_stat_statements 拡張機能を作成する必要があります。これらの統計情報のキャプチャは、拡張機能の作成自体ではなく、pg_stat_statements.track フラグによって有効になります。
SQL 実行統計情報も含むスナップショットを作成する手順は次のとおりです。
-
postgresデータベースにpg_stat_statements拡張機能を作成します。postgres=# CREATE EXTENSION pg_stat_statements;
- これで、スナップショットを作成すると、
pg_stat_statementsの SQL 統計情報が自動的に含まれるようになります。postgres=# select perfsnap.snap(); snap ------ 2 (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)
Performance Snapshot Report を生成する
2 つのスナップショット（スナップショット 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
SQL Report
~~~~~~~~~~
NOTE: Query might be empty if query ID does not have a match in pg_stat_statements at report time. This is expected if the query is not run recently.
Per Query Information (Top 50) By Total Elapsed Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query Text UserID DBID DBName QueryID Total Elapsed Time(ms) Execution Count Avg Elapsed Time(ms)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6) 36272 36274 tpcc -5467151541922966497 276400877.8014 36928106 7.4848
prepare payment (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, NUMERIC, VARCHAR) AS select p 36272 36274 tpcc 3864683359055073968 127719636.4656 36928456 3.4586
prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2) 36272 36274 tpcc 2323704420019807054 48540963.0880 3694128 13.1400
prepare slev (INTEGER, INTEGER, INTEGER) AS select slev($1,$2,$3) 36272 36274 tpcc -8637448842172635004 35361366.9271 3692785 9.5758
...
Per Query Information (Top 50) By Read IO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query Text UserID DBID DBName QueryID Total ReadIO Time(ms) Execution Count Avg ReadIO Time(ms) Total buffer hits Avg buffer hits Total blk reads Avg blk reads
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
prepare ostat (INTEGER, INTEGER, INTEGER, INTEGER, VARCHAR) AS select * from ostat($1,$2,$3,$4,$5) a 36272 36274 tpcc -1640504351418263816 498072.4004 3693895 0.1348 80360201 21.75486877672484 105858 0.028657555236410347
prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2) 36272 36274 tpcc 2323704420019807054 12.5438 3694128 0.0000 4477308168 1212.0067761593534 1219908 0.33022894712906536
prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6) 36272 36274 tpcc -5467151541922966497 0.8039 36928106 0.0000 10337394097 279.9329620912592 6245570 0.16912781825312134
SELECT name, default_version, installed_version FROM pg_catalog.pg_available_extensions 10 5 postgres 6619165036968781114 0.0000 361 0.0000 361 1 0 0
...
Per Query Information (Top 50) By Standard Deviation of Elapsed Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query Text UserID DBID DBName QueryID Begin STDDEV Elapsed Time(ms) End STDDEV Elapsed Time(ms)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SELECT COUNT($1) FROM perfsnap.g$snapshots 10 5 postgres -8741741796612173369 17.8084 18.1239
prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2) 36272 36274 tpcc 2323704420019807054 15.0626 19.8495
prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6) 36272 36274 tpcc -5467151541922966497 13.9820 17.0074
prepare slev (INTEGER, INTEGER, INTEGER) AS select slev($1,$2,$3) 36272 36274 tpcc -8637448842172635004 8.4333 9.6205
----------------------------------------------------
Created by G_STATS v1.0.100
----------------------------------------------------
(xxx rows)
レポート フィールドとパフォーマンス最適化の推奨事項については、データベース パフォーマンス最適化に関する推奨事項をご覧ください。Performance Snapshot Report の待機イベントの詳細については、データベースの Performance Snapshot Report のリファレンスをご覧ください。
スナップショットの削除
既存のベースラインに含まれるスナップショットを削除する前に、ベースラインを消去する必要があります。
スナップショットを削除するには、次のコマンドを実行します。
SELECT perfsnap.delete(SNAP_ID);
SNAP_ID は、削除するスナップショットの ID に置き換えます。
削除したスナップショットは復元できません。
スナップショットをパフォーマンス ベースラインとしてマークする
たとえば ID が 1～3 のすべてのスナップショットをシステム パフォーマンスのベースラインとしてマークするには、SELECT perfsnap.make_baseline(1, 3) を実行します。
パフォーマンス ベースラインを消去する
たとえば ID が 1～3 のすべてのベースラインを消去するには、SELECT perfsnap.clear_baseline(1, 3) を実行します。
自動スナップショットの頻度を変更する
自動スナップショットの頻度をカスタマイズするには、perfsnap.interval フラグを設定します。このフラグは、自動スナップショットの間隔を秒単位で設定します。詳細については、データベース フラグを構成するをご覧ください。
意味のある情報を取得するには、フラグの値を数分以上に設定することをおすすめします。
リソースの無駄遣いを避けるため、カスタマイズした頻度が不要になったら、フラグをデフォルト値（1 日あたりの秒数）にリセットします。
スナップショット レポートの結果を使用してデータベースのパフォーマンスを最適化する
AlloyDB データベースのパフォーマンスを最適化する手順は次のとおりです。
- ベースライン スナップショットは、データベースがアイドル状態の場合や、データベースに平均的な負荷が発生している場合に作成します。
- パフォーマンスを改善するワークロードまたはクエリを開始します。
- ワークロードまたはクエリがリソース使用量のピークに達したら、別のスナップショット セットを作成します。両方のレポートに同じ期間を使用することをおすすめします。
- 作成したレポートを両方のスナップショット セットと比較し、パフォーマンスを向上させる可能性のある変化を特定します。パフォーマンスに関する推奨事項の詳細については、データベース パフォーマンスの最適化に関する推奨事項をご覧ください。
データベース パフォーマンスの最適化に関する推奨事項
次の表に、Performance Snapshot Report のセクションと、各レポート セクションで推奨される改善策を示します。Performance Snapshot Report のセクションと待機イベントの詳細については、データベースの Performance Snapshot Report のリファレンスをご覧ください。
| セクション | レポートの項目 | レポートの項目の説明 | おすすめの最適化案 |
|---|---|---|---|
| スナップショットの詳細 | スナップショットの詳細 | ホスト、PostgreSQL 互換のリリース バージョン、マシンが稼働している時刻を指定します。 | なし |
| スナップショット ID | このレポートの作成に使用されたスナップショットの ID と特定の時点が一覧表示されます。 | なし | |
| システム分析情報 | ホスト CPU | ホストの CPU 使用率の詳細。 | CPU 使用率が 80% を超える場合は、使用可能な次のサイズにスケールアップすることをおすすめします。 |
| ホストメモリ | ホストメモリ使用率の詳細。 | 空きメモリが 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 データベース フラグ）を確認し、値が想定されていないか、推奨されていないかを判断します。 |
| SQL 実行統計情報 | クエリごとの情報（上位 50 件） - 合計経過時間別 | 2 つのスナップショット間で経過時間が最も長かった上位 50 件のクエリと、その合計実行回数を、クエリが発行されたユーザーとデータベース別に表示します。Elapsed time = Difference of total_exec_time in pg_stat_statements at the two snapshot time |
このセクションでは、システム時間の大部分を占める最も負荷の高いクエリを特定します。 |
| クエリごとの情報（上位 50 件）（読み取り IO 別） | 2 つのスナップショット間で読み取り IO 時間が最も長かった上位 50 件のクエリと、その実行数、バッファヒット数、ブロック読み取り数を合計と平均の両方で一覧表示します。ReadIO = blk_read_time + temp_blk_read_time 2 つのスナップショット間で累積Buffer Hits = shared_blks_hit + local_blks_hit 2 つのスナップショット間で累積Buffer Reads = shared_blks_read + local_blks_read 2 つのスナップショット間で累積これらのフィールドは、 track_io_timing が設定されているため、AlloyDB Cloud によってデフォルトで追跡されます。 |
このセクションでは、特にディスクからの読み取り頻度が高い I/O 集中型クエリを特定します。 | |
| クエリごとの情報（上位 50 件）経過時間の標準偏差別 | 経過時間の標準偏差が最も大きい上位 50 件のクエリを一覧表示します。開始スナップショット時間と終了スナップショット時間の両方で計算された標準偏差を一覧表示します。 ここで、値は pg_stat_statements の stddev_exec_time を参照します。 |
標準偏差が大きいクエリは、クエリの実行時間が大きく変動していることを意味します。この場合は、I/O を確認する必要があります。 |
制限事項
ストレージの過剰な消費によるスペースの肥大化を防ぐため、1 つのインスタンスで手動的に作成できるスナップショットは最大 2, 500 個です。
スナップショットの数がスナップショットの上限を超えると、AlloyDB は 90 日より古い手動スナップショットをすべて削除します。スナップショットの上限内に収めるには、新しいスナップショットを取得する前に不要なスナップショットをクリーンアップする必要があります。
AlloyDB は、90 日より古い手動スナップショットを定期的にクリーンアップします。
次のステップ
- Performance Snapshot Report の待機イベントについて学習する。