資料庫負載 - Amazon Relational Database Service
作用中的工作階段平均作用中工作階段平均作用中執行數維度

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

資料庫負載

資料庫負載 (DB 載入) 會測量資料庫中工作階段活動的層級。 DBLoad是「Performance Insights 見」中的關鍵指標，而 Performance Insights 每秒都會收集資料庫負載。

作用中的工作階段

資料庫工作階段代表應用程式與關聯式資料庫的對話。作用中工作階段是已提交工作給資料庫引擎且正在等待回應的連線。

工作階段處於作用中是指工作階段正在 CPU 上執行，或等待資源變成可用以繼續執行。例如，作用中工作階段可能等待分頁 (或區塊) 讀入記憶體中，然後從分頁讀取資料時耗用 CPU。

平均作用中工作階段

平均作用中工作階段 (AAS) 是 DBLoad 績效詳情的單位。它會測量資料庫上同時處於作用中狀態的工作階段數目。

每一秒，績效詳情都會取樣同時執行查詢的工作階段數目。針對每個作用中的工作階段，績效詳情會收集下列資料：

  • SQL 陳述式

  • 工作階段狀態 (正在 CPU 上執行或等待中)

  • 主機

  • 執行 SQL 的使用者

績效詳情會計算 AAS，方法是將工作階段總數除以特定時段的樣本數。例如，下表顯示執行查詢的 5 個連續範例，間隔至少為 1 秒。

樣本 執行查詢的工作階段數目 AAS 算式
1 2 2 工作階段總數 2 / 1 個樣本
2 0 1 工作階段總數 2 / 2 個樣本
3 4 2 工作階段總數 6 / 3 個樣本
4 0 1.5 工作階段總數 6 / 4 個樣本
5 4 2 工作階段總數 10 / 5 個樣本

在上述範例中，時間間隔的資料庫負載為 2 AAS。此測量表示在採集 5 個樣本的間隔期間內，於任何特定時間平均有 2 個工作階段處於作用中。

平均作用中執行數

每秒平均作用中執行數 (AAE) 與 AAS 相關。若要計算 AAE，績效詳情會將查詢的總執行時間除以時間間隔。下表顯示上表中同一個查詢的 AAE 計算。

經過時間 (秒) 總執行時間 (秒) AAE 算式
60 120 2 120 執行秒 / 60 秒經過
120 120 1 120 執行秒 / 120 秒經過
180 380 2.11 380 執行秒/180 秒經過
240 380 1.58 380 執行秒/240 秒經過
300 600 2 600 執行秒 / 300 秒經過

在大多數情況下，查詢的 AAS 和 AAE 大致相同。不過，由於計算的輸入是不同的資料來源，所以計算通常會略有不同。

維度

db.load 指標與其他時間序列指標不同，因為您可以將它分為名為維度的子元件。您可以將維度視為 DBLoad 指標不同特性的「配量依據」類別。

診斷效能問題時，下列維度通常最實用：

如需 Amazon RDS 引擎的維度完整清單，請參閱 資料庫負載依維度配量。

等待事件

等待事件會導致 SQL 陳述式等待特定事件發生後，才能繼續執行。等待事件指出工作在何處受阻，是資料庫負載的重要維度或類別。

每個使用中的工作階段都在 CPU 上執行或等待中。例如，工作階段在記憶體中搜尋緩衝區、執行計算或執行程序程式碼時會耗用 CPU。當工作階段不耗用 CPU 時，可能是在等待記憶體緩衝區變成可用、要讀取的資料檔或要寫入的記錄檔。工作階段等待資源越久，在 CPU 上執行的時間就越短。

調校資料庫時，您通常會嘗試查明工作階段正在等待的資源。例如，兩個或三個等待事件可能佔資料庫負載的 90%。此量值表示作用中工作階段平均花最多時間等待少量資源。如果您可以找出這些等待的原因，就可以嘗試解決方案。

等待事件依據資料庫引擎而有所差異：

注意

對於 Oracle，背景程序有時不需要相關的 SQL 陳述式即可發揮作用。在這些情況下，「績效詳情」會報告背景程序的類型，後面加上冒號，還有與該背景程序相關聯的等待類別。背景程序的類型包括 LGWR、ARC0、PMON 等。

例如，封存工具正在執行輸入/輸出時，績效詳情報告與 ARC1:System I/O 相當類似。有時候也會遺失背景程序類型，所以績效詳情只會報告等待類別，例如 :System I/O。

最高 SQL

等待事件會顯示瓶頸，而最高 SQL 則顯示哪些查詢對資料庫負載造成最大影響。例如，許多查詢目前可能正在資料庫上執行，但單一查詢可能會耗用 99% 的資料庫負載。在此情況下，高負載可能表示查詢發生問題。

根據預設，績效詳情主控台會顯示造成資料庫負載的常用 SQL 查詢。主控台也會顯示每個陳述式的相關統計資料。若要診斷特定陳述式的效能問題，您可以檢查其執行計劃。

計畫

執行計畫簡稱為計畫，是存取資料的一連串步驟。例如，聯結資料表 t1 和 t2 的計畫，可能會循環 t1 中的所有資料列，並將每一列與 t2 中的某列做比較。在關聯式資料庫中，內建程式碼最佳化工具可為 SQL 查詢最決定最有效的計畫。

對於資料庫執行個體，Performance Insights 會自動收集執行計劃 若要診斷 SQL 效能問題，請檢查擷取的計劃是否有高資源 SQL 查詢。這些計劃顯示了數據庫如何解析和運行查詢。

若要瞭解如何使用計劃分析資料庫負載，請參閱：

計畫擷取

Performance Insights 每五分鐘就會識別最耗用資源的查詢，並擷取其計劃。因此您不需要手動收集和管理大量的計畫。而是可以使用 Top SQL (最高 SQL) 索引標籤，將重點放在問題最大的查詢的計畫上。

注意

若查詢的文字超過可收集的查詢文字上限，績效詳情就不會擷取其計畫。如需詳細資訊，請參閱 在績效詳情儀表板中存取更多 SQL 文字。

執行計畫的保留期間與所有 Performance Insights 資料的保留期間相同。免費方案中的保留設定為 Default (7 days) (預設值 (7 天))。若要更長時間保留績效資料，請指定 1 - 24 個月。如需保留期間的詳細資訊，請參閱 Performance Insights 的定價和資料保留。

摘要查詢

Top SQL (最高 SQL) 索引標籤預設顯示摘要查詢。摘要查詢本身沒有計畫，但使用文字值的所有查詢都具有計畫。例如，摘要查詢可能包含文字 WHERE `email`=?。摘要可能包含兩個查詢，其中一個具有文字 WHERE email=user1@example.com，另一個含有 WHERE email=user2@example.com。這些文字查詢全都可能包含多個計畫。

當您選取摘要查詢時，主控台會顯示所選摘要之子陳述式的所有計劃。因此，您不需要查看所有的子陳述式來尋找計畫。您可能會看到前 10 個子陳述式清單中沒有顯示的計畫。主控台顯示已收集計畫的所有子查之計畫，無論這些查詢是否排入前 10 名。