本文說明如何手動產生效能快照報表，以便比較兩個時間點的系統指標快照。您可以運用效能快照報表，找出並解決 AlloyDB for PostgreSQL 資料庫的效能問題。每個快照擷取的系統指標包括虛擬 CPU (vCPU) 使用率、記憶體用量、磁碟 I/O、交易計數和等待事件。
自動和手動快照
AlloyDB 支援下列快照：
自動快照：根據預設，AlloyDB 每天會自動擷取一次快照，並將快照儲存 7 天。系統會自動建立快照，方便您產生以每日工作負載為精細度的報表。您無法變更自動快照的保留期限，但可以設定頻率。
手動快照：您可以手動擷取快照並產生報表。
您可以混用自動和手動快照，產生成效報表。舉例來說，您可以產生成效快照報表，比較手動產生的快照與自動快照。
本文說明如何手動產生成效快照報表。
成效快照報表的運作方式
成效快照報表是 AlloyDB 內建工具，可擷取及分析效能資料，協助您找出效能問題的原因。這項工具可輔助其他 AlloyDB 可觀測性功能，例如系統洞察、查詢洞察和指標探索器，提供執行個體的即時指標。
成效快照報表會在單一報表中，顯示兩個時間戳記之間的資料庫指標。您可以運用成效快照報表資訊，找出成效快照報表執行個體的成效問題，例如在一天中的特定時段資料庫效能下降，或在特定時間範圍內效能下降。
您可以透過成效快照報表，將指標與成效基準進行比較，深入瞭解工作負載成效指標，進而最佳化或排解資料庫效能問題。基準是一組自訂的資料庫快照，用於評估特定設定和工作負載的資料庫標準效能和行為。
如要瞭解效能快照報告中的等待事件，請參閱「資料庫效能快照報告參考資料」。
必要的角色
確認您具備alloydbsuperuser角色。
根據預設，AlloyDB 會將 pg_monitor 角色授予 alloydbsuperuser。詳情請參閱 PostgreSQL 預先定義的角色。
如要使用其他自訂角色，請先以 alloydbsuperuser 執行 GRANT pg_monitor TO my_user。詳情請參閱「更新 Identity and Access Management (IAM) 帳戶，並指派適當角色」。
建立快照
成效快照是瞭解及提升資料庫效能的強大工具。這類快照會擷取特定時間點的主要系統指標，方便您比較資料庫在兩個時間點的效能。AlloyDB 支援兩種快照：
- 系統指標快照：這些快照會擷取重要的系統指標，例如 vCPU 用量、記憶體用量和磁碟 I/O。
- 系統指標和 SQL 執行統計資料的快照：這些快照包含標準快照中的所有系統指標，以及
pg_stat_statements擴充功能的詳細 SQL 執行統計資料。
您可以彈性選擇分析所需的詳細程度。
建立系統指標快照
在您感興趣的工作負載開始和結束時建立快照。 兩次快照之間的時間間隔應夠長，才能擷取工作負載的代表性樣本。
請按照下列步驟，盡可能提升 AlloyDB 資料庫效能：
- 在資料庫閒置或平均負載時，建立基準快照。
- 將
psql用戶端連線至 AlloyDB 執行個體。 執行
SELECT perfsnap.snap()。 輸出看起來類似以下內容：postgres=# select perfsnap.snap(); snap ------ 1 (1 row)這項指令的輸出內容會傳回快照 ID (
snap_id)，在本例中為1。您稍後需要這個 ID 才能產生成效快照報表。您環境中的snap_id可能不同。比較您使用兩組快照建立的報表，找出可提升成效的變更。如要進一步瞭解效能最佳化建議，請參閱「資料庫效能最佳化建議」。
從產生的成效快照報表取得指標後，您可以再拍攝一組快照，然後重複這個程序。
建立包含 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)
產生成效數據匯報報表
如要產生報表，擷取兩個快照 (例如快照 1 和 2) 之間的差異，請執行：SELECT perfsnap.report(1,2)
差異化作業中的第二個快照不一定要緊接在第一個快照之後。不過，請務必在第一個快照之後，擷取差異中的第二個快照。
報告範例
以下是生成的成效摘要報表範例 (已省略部分內容)：
範例成效快照報表
$ 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)
如要瞭解報表欄位和效能最佳化建議，請參閱「資料庫效能最佳化建議」。如要進一步瞭解效能快照報表中的等待事件，請參閱「資料庫效能快照報表參考資料」。
刪除快照
如要刪除現有基準中的快照，請先清除基準。
如要刪除快照，請執行下列指令：
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 標記，以秒為單位設定自動快照間隔。詳情請參閱「設定資料庫旗標」。
建議您將旗標值設為至少幾分鐘，以便擷取有意義的資訊。
為避免浪費資源，不再需要自訂頻率時，請將旗標重設為預設值 (即每天每秒)。
根據快照報表結果，盡量提高資料庫效能
請按照下列步驟，盡可能提升 AlloyDB 資料庫效能：
- 請在資料庫閒置或平均負載時建立基準快照。
- 啟動要提升效能的工作負載或查詢。
- 當工作負載或查詢達到資源使用量高峰時，請建立另一組快照。建議您為這兩份報表設定相同的間隔。
- 比較您使用兩組快照建立的報表，找出可提升成效的變更。如要進一步瞭解效能最佳化建議，請參閱「資料庫效能最佳化建議」。
資料庫效能最佳化建議
下表列出成效快照報表各部分，以及每個報表部分建議的改善措施。如要進一步瞭解效能快照報表區段和等待事件，請參閱「資料庫效能快照報表參考資料」。
| 區段 | 報表欄位 | 報表欄位說明 | 最佳化建議 |
|---|---|---|---|
| 快照詳細資料 | 快照詳細資料 | 提供主機、與 PostgreSQL 相容的版本，以及機器啟動並執行的時間。 | 不適用 |
| 快照 ID | 列出用於建立這份報表的快照 ID 和時間點。 | 不適用 | |
| 系統深入分析資訊 | 主機 CPU | 主機 CPU 使用率詳細資料。 | 如果 CPU 使用率超過 80%，建議您擴充至下一個可用大小。 |
| 主機記憶體 | 主機記憶體使用率詳細資料。 | 如果可用記憶體低於 15%，建議您擴充至下一個可用大小。 | |
| 載入設定檔 | 列出有助於評估工作負載的計數器，包括產生的預先寫入記錄 (WAL)、I/O 需求和連線管理。 | 如果實體讀取次數高於邏輯讀取次數，請考慮擴充至下一個可用大小，以支援更大的資料快取。 | |
| 回應時間和等待類別細目 | Postgres 處理工作負載執行作業所花費的時間明細。 | 如果程序大多處於等待狀態，請著重於縮短 I/O 等待時間。 | |
| 資料庫工作負載資訊 | 每個資料庫的工作負載資訊 | 每個資料庫的重要指標，包括提交、回溯、命中率，以及暫時性資料表和排序作業的相關資訊。 | 如果回溯次數偏高，請考慮診斷應用程式。 |
| 每個資料庫的 DML 和 DQL 資訊 | 查詢作業的計數器。 | 將工作負載歸類為讀取密集型或寫入密集型。 | |
| 資料庫衝突資訊 | 常見應用程式和資料庫問題的計數器。 | 如果發生死結，請找出應用程式中的問題。 | |
| 資料庫規模資訊 | 顯示資料庫在兩個快照間隔期間的成長量。這個欄位也會顯示資料庫是否已建立連線限制。 | 如果資料庫成長幅度過大，請找出應用程式中的問題。 | |
| 吸塵器資訊 | 吸塵器資訊 | 真空作業的 I/O 和計數器詳細資料。 | 根據預設，AlloyDB 會執行適應性清除作業。您可以覆寫部分真空設定，以配合工作負載。舉例來說，如果這些要求耗費過多 I/O，請減少清除作業。 |
| 每個資料庫的清除資訊 | 顯示下列資訊：
|
如果凍結 XID 欄位的年齡過舊，或已使用的交易百分比接近 90%，請考慮執行清除作業。如果匯總真空間隙減少，表示 Postgres 會強制執行真空，以防止迴繞。 | |
| 資料庫程序等待詳細資料 | 詳細的後端和背景程序資訊 | 報告間隔內，後端和背景程序的所有等待詳細資料。資訊包括累計等待時間、CPU 時間，以及每種等待類型的平均時間。 | 舉例來說，如要減少 WALWrite 的等待時間，請增加資料庫可用的 wal_buffers 數量。 |
| 詳細後端和背景等待事件直方圖 | 根據預設，這項指標會納入成效數據匯報報表。這份清單包含後端和背景程序的等待事件直方圖，並分成 32 個值區，從 1 微秒到超過 16 秒。 | 找出等待事件，並判斷較大的等待時間 bucket 中是否有過多等待事件。等待事件過多或每次等待耗用的時間過長，都可能導致問題。 | |
| 其他統計資料 | 預寫記錄 (WAL) 統計資料 | WAL 統計資料摘要。 | 如果同步時間過長，請調整相關資料庫標記 (GUC)，改善工作負載。GUC 是 PostgreSQL 子系統，負責處理伺服器設定。 |
| 摘要統計資料 (所有資料庫) | 快照間隔期間發生的所有資料庫作業摘要。 | 不適用 | |
| 參數設定 | 參數設定 | 快照時間結束時的 Postgres 主要設定參數。 | 檢查 GUC 參數設定 (Postgres 資料庫旗標)，判斷值是否不符合預期或不建議使用。 |
| SQL 執行統計資料 | 依總經過時間排序的查詢資訊 (前 50 項) | 列出在兩個快照之間耗時最長的前 50 項查詢，以及這些查詢的總執行次數，並依發出查詢的使用者和資料庫細分。Elapsed time = Difference of total_exec_time in pg_stat_statements at the two snapshot time |
請使用這個部分找出最耗費系統時間的查詢。 |
| 依讀取 IO 排序的前 50 項查詢資訊 | 列出在兩個快照期間，讀取 IO 時間最長的 50 個查詢，以及這些查詢的執行次數、緩衝區命中次數、讀取區塊次數，包括總計和平均值。ReadIO = blk_read_time + temp_blk_read_time在兩個快照期間累積Buffer Hits = shared_blks_hit + local_blks_hit在兩個快照期間累積Buffer Reads = shared_blks_read + local_blks_read在兩個快照期間累積由於已設定 track_io_timing，AlloyDB Cloud 預設會追蹤這些欄位。 |
您可以使用這個部分找出 I/O 密集型查詢，特別是需要經常從磁碟讀取資料的查詢。 | |
| 依經過時間的標準差排序，顯示每個查詢的資訊 (前 50 項) | 列出前 50 個經過時間標準差最高的查詢，並列出在開始和結束快照時間計算出的標準差。 這裡的值參照 pg_stat_statements 中的 stddev_exec_time |
如果查詢的標準差很高，表示查詢執行時間差異很大，可能需要檢查 I/O。 |
限制
為避免儲存空間用量過高而導致空間膨脹，您可以在一個執行個體上手動建立最多 2, 500 張快照。
如果快照數量超過上限，AlloyDB 會刪除所有超過 90 天的手動快照。如要維持在快照限制內，您必須先清除不必要的快照，才能建立新快照。
AlloyDB 會定期清除超過 90 天的手動快照。