synch/mutex/innodb/buf_pool_mutex - Amazon Aurora
相關的引擎版本Context等待變多的可能原因動作

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

synch/mutex/innodb/buf_pool_mutex

當執行緒已對 InnoDB 緩衝集區取得鎖定來存取記憶體中的頁面時，synch/mutex/innodb/buf_pool_mutex 事件便會發生。

相關的引擎版本

下列引擎版本支援這個等待事件資訊：

  • Aurora MySQL 第 2 版

Context

buf_pool 互斥是單一互斥，其會保護緩衝集區的控制資料結構。

如需詳細資訊，請參閱 MySQL 文件中的使用效能結構描述監控 InnoDB 互斥等待。

等待變多的可能原因

這是工作負載特定的等待事件。synch/mutex/innodb/buf_pool_mutex 出現在最高等待事件之間的常見原因包括：

  • 緩衝集區不夠大，無法容納工作資料集。

  • 工作負載更特定於來自資料庫中特定資料表的特定頁面，從而導致緩衝集區中的爭用。

動作

根據等待事件的原因，我們會建議不同的動作。

識別造成事件的工作階段和查詢

通常，具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的，則等待事件可能是可以接受的。如果效能不是最佳的，則檢查資料庫在何處花費最多時間。查看造成最高負載的等待事件，並了解您是否可以最佳化資料庫和應用程式，以減少這些事件。

在 AWS 管理主控台中檢視最高 SQL 圖表

  1. 前往 https://console.aws.amazon.com/rds/，開啟 Amazon RDS 主控台。

  2. 在導覽窗格中，選擇 Performance Insights (績效詳情)。

  3. 選擇資料庫執行個體。即會顯示該資料庫執行個體的績效詳情儀表板。

  4. 在 Database load (資料庫負載) 圖表中，選擇 Slice by wait (依等待建立配量)。

  5. 在 Database load (資料庫負載) 圖表下方，選擇 Top SQL (最高 SQL)。

    此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。

如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章利用績效詳情分析 Amazon Aurora MySQL 工作負載。

使用績效詳情

此事件與工作負載相關。您可以使用績效詳情執行下列動作：

  • 從應用程式日誌或相關來源識別等待事件開始的時間，以及工作負載在該段時間是否有任何變更。

  • 識別負責此等待事件的 SQL 陳述式。檢查查詢的執行計劃，以確定這些查詢已最佳化，並使用適當的索引。

    如果負責等待事件的最高查詢與相同的資料庫物件或資料表相關，請考慮分割該物件或資料表。

建立 Aurora 複本

您可以建立 Aurora 複本來提供唯讀流量。您也可以使用 Aurora Auto Scaling 來處理讀取流量的突增。務必在 Aurora 複本上執行排定的唯讀任務和邏輯備份。

如需更多詳細資訊，請參閱 使用 Amazon Aurora Auto Scaling 搭配 Aurora 複本。

檢查緩衝集區大小

查看指標 innodb_buffer_pool_wait_free，檢查緩衝集區大小是否足以處理工作負載。如果此指標的值很高且持續增加，這表示緩衝集區的大小不足以處理工作負載。如果 innodb_buffer_pool_size 已正確設定，則 innodb_buffer_pool_wait_free 的值應該很小。如需詳細資訊，請參閱 MySQL 文件中的 Innodb_buffer_pool_wait_free。

如果資料庫執行個體具有足夠的記憶體，可供工作階段緩衝區和作業系統任務使用，請增加緩衝區集區大小。如果沒有，請將資料庫執行個體變更為較大的資料庫執行個體類別，以取得可配置給緩衝集區的額外記憶體。

注意

Aurora MySQL 會根據設定的 innodb_buffer_pool_size 自動調整 innodb_buffer_pool_instances 的值。

監控全域狀態歷史記錄

透過監控狀態變數的變更率，您可以在資料庫執行個體上偵測鎖定或記憶體問題。開啟全域狀態歷史記錄 (GoSH)，如果尚未開啟的話。如需 GoSh 的詳細資訊，請參閱管理全域狀態歷史記錄。

您也可以建立自訂 Amazon CloudWatch 指標來監控狀態變數。如需詳細資訊，請參閱發佈自訂指標。