本文說明如何使用比較兩個不同時間點系統指標快照的報表，找出並解決 AlloyDB Omni 資料庫的效能問題。每個快照擷取的系統指標包括虛擬 CPU (vCPU) 用量、記憶體用量、磁碟 I/O、交易計數和等待事件。
成效快照報表的運作方式
效能快照報表是 AlloyDB Omni 內建工具，可擷取及分析效能資料，協助您找出效能問題的原因。成效快照報表會在一份報表中，顯示兩個時間戳記之間的資料庫指標。您可以運用成效快照報表資訊，找出成效快照報表執行個體的成效問題，例如在一天中的特定時段資料庫效能下降，或在特定時間範圍內效能下降。
使用成效快照報表，將指標與成效基準進行比較，深入瞭解工作負載成效指標，進而最佳化或排解資料庫效能問題。基準是一組自訂的資料庫快照，用於評估特定設定和工作負載的資料庫標準效能和行為。
如要瞭解效能快照報告中的等待事件，請參閱「資料庫效能快照報告參考資料」。
必要的角色
確認您具備pg_monitor角色。
這個角色會授予超級使用者，他們可以將 pg_monitor 授予其他使用者。
舉例來說，postgres 是預設的超級使用者。您可以執行 GRANT pg_monitor TO my_user 做為 postgres，允許 my_user 使用效能快照工具。
安裝成效快照報表
perfsnap 是結構定義名稱，內含 SQL 函式，可供使用者擷取快照或產生報表。這個結構定義是 AlloyDB Omni g_stats 擴充功能的一部分。使用超級使用者角色安裝成效快照報表。
如要使用 perfsnap API，請連線至使用者要安裝擴充功能的任何資料庫，然後使用下列指令建立 g_stats 擴充功能：
CREATE EXTENSION IF NOT EXISTS g_stats;
建立系統指標快照
在您感興趣的工作負載開始和結束時建立快照。 兩個快照之間的時間間隔要夠長，工作負載才能進展，系統才能累積反映工作負載的指標。從產生的成效快照報表取得指標後，您可以再拍攝一組快照，然後重複這個程序。
- 將
psql用戶端連線至 AlloyDB 執行個體。 執行
SELECT perfsnap.snap()。 輸出看起來類似以下內容：postgres=# select perfsnap.snap(); snap ------ 1 (1 row)
查看快照清單
- 將
psql用戶端連線至 AlloyDB Omni 執行個體。 執行
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
----------------------------------------------------
Created by G_STATS v1.0.100
----------------------------------------------------
(xxx rows)
如要瞭解報表欄位和效能最佳化建議，請參閱「資料庫效能最佳化建議」。如要進一步瞭解效能快照報告中的等待事件，請參閱「資料庫效能快照報告參考資料」。
刪除快照
如要刪除現有基準中的快照，請先清除基準。
如要刪除快照，請執行 SELECT perfsnap.delete(n)。快照刪除後就無法復原。
將快照標示為成效基準
舉例來說，如要將 ID 介於 1 和 3 之間的所有快照標示為系統效能基準，請執行 SELECT perfsnap.make_baseline(1, 3)。
清除成效基準
舉例來說，如要清除 ID 介於 1 到 3 之間的所有基準線，請執行 SELECT perfsnap.clear_baseline(1, 3)。
根據快照報表結果，盡量提升資料庫效能
請按照下列步驟，盡可能提升 AlloyDB 資料庫效能：
- 請在資料庫閒置或平均負載時建立基準快照。
- 啟動要提升效能的工作負載或查詢。
- 當工作負載或查詢達到資源使用量高峰時，請建立另一組快照。建議您為這兩份報表設定相同的間隔。
- 比較您使用兩組快照建立的報表，找出可能提升成效的變更。如要進一步瞭解效能最佳化建議，請參閱「資料庫效能最佳化建議」。
資料庫效能最佳化建議
下表列出成效快照報表各部分，以及每個報表部分的建議改善措施。如要進一步瞭解效能快照報表區段和等待事件，請參閱「資料庫效能快照報表參考資料」。
| Section | 報表欄位 | 報表欄位說明 | 最佳化建議 |
|---|---|---|---|
| 快照詳細資料 | 快照詳細資料 | 提供主機、與 PostgreSQL 相容的版本，以及機器啟動並運作的時間。 | 不適用 |
| 快照 ID | 列出用於建立這份報表的快照 ID 和時間點。 | 不適用 | |
| 系統深入分析資訊 | 主機 CPU | 主機 CPU 使用率詳細資料。 | 如果 CPU 使用率超過 80%，建議您改用虛擬 CPU 數量較多的系統。 |
| 主機記憶體 | 主機記憶體使用率詳細資料。 | 如果可用記憶體低於 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 資料庫旗標)，判斷值是否不符合預期或不建議使用。 |
限制
為避免空間膨脹，您可以在一個執行個體上手動建立最多 2500 張快照。空間膨脹可確保快照不會佔用資料庫中過多的儲存空間。
如果快照數量超過上限，AlloyDB Omni 會刪除所有超過 90 天的手動快照。如要維持在快照限制內，您必須先清除不必要的快照，才能建立新快照。
AlloyDB Omni 會定期清除超過 90 天的手動快照。