本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
資料庫效能調校的關鍵概念
DevOpsGuru for RDS 假設您熟悉幾個關鍵效能概念。若要進一步了解這些概念，請參閱《Amazon Aurora 使用者指南》中的績效詳情概觀或》Amazon RDS 使用者指南》中的績效詳情概觀。
指標
指標代表按時間順序排列的資料集點。您可以將指標視為要監控的變數，且資料點代表該變數隨著時間的值。Amazon RDS 即時為資料庫和資料庫執行個體執行所在的作業系統 (OS) 提供指標。您可以在 Amazon RDS 主控台上檢視 Amazon RDS 資料庫執行個體的所有系統指標和程序資訊。適用於 RDS 的 DevOpsGuru 會監控並提供其中一些指標的洞見。如需詳細資訊，請參閱監控 Amazon Aurora 叢集中的指標或監控 Amazon Relational Database Service 執行個體中的指標。
問題偵測
DevOpsGuru for RDS 採用資料庫和作業系統 (OS) 指標來偵測關鍵資料庫效能問題，無論這些問題是即將發生還是持續發生。DevOps DevOpsGuru for RDS 問題偵測有 2 種主要運作方式：
使用閾值
使用異常
偵測閾值的問題
閾值是評估監控指標的邊界值。您可以在指標圖表上將閾值視為水平線，將正常行為與潛在的有問題行為分開。DevOpsGuru for RDS 會監控特定指標，並透過分析特定資源可能被視為有問題的層級來建立閾值。然後，當新的指標值在指定期間內以一致的方式超過指定的閾值時，DevOps for RDS 會在 DevOpsGuru 主控台中建立洞見。洞見包含防止未來資料庫效能影響的建議。
例如，DevOps for RDS 可能會在 15 分鐘內監控使用磁碟的暫存資料表數量，並在使用每秒磁碟的暫存資料表速率異常高時建立洞見。增加磁碟上暫存資料表用量的層級可能會影響資料庫效能。DevOps DevOpsGuru for RDS 透過在情況變得重要之前公開此狀況，協助您採取修正動作以防止問題發生。
偵測異常問題
雖然閾值提供簡單且有效的方法來偵測資料庫問題，但在某些情況下，它們還不夠。考慮一個因為已知的程序，例如每日報告任務，而指標值會經常激盪並交叉到潛在有問題行為的情況。由於預期會有此類峰值，因此為每個峰值建立洞見和通知會產生反效果，並可能導致警示疲勞。
不過，仍然需要偵測高度不尋常的峰值，因為比其餘指標高出許多或持續更久可能代表實際的資料庫效能問題。為了解決這個問題，RDS 的 DevOpsGuru 會監控特定指標，以偵測指標的行為何時變得非常異常或異常。DevOpsGuru 接著會在洞見中報告這些異常。
例如，當資料庫負載不僅很高，而且也顯著偏離其一般行為時，DevOps for RDS 可能會建立洞見，這表示資料庫操作發生重大的意外減慢。DevOps DevOpsGuru for RDS 透過僅識別異常資料庫負載峰值，可讓您專注於真正重要的問題。
資料庫負載
資料庫調校的關鍵概念是資料庫負載 （資料庫負載） 指標。資料庫負載代表資料庫在任何指定時間的忙碌程度。資料庫負載增加表示資料庫活動增加。
資料庫工作階段代表應用程式與關聯式資料庫的對話。作用中工作階段是正在進行資料庫請求的工作階段。工作階段處於作用中是指工作階段正在 CPU 上執行，或等待資源變成可用以繼續執行。例如，作用中的工作階段可能等待分頁讀入記憶體中，然後從分頁讀取資料時耗用 CPU。
Performance Insights 中的指標是以平均作用中工作階段 DBLoad (AAS) 來測量。 為了計算 AAS，Performance Insights 每秒會取樣作用中工作階段的數量。在特定期間內，ASS 是作用中工作階段的總數除以範例的總數。AAS 值 2 表示，在任何指定時間，平均有 2 個工作階段在請求中處於作用中狀態。
倉庫中的活動可比喻為資料庫負載。假設倉庫僱用 100 名工人。如果有 1 份訂單進來，則 1 名工人履行訂單，其他工人閒置。如果出現 100 個或更多訂單，則所有 100 個工作者都會同時履行訂單。如果您定期抽樣特定時段內有多少作用中的工人，則可以算出平均的作用中工人數目。計算結果指出平均隨時都有 N 名工人忙於履行訂單。如果昨天平均 50 名工人，今天平均 75 名工人，則表示倉庫中的活動程度上升。同樣地，資料庫負載會隨著工作階段活動增加而提高。
若要進一步了解，請參閱《Amazon Aurora 使用者指南》中的資料庫載入或》Amazon RDS 使用者指南》中的資料庫載入。
等待事件
等待事件是一種資料庫檢測，可告訴您資料庫工作階段正在等待哪個資源，以便繼續。當 Performance Insights 計算作用中工作階段以計算資料庫負載時，也會記錄導致作用中工作階段等待的等待事件。此技術可讓 Performance Insights 顯示哪些等待事件導致資料庫載入。
每個使用中的工作階段都在 CPU 上執行或等待中。例如，工作階段在搜尋記憶體、執行計算或執行程序程式碼時會使用 CPU。當工作階段未使用 CPU 時，他們可能會等待資料檔案讀取或日誌寫入。工作階段等待資源越久，在 CPU 上執行的時間就越短。
當您調整資料庫時，通常會嘗試尋找工作階段正在等待的資源。例如，兩個或三個等待事件可能佔資料庫負載的 90%。此量值表示作用中工作階段平均花最多時間等待少量資源。如果您可以找出這些等待的原因，您可以嘗試解決問題。
以倉庫工人的比喻為例。進來的訂單是買一本書。工人可能延遲履行訂單。例如，不同的工作者可能目前正在重新存放架子，或無法使用手拉車。或者，用來輸入訂單狀態的系統可能很慢。工作者等待的時間越長，訂單完成的時間就越長。等待是倉儲工作流程的自然部分，但如果等待時間過長，生產力就會降低。同樣地，重複或冗長的工作階段等待會降低資料庫效能。
如需 Amazon Aurora 中等待事件的詳細資訊，請參閱《Amazon Aurora 使用者指南》中的使用 Aurora PostgreSQL 的等待事件進行調校和使用 Aurora MySQL 的等待事件進行調校。
如需其他 Amazon RDS 資料庫中等待事件的詳細資訊，請參閱《Amazon RDS 使用者指南》中的使用 RDS for PostgreSQL 的等待事件進行調校。
