Performance Snapshot Report 的運作方式
效能快照報表是 AlloyDB Omni 內建的工具，可擷取及分析效能資料，協助您找出效能問題的原因。
Performance Snapshot Report 會在單一報表中，顯示兩個時間戳記之間的資料庫指標。您可以使用 Performance Snapshot Report 資訊，找出 Performance Snapshot Report 執行個體的效能問題，例如資料庫效能在一天中的特定時段或特定時間範圍內降低。
您可以使用 Performance Snapshot Report，將指標與成效基準進行比較，深入瞭解工作負載成效指標，並據此最佳化或排解資料庫效能問題。基準是一組自訂的資料庫快照，用於評估資料庫在特定設定和工作負載下的標準效能和行為。
根據預設，AlloyDB Omni 的效能快照會儲存在記憶體中，如果執行個體重新啟動，就會捨棄這些快照。
必要的角色
確認您具備 pg_monitor 角色。這項角色會授予超級使用者，然後超級使用者可以將 pg_monitor 授予其他使用者。
舉例來說，postgres 預設為超級使用者。您可以以 postgres 身分執行 GRANT pg_monitor TO my_user，允許 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;
建立系統指標快照
在感興趣的工作負載開始和結束時建立快照。兩個快照之間的時間間隔應足以讓工作負載進展，以便系統累積反映工作負載的指標。從產生的 Performance Snapshot Report 取得指標後，您可以擷取另一組快照並重複上述程序。
- 將
psql用戶端連線至 AlloyDB 執行個體。 執行
SELECT perfsnap.snap()。 輸出看起來類似以下內容：postgres=# select perfsnap.snap(); snap ------ 1 (1 row)
建立含有 SQL 執行統計資料的快照
根據預設，AlloyDB Omni 會使用 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)。
差異作業中的第二個快照不一定要緊接在第一個快照之後。不過，請務必在第一個快照後，擷取差異的第二個快照。
生成的成效快照報表大致如下列簡略範例：
Performance Snapshot Report 範例
psql -d postgres -U alloydbsuperuser
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
----------------------------------------------------
(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 的各個部分，以及各部分的建議改善措施。如要進一步瞭解效能快照報表區段和等待事件，請參閱「資料庫效能快照報表參考資料」。
| 區段 | 報表欄位 | 報表欄位說明 | 最佳化建議 |
|---|---|---|---|
| 快照詳細資料 | 快照詳細資料 | 提供主機、PostgreSQL 相容發布版本，以及機器啟動並執行的時間。 | 不適用 |
| 快照 ID | 列出用於建立這份報表的快照 ID 和時間點。 | 不適用 | |
| 系統深入分析資訊 | 主機 CPU | 主機 CPU 使用率詳細資料。 | 如果 CPU 使用率超過 80%，建議您改用具有更多虛擬 CPU 的系統。 |
| 主機記憶體 | 主機記憶體使用率詳細資料。 | 如果可用記憶體低於 15%，建議您擴充至下一個可用大小。 | |
| 載入設定檔 | 列出計數器，協助您根據產生的預寫記錄檔 (WAL)、I/O 需求和連線管理，描述工作負載的特性。 | 如果實體讀取次數高於邏輯讀取次數，請考慮擴充至下一個可用大小，以支援更大的資料快取。 | |
| 回應時間和等待類別細目 | Postgres 程序在工作負載執行期間花費的時間細目。 | 舉例來說，如果程序大多處於等待狀態，請著重縮短 I/O 等待時間。 | |
| 資料庫工作負載資訊 | 每個資料庫的工作負載資訊 | 每個資料庫的重要指標，包括修訂、復原、命中率，以及臨時資料表和排序作業的相關資訊。 | 如果回溯次數偏高，請考慮診斷應用程式。 |
| 各資料庫的 DML 和 DQL 資訊 | 查詢作業的計數器。 | 將工作負載歸類為讀取密集型或寫入密集型。 | |
| 資料庫衝突資訊 | 常見應用程式和資料庫問題的計數器。 | 找出應用程式中的死結問題。 | |
| 資料庫 大小資訊 |
顯示資料庫在兩個快照之間的間隔期間成長了多少。這個欄位也會顯示資料庫是否已設定連線限制。 | 如果資料庫成長幅度過大，請找出應用程式中的問題。 | |
| 吸塵器資訊 | 吸塵器資訊 | 清理作業的 I/O 和計數器詳細資料。 | AlloyDB 預設會執行自動調節式清除作業。您可以覆寫部分清理設定，以符合工作負載。舉例來說，如果這些要求耗費過多 I/O，請減少真空作業。 |
| 各資料庫的 Vacuum 資訊 | 顯示下列資訊：
|
如果 Frozen XID 欄位的時間過久，或已耗用交易的百分比接近 90%，請考慮執行清理作業。如果匯總 vacuum 間隔縮小，表示 Postgres 將強制執行 vacuum，防止 wraparound。 | |
| 資料庫程序等待詳細資料 | 詳細的後端和 背景程序資訊 |
報表間隔內，後端和背景程序的所有等待詳細資料。資訊包括累計等待時間、CPU 作業時間，以及每種等待類型的平均時間。 | 舉例來說，如要減少 WALWrite 的等待時間，請增加資料庫可用的 wal_buffers 數量。 |
| 後端和背景等待事件詳細資料直方圖 | 根據預設，這項資訊會包含在效能數據匯報報表中。這份清單包含後端和背景程序的等待事件直方圖，分為 32 個值區，從 1 微秒到超過 16 秒。 | 找出等待事件，並判斷較大的等待時間值區中是否有過多等待事件。等待事件過多或每次等待耗費的時間過長，都可能造成問題。 | |
| 其他統計資料 | 預寫記錄 (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 項查詢資訊 | 列出兩個快照期間耗費最多讀取 I/O 時間的前 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 Omni 會刪除所有超過 90 天的手動快照。為避免超過快照數量上限，請先清除不必要的快照，再建立新的快照。
AlloyDB Omni 會定期清除超過 90 天的手動快照。
後續步驟
- 瞭解效能快照報表中的等待事件。