如何疑難排解並解決 Amazon RDS for MySQL 或 Aurora MySQL 相容資料庫執行個體的 CPU 高使用率的問題？

簡短說明

CPU 使用率增加可能由多種因素引起，例如使用者啟動的繁重工作負載、多個並行查詢或長時間執行的交易。

若要識別資料庫執行個體中 CPU 使用率的來源，請檢查下列資源：

• 增強型監控
• 效能洞察
• 用於偵測工作負載中 CPU 使用率的產生原因的查詢
• 具有已啟用監控的日誌

找出來源之後，分析並最佳化您的工作負載以減少 CPU 使用量。

解決方法

使用增強型監控

增強的監控提供作業系統 (OS) 層級檢視，以識別 CPU 負載高原因。例如，您可以檢閱負載平均值、作業系統處理程序清單和 CPU 分佈 (System (%) 或 Nice (%))。

使用增強型監控，以使用 1、5 和 15 分鐘的間隔檢查 loadAverageMinute 資料。平均負載大於 vCPU 數量，即表示執行個體負載過重。如果負載平均值小於資料庫執行個體類別的 vCPU 數量，則 CPU 限流可能不會導致應用程式延遲。在診斷 CPU 用量的原因時，檢查負載平均值以避免誤判。

例如，您有一個資料庫執行個體，其執行個體類別為 db.m5.2xlarge，具有 3000 個達到 CPU 限制的佈建 IOPS。執行個體類別具有八個與其關聯的 vCPU。負載平均值超過 170 表示機器在測量的時間範圍內處於重負載：

負載平均分鐘數

十五	170.25
五	391.31
一	596.74

CPU 使用率

使用者 (%)	0.71
系統 (%)	4.9
Nice (%)	93.92
總計 (%)	99.97

**注意：**Amazon RDS 為您的工作負載提供比在資料庫執行個體上執行的其他任務更高的優先順序。為了排定這些任務的優先順序，工作負載任務具有較高的 Nice 值。因此，在增強型監控中，Nice (%) 代表您的工作負載對資料庫使用的 CPU 數量。

開啟增強型監控後，請檢查與資料庫執行個體相關聯的作業系統處理程序清單。增強型監控最多顯示 100 個處理程序。這可以協助您根據 CPU 和記憶體使用情況，識別對效能影響最大的處理程序。

在增強型監控的作業系統 (OS) 處理程序清單部分中，檢閱作業系統處理程序和 RDS 處理程序。請檢查 mysqld 或 aurora 處理程序的 CPU 使用率百分比。這些指標可協助您確認 CPU 使用率增加是由作業系統還是由 RDS 處理程序所造成。或者使用這些指標，來監控由 mysqld 或 Aurora 造成的任何 CPU 使用率增加。若要查看 CPU 使用率的分割，請檢閱 cpuUtilization 的指標。如需更多詳細資訊，請參閱使用增強型監控來監控作業系統指標。

注意： 如果啟用「效能結構描述」，您可以將作業系統執行緒 ID 映射至資料庫的處理程序 ID。如需更多詳細資訊，請參閱為什麼 Amazon RDS 資料庫執行個體在我具有足夠的記憶體時使用交換記憶體？

使用效能洞察

您可以使用「效能洞察」來識別在資料庫執行個體上，執行查詢造成的 CPU 高使用率。首先，啟用 Performance Insights for MySQL。然後，使用 「效能洞察」來優化工作負載。如有需要，請與您的資料庫管理員合作，找出問題的根本原因。

若要查看可與「效能洞察」一起使用的資料庫引擎，請參閱支援效能洞察的 Amazon RDS 資料庫引擎、AWS 區域和執行個體類別。

使用查詢來偵測工作負載中 CPU 使用率的產生原因

您必須先識別有問題的查詢，然後才能優化工作負載。若要識別 CPU 使用率的根本原因，在發生高 CPU 使用率問題時，執行下列查詢。

若要查看 MySQL 執行個體上正在運行的執行緒，請執行 SHOW FULL PROCESSLIST 命令：

SHOW FULL PROCESSLIST;

注意： 以主要系統使用者身分執行 SHOW PROCESSLIST 查詢。如果您不是主要系統使用者，則必須有 MySQL PROCESS 伺服器系統管理員許可，才能查看在 MySQL 執行個體上執行的所有執行緒。如果沒有管理員許可，SHOW PROCESSLIST 僅顯示與您正在使用的 MySQL 帳戶關聯的執行緒。

有時，相同的陳述式集可能會繼續執行而不完成。當發生這種情況時，後續的陳述式必須等待第一個陳述式集完成。這是因為 InnoDB 資料列層級鎖定可能正在更新相同的資料列。如需更多詳細資訊，請參閱 MySQL 網站上的 13.7.5.29 SHOW PROCESSLIST 陳述式。

INNODB_TRX 表格提供有關正在執行且並非唯讀交易的所有 InnoDB 交易的資訊。若要檢視 INNODB_TRX 表格，請執行下列查詢：

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

INNODB_LOCKS 表格提供有關 InnoDB 交易已請求但尚未收到的鎖定的資訊。若要檢視 INNODB_LOCKS 表格，請執行下列查詢：

• MySQL 5.7 或更早版本：

  SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

• MySQL 8.0：

  SELECT * FROM performance_schema.data_locks;

