本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
synch/sxlock/innodb/hash_table_locks
當緩衝集區中找不到的頁面必須從儲存體讀取時,就會發生synch/sxlock/innodb/hash_table_locks
事件。
支援的引擎版本
下列版本支援這個等待事件資訊:
-
Aurora MySQL 第 2 版和第 3 版
Context
事件 synch/sxlock/innodb/hash_table_locks
指出工作負載經常存取未存放在緩衝集區中的資料。此等待事件與新的頁面新增相關,而且舊資料會從緩衝集區移出。存放在緩衝集區的資料過時,而且新資料必須進行快取,因此會將過時頁面移出,以允許快取新頁面。我的SQL 使用最近使用的 (LRU) 演算法,從緩衝集區中移出頁面。工作負載嘗試存取尚未載入至緩衝集區的資料或已從緩衝集區移出的資料。
當工作負載必須存取磁碟上檔案中的資料,或當區塊從緩衝集區清單釋放或新增至緩衝集區LRU清單時,就會發生此等待事件。這些作業等待取得共用的排除鎖定 (SX-lock)。此 SX-lock 用於透過「雜湊表」進行同步,此雜湊表是記憶體中的資料表,旨在改善緩衝集區存取效能。
如需詳細資訊,請參閱 MySQL 文件中的緩衝集區
等待時間增加的可能原因
synch/sxlock/innodb/hash_table_locks
等待事件比平時更常出現時,可能表示有效能問題,典型原因包括:
- 緩衝集區大小過小
-
緩衝集區的大小太小,無法將所有經常存取的頁面保留在記憶體中。
- 工作負載繁重
-
工作負載導致頻繁的移出,並在緩衝區快取中重新載入資料頁面。
- 讀取頁面時發生錯誤
-
讀取緩衝集區中的頁面時發生錯誤,這可能表示資料損毀。
動作
根據等待事件的原因,我們會建議不同的動作。
增加緩衝集區的大小
確定緩衝集區已適當地調整為適合工作負載的大小。若要這樣做,您可以檢查緩衝區快取命中率。通常,如果值低於 95%,請考慮增加緩衝集區大小。越大的緩衝集區可以將經常存取的頁面保留在記憶體中的時間越長 若要增加緩衝集區的大小,請修改 innodb_buffer_pool_size
參數的值。此參數的預設值是基於資料庫執行個體類別大小。如需詳細資訊,請參閱 Amazon Aurora MySQL 資料庫組態的最佳實務
改善資料存取模式
檢查受此等待及其執行計劃影響的查詢。考慮改善資料存取模式。例如,如果您是使用 mysqli_result::fetch_array
您可以使用績效詳情來顯示可能造成 synch/sxlock/innodb/hash_table_locks
等待事件的查詢和工作階段。
尋找負責高負載的SQL查詢
登入 AWS Management Console 並在 開啟 Amazon RDS主控台https://console.aws.amazon.com/rds/
。 -
在導覽窗格中,選擇 Performance Insights (績效詳情)。
-
選擇資料庫執行個體。即會顯示該資料庫執行個體的績效詳情儀表板。
-
在 Database load (資料庫負載) 圖表中,選擇 Slice by wait (依等待建立配量)。
-
在頁面底部,選擇頂端 SQL。
圖表列出負責載入的SQL查詢。位於清單頂端者負最大責任。若要解決瓶頸,請專注於這些陳述式。
如需使用 Performance Insights 進行故障診斷的實用概觀,請參閱 AWS 資料庫部落格文章 使用 Performance Insights 分析 Amazon Aurora MySQL Workloads
減少或避免完整資料表掃描
監控工作負載,以查看它是否正在執行完整資料表掃描,若是,請減少或避免它們。例如,您可以監控狀態變數,例如 Handler_read_rnd_next
。如需詳細資訊,請參閱 MySQL 文件中的伺服器狀態變數
檢查錯誤日誌是否有頁面毀損
你可以檢查 mysql-error.log,是否在接近問題發生時偵測到毀損相關訊息。您可以用來解決問題的訊息位於錯誤日誌中。您可能需要重新建立已報告為毀損的物件。