針對 Aurora MySQL 資料庫的工作負載問題進行故障診斷

資料庫工作負載可以視為讀取和寫入。了解「正常」資料庫工作負載後，您可以調校查詢和資料庫伺服器，以滿足其變更的需求。效能可以變更的原因有很多種，因此第一個步驟是了解變更的內容。

是否有主要或次要版本升級？

主要版本升級包括引擎程式碼的變更，特別是在最佳化工具中，這些變更可能會變更查詢執行計畫。升級資料庫版本時，特別是主要版本，請務必分析資料庫工作負載並相應地進行調校。調校可能涉及最佳化和重寫查詢，或根據測試結果新增和更新參數設定。了解造成影響的原因，可讓您開始專注於該特定區域。

如需詳細資訊，請參閱 MySQL 文件 My 8.0 中的新功能，以及 My 文件 My 8.0 中SQL新增、棄用或移除的伺服器和狀態變數和選項，以及比較 Aurora MySQL 第 2 版和 Aurora MySQL 第 3 版。SQL
處理中的資料是否增加（列計數）？
是否有更多同時執行的查詢？
是否有結構描述或資料庫變更？
是否有程式碼瑕疵或修正？

內容

執行個體主機指標

監控執行個體主機指標，例如 CPU、記憶體和網路活動，以協助了解工作負載是否已變更。了解工作負載變更有兩個主要概念：

使用率 – 裝置使用率，例如 CPU或磁碟。它可以是以時間為基礎或以容量為基礎。
- 以時間為基礎 – 資源在特定觀察期間忙碌的時間量。
- 以容量為基礎的 – 系統或元件可以交付的輸送量，以容量的百分比表示。
飽和度 – 資源所需的工作量超過其可處理的程度。當容量型用量達到 100% 時，便無法處理額外工作，且必須排入佇列。

CPU 用量

您可以使用下列工具來識別CPU用量和飽和度：

CloudWatch 提供 CPUUtilization 指標。如果達到 100%，則執行個體會飽和。不過， CloudWatch 指標的平均值為 1 分鐘，且缺乏精細程度。

如需 CloudWatch 指標的詳細資訊，請參閱 Amazon Aurora 的執行個體層級指標。
增強型監控提供作業系統top命令傳回的指標。它顯示負載平均值和下列CPU狀態，具有 1 秒的精細程度：
- Idle (%) = 閒置時間
- IRQ (%) = 軟體中斷
- Nice (%) = 具有經調整優先順序的程序的良好時間。
- Steal (%) = 服務其他租戶所花費的時間（虛擬化相關）
- System (%) = 系統時間
- User (%) = 使用者時間
- Wait (%) = I/O 等待
如需增強型監控指標的詳細資訊，請參閱Aurora 的作業系統指標。

記憶體用量

如果系統處於記憶體壓力下，且資源消耗達到飽和，您應該觀察高度的頁面掃描、分頁、交換和 out-of-memory錯誤。

您可以使用下列工具來識別記憶體用量和飽和度：

CloudWatch 提供 FreeableMemory 指標，顯示透過排清一些作業系統快取和目前的可用記憶體，可以回收多少記憶體。

如需 CloudWatch 指標的詳細資訊，請參閱 Amazon Aurora 的執行個體層級指標。

增強型監控提供下列指標，可協助您識別記憶體用量問題：

Buffers (KB) – 在寫入儲存裝置之前，用於緩衝輸入/輸出請求的記憶體量，以 KB 為單位。
Cached (KB) – 用於快取檔案系統型 I/O 的記憶體量。
Free (KB) – 未指派的記憶體數量，以 KB 為單位。
Swap – 快取、免費和總計。

例如，如果您看到資料庫執行個體使用Swap記憶體，則工作負載的記憶體總量會大於執行個體目前可用的記憶體總量。我們建議您增加資料庫執行個體的大小，或調校工作負載以使用較少的記憶體。

如需增強型監控指標的詳細資訊，請參閱Aurora 的作業系統指標。

如需使用效能結構描述和sys結構描述來判斷哪些連線和元件正在使用記憶體的詳細資訊，請參閱故障診斷 Aurora MySQL 資料庫的記憶體用量問題。

網路輸送量

CloudWatch 提供下列總網路輸送量的指標，所有指標均在 1 分鐘內平均：

