針對 Aurora MySQL 資料庫的工作負載問題進行故障診斷 - Amazon Aurora
執行個體主機指標資料庫指標

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

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

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

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

    如需詳細資訊，請參閱 MySQL 文件中的 MySQL 8.0 中的新功能和伺服器和狀態變數，以及 MySQL 8.0 中新增、棄用或移除的選項，以及 比較 Aurora MySQL 第 2 版和 Aurora MySQL 第 3 版。

  • 正在處理的資料是否增加 (列計數)？

  • 是否有更多同時執行的查詢？

  • 是否有結構描述或資料庫變更？

  • 是否有程式碼瑕疵或修正？

內容

執行個體主機指標

監控執行個體主機指標，例如 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​ 的作業系統指標。

記憶體用量

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

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

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

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

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

  • Buffers (KB) – 在寫入至儲存裝置之前，用於緩衝 I/O 請求的記憶體數量，以 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 儲存子系統接收和向其傳入的網路輸送量。

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

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

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

資料庫指標

檢查下列 CloudWatch 指標以確認是否有工作負載變更：

  • BlockedTransactions – 被封鎖的資料庫中的平均每秒交易數量。

  • BufferCacheHitRatio – 由緩衝區快取提供服務的請求的百分比。

  • CommitThroughput – 遞交操作的每秒平均數量。

  • DatabaseConnections – 連線至資料庫執行個體的用戶端網路連線數。

  • Deadlocks – 資料庫中平均每秒的死鎖數量。

  • DMLThroughput – 平均每秒插入、更新及刪除的數量。

  • ResultSetCacheHitRatio – 由查詢快取提供服務的請求的百分比。

  • RollbackSegmentHistoryListLength – 記錄具有刪除標記記錄之已遞交交易的復原日誌。

  • RowLockTime – 針對 InnoDB 資料表取得資料列鎖定所花費的時間總計。

  • SelectThroughput – 平均每秒選取查詢的數量。

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

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

  1. 資料庫執行個體類別最近是否有變更，例如將執行個體大小從 8xlarge 減少為 4xlarge，或從 db.r5 變更為 db.r6？

  2. 您可以建立複製並重現問題，還是僅在該單一執行個體上發生？

  3. 是否有伺服器資源耗盡、高 CPU 或記憶體耗盡？ 如果是，這可能表示需要額外的硬體。

  4. 一個或多個查詢需要更長的時間嗎？

  5. 變更是否由升級造成，尤其是主要版本升級？ 如果是，請比較升級前和升級後指標。

  6. 讀取器資料庫執行個體的數量是否有變更？

  7. 您是否已啟用一般、稽核或二進位記錄？ 如需更多詳細資訊，請參閱 記錄 Aurora MySQL 資料庫。

  8. 您是否啟用、停用或變更二進位記錄 (binlog) 複寫的使用？

  9. 是否有任何長時間執行的交易具有大量資料列鎖定？ 檢查 InnoDB 歷史記錄清單長度 (HLL) 是否有長時間執行交易的指示。

    如需詳細資訊，請參閱 InnoDB 歷史記錄清單長度顯著增加 和部落格文章為什麼我的 SELECT 查詢在 Amazon Aurora MySQL 資料庫叢集上緩慢執行？。

    1. 如果大型 HLL 是由寫入交易造成，表示 UNDO 日誌正在累積 (未定期清理)。在大型寫入交易中，此累積可能會快速成長。在 MySQL 中，UNDO 存放在 SYSTEM 資料表空間中。SYSTEM 資料表空間無法縮減。UNDO 日誌可能會導致 SYSTEM 資料表空間成長到數個 GB 甚至 TB。清除後，透過建立資料的邏輯備份 (傾印) 釋放配置的空間，然後將傾印匯入新的資料庫執行個體。

    2. 如果大型 HLL 是由讀取交易 (長時間執行的查詢) 所造成，可能表示查詢使用大量的暫時空間。重新啟動以釋放暫時空間。檢查 Performance Insights 資料庫指標是否有 Temp 區段中的任何變更，例如 created_tmp_tables。如需更多詳細資訊，請參閱 在 Amazon Aurora 上使用績效詳情監控資料庫負載。

  10. 您可以將長時間執行的交易分割成修改較少資料列的較小交易嗎？

  11. 封鎖的交易是否有任何變更或死結增加？ 用來檢查 Locks 區段中狀態變數的任何變更的 Performance Insights 資料庫指標，例如 innodb_row_lock_time、 innodb_row_lock_waits 和 innodb_dead_locks。使用 1 分鐘或 5 分鐘的間隔。

  12. 是否有增加的等待事件？ 使用 1 分鐘或 5 分鐘的間隔檢查 Performance Insights 等待事件和等待類型。分析最久等待事件，並查看它們是否與工作負載變更或資料庫爭用相關聯。例如，buf_pool mutex 表示緩衝集區爭用。如需更多詳細資訊，請參閱 使用等待事件調校 Aurora MySQL。