如需更多詳細資訊，請參閱 MySQL 網站上的 24.4.14 INFORMATION_SCHEMA.INNODB_LOCKS 表格和 10.13.1 data_locks table。

INNODB_LOCK_WAITS 表格為每個已封鎖的 InnoDB 交易提供一或多個資料列。若要檢視 INNODB_LOCKS_WAITS 表格，請執行下列查詢。

• MySQL 5.7 或更早版本：

  SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

• MySQL 8.0：

  SELECT * FROM performance_schema.data_lock_waits;

若要查看正在等待的交易，以及正在封鎖等待交易的交易，請執行類似於下列範例的查詢：

• MySQL 5.7 或更早版本：

  SELECT  r.trx_id waiting_trx_id,
    r.trx_mysql_thread_id waiting_thread,
    r.trx_query waiting_query,
    b.trx_id blocking_trx_id,
    b.trx_mysql_thread_id blocking_thread,
    b.trx_query blocking_query
  FROM       information_schema.innodb_lock_waits w
  INNER JOIN information_schema.innodb_trx b
    ON b.trx_id = w.blocking_trx_id
  INNER JOIN information_schema.innodb_trx r
    ON r.trx_id = w.requesting_trx_id;

• MySQL 8.0：

  SELECT  r.trx_id waiting_trx_id,
    r.trx_mysql_thread_id waiting_thread,
    r.trx_query waiting_query,
    b.trx_id blocking_trx_id,
    b.trx_mysql_thread_id blocking_thread,
    b.trx_query blocking_query
  FROM       performance_schema.data_lock_waits w
  INNER JOIN information_schema.innodb_trx b
    ON b.trx_id = w.blocking_engine_transaction_id
  INNER JOIN information_schema.innodb_trx r
    ON r.trx_id = w.requesting_engine_transaction_id;

如需更多有關如何解釋此查詢輸出的詳細資訊，請參閱 MySQL 網站上的 17.15.2.1 使用 InnoDB 交易和鎖定資訊。

若要從標準 InnoDB 監控獲取有關 InnoDB 存儲引擎狀態的資訊，請執行以下查詢：

SHOW ENGINE INNODB STATUS;

如需更多詳細資訊，請參閱 MySQL 網站上的 13.7.5.15 SHOW ENGINE 陳述式。

若要檢視伺服器狀態，請執行下列命令。

SHOW GLOBAL STATUS;

如需更多詳細資訊，請參閱 MySQL 網站上的 15.7.7.37 SHOW STATUS 陳述式。

分析日誌並開啟監控

分析 MySQL 一般查詢日誌，以檢視 mysqld 在特定時間執行的操作。您還可以檢視特定時間在執行個體上執行的查詢，例如有關用戶端何時連接或中斷連接的資訊。如需更多詳細資訊，請參閱 MySQL 網站上的 7.4.3 一般查詢日誌。

重要： 如果長時間啟用「一般查詢日誌」，日誌會耗用儲存空間，且可能會增加效能額外負擔。

分析 MySQL 慢速查詢日誌，以尋找執行時間超過您為 long_query_time 設定的秒數的查詢。您也可以檢閱工作負載並分析查詢，以提高效能並減少記憶體耗用。如需更多詳細資訊，請參閱 MySQL 網站上的 7.4.5 慢速查詢日誌。

注意： 當您使用「慢速查詢記錄檔」或「一般查詢記錄檔」時，最佳實務是將參數 log_output 設定為 FILE。

使用 MariaDB 稽核外掛程式來稽核資料庫活動。例如，追蹤登入資料庫的使用者或針對資料庫執行的查詢。

如果使用 Aurora MySQL，您也可以使用進階稽核。「進階稽核」可對您要記錄的查詢類型提供更多的控制權，並降低記錄的開銷。

使用 innodb_print_all_deadlocks 參數來檢查是否存在死鎖和資源鎖定。您可以使用此參數，在 MySQL 錯誤日誌中記錄有關 InnoDB 使用者交易中死結的資訊。如需更多詳細資訊，請參閱 MySQL 網站上的 innodb_print_all_deadlocks。

分析並最佳化高 CPU 工作負載

在識別導致 CPU 用量增加的查詢後，優化工作負載以減少 CPU 耗用。

如果發現工作負載不需要的查詢，您可以執行下列命令終止連線：

CALL mysql.rds_kill(processID);

若要尋找查詢的 processID，請執行 SHOW FULL PROCESSLIST 命令。

如果您不想結束查詢，請使用 EXPLAIN 優化查詢。EXPLAIN 會顯示執行查詢時所涉及的個別步驟。如需更多詳細資訊，請參閱 MySQL 網站上的 10.8.1 使用 EXPLAIN 優化查詢。

若要檢視設定檔詳細資訊，請啟用分析。**SHOW PROFILE ** 命令顯示在目前作業階段期間執行陳述式的資源用量。如需詳細資訊，請參閱 MySQL 網站上的 15.7.7.30 SHOW PROFILE 陳述式。

若要檢視和最佳化表格統計資料，請使用 ANALYZE TABLE 查詢。如需更多詳細資訊，請參閱 MySQL 網站上的 15.7.3.1 ANALYZE TABLE 陳述式。

相關資訊

Amazon RDS for MySQL

Amazon RDS for MariaDB

如何啟用並監控 Amazon RDS for MySQL 資料庫執行個體的日誌？

使用「效能洞察」調校 Amazon RDS for MySQL