NetworkReceiveThroughput – Aurora 資料庫叢集中每個執行個體從用戶端接收的網路輸送量。
NetworkTransmitThroughput – Aurora 資料庫叢集中每個執行個體傳送至用戶端的網路輸送量。
NetworkThroughput – Aurora 資料庫叢集中每個執行個體從用戶端接收和傳輸的網路輸送量。
StorageNetworkReceiveThroughput – 資料庫叢集中每個執行個體從 Aurora 儲存子系統接收的網路輸送量。
StorageNetworkTransmitThroughput – Aurora 資料庫叢集中每個執行個體傳送至 Aurora 儲存子系統的網路輸送量。
StorageNetworkThroughput – Aurora 資料庫叢集中每個執行個體從 Aurora 儲存子系統接收並傳送至 Aurora 儲存子系統的網路輸送量。

如需 CloudWatch 指標的詳細資訊，請參閱 Amazon Aurora 的執行個體層級指標。

增強型監控提供network接收 (RX) 和傳輸 (TX) 圖形，最長 1 秒的精細程度。

如需增強型監控指標的詳細資訊，請參閱Aurora 的作業系統指標。

資料庫指標

檢查下列 CloudWatch 工作負載變更指標：

BlockedTransactions – 資料庫中每秒封鎖的平均交易數。
BufferCacheHitRatio – 緩衝區快取提供的請求百分比。
CommitThroughput – 每秒遞交操作的平均數量。
DatabaseConnections – 用戶端網路連線至資料庫執行個體的數目。
Deadlocks – 資料庫中每秒的平均死鎖數。
DMLThroughput – 每秒平均插入、更新和刪除次數。
ResultSetCacheHitRatio – 查詢快取提供的請求百分比。
RollbackSegmentHistoryListLength – 復原日誌，以使用刪除標記的記錄記錄遞交的交易。
RowLockTime – 取得 InnoDB 資料表的資料列鎖定所花費的總時間。
SelectThroughput – 每秒選取查詢的平均數量。

如需 CloudWatch 指標的詳細資訊，請參閱 Amazon Aurora 的執行個體層級指標。

檢查工作負載時，請考慮下列問題：

資料庫執行個體類別最近是否有變更，例如將執行個體大小從 8xlarge 減少為 4xlarge，或從 db.r5 變更為 db.r6？
您可以建立複製並重現問題，還是只在該執行個體上發生？
是否有伺服器資源耗盡、大量CPU或記憶體耗盡？如果是，這可能表示需要額外的硬體。
一或多個查詢需要更長的時間嗎？
變更是否由升級造成，尤其是主要版本升級？如果是，請比較升級前後指標。
讀取器資料庫執行個體的數量是否有變更？
您是否已啟用一般、稽核或二進位記錄？如需詳細資訊，請參閱Aurora MySQL 資料庫的記錄。
您是否啟用、停用或變更二進位日誌 (binlog) 複寫的使用？
是否有任何長時間執行的交易持有大量資料列鎖定？檢查 InnoDB 歷史記錄清單長度 (HLL) 是否有長時間執行交易的指示。

如需詳細資訊，請參閱 InnoDB 歷史記錄清單長度顯著增加和部落格文章為什麼我的SELECT查詢在 Amazon Aurora MySQL 資料庫叢集上執行緩慢？
1. 如果大型HLL是寫入交易所造成，表示UNDO日誌正在累積（未定期清理）。在大型寫入交易中，此累積可能會快速成長。在 My 中SQL， UNDO 會存放在SYSTEM資料表空間中。SYSTEM 資料表空間無法縮減。UNDO 日誌可能會導致SYSTEM資料表空間成長到數個 GB，甚至 TB。清除後，透過取得資料的邏輯備份（傾印）來釋放配置的空間，然後將傾印匯入新的資料庫執行個體。
2. 如果大型HLL是讀取交易（長時間執行的查詢）所造成，可能表示查詢使用大量的暫時空間。重新啟動以釋放暫時空間。檢查 Performance Insights 資料庫指標是否有任何 Temp 區段的變更，例如 created_tmp_tables。如需詳細資訊，請參閱在 Amazon Aurora 上使用績效詳情監控資料庫負載。
您可以將長時間執行的交易分割為修改較少資料列的較小交易嗎？
封鎖的交易是否有任何變更或死鎖增加？檢查 Performance Insights 資料庫指標 Locks區段中狀態變數的任何變更，例如 innodb_row_lock_time、 innodb_row_lock_waits和 innodb_dead_locks。使用 1 分鐘或 5 分鐘的間隔。
是否有增加的等待事件？使用 1 分鐘或 5 分鐘的間隔檢查 Performance Insights 等待事件和等待類型。分析熱門等待事件，並查看它們是否與工作負載變更或資料庫爭用相關。例如， buf_pool mutex 表示緩衝集區爭用。如需詳細資訊，請參閱使用等待事件調校 Aurora MySQL。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

針對 Aurora MySQL 效能進行故障診斷

故障診斷 Aurora MySQL 記憶體用量問題