CPU - Amazon Aurora
支援的引擎版本Context等待變多的可能原因動作

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

CPU

此事件表示執行緒活躍於 CPU 中或正在等待 CPU。

支援的引擎版本

此等待事件資訊與 Aurora PostgreSQL 9.6 版及更新版本有關。

Context

中央處理單元 (CPU) 是執行指令的電腦元件。例如，CPU 指令執行算術運算，並在記憶體中交換資料。如果查詢增加更多指令來透過資料庫引擎執行，則查詢會執行更久。CPU 排程將 CPU 時間撥給程序。排程由作業系統的核心協調。

如何得知發生這種等待

此 CPU 等待事件表示後端程序活躍於 CPU 中或正在等待 CPU。當查詢顯示下列資訊時，就表示發生此事件：

  • pg_stat_activity.state 欄具有值 active。

  • pg_stat_activity 中的 wait_event_type 和 wait_event 欄皆為 null。

若要查看正在使用或等待 CPU 的後端程序，請執行下列查詢。

SELECT * 
FROM   pg_stat_activity
WHERE  state = 'active'
AND    wait_event_type IS NULL
AND    wait_event IS NULL;

DBLoadCPU 指標

CPU 的績效詳情指標為 DBLoadCPU。DBLoadCPU 的值與 Amazon CloudWatch 指標 CPUUtilization 的值可能不同。後者是從 HyperVisor 為資料庫執行個體收集的指標。

os.cpuUtilization 指標

績效詳情作業系統指標提供 CPU 使用率的詳細資訊。例如，您可以顯示下列指標：

  • os.cpuUtilization.nice.avg

  • os.cpuUtilization.total.avg

  • os.cpuUtilization.wait.avg

  • os.cpuUtilization.idle.avg

績效詳情以 os.cpuUtilization.nice.avg 報告資料庫引擎的 CPU 使用率。

CPU 排程的可能原因

就作業系統而言，CPU 不執行閒置執行緒時，就處於作用中。CPU 執行運算時就處於作用中，但等待記憶體輸入/輸出時也是處於作用中。在典型資料庫工作負載中，這種輸入/輸出佔多數。

滿足下列條件時，程序可能等待排定使用 CPU：

  • CloudWatch CPUUtilization 指標接近 100%。

  • 平均負載大於 vCPU 數目，表示負載過重。您可以在績效詳情的作業系統指標區段中找到 loadAverageMinute 指標。

等待變多的可能原因

CPU 等待事件比平時更常發生時，可能表示有效能問題，典型原因包括下列各項。

突然激增的可能原因

突然激增最可能的原因如下：

  • 應用程式對資料庫同時開啟太多連線。這種情況稱為「連線風暴」。

  • 應用程式工作負載出現下列任何變化：

    • 新查詢

    • 資料集變大

    • 維護或建立索引

    • 新函數

    • 新運算子

    • 平行執行查詢增加

  • 查詢執行計劃已變更。在某些情況下，變更可能造成緩衝區增加。例如，查詢原本使用索引，但現在使用循序掃描。在此情況下，查詢需要更多 CPU 才能完成相同的目標。

長期頻繁的可能原因

事件長期復發最可能的原因：

  • CPU 上同時執行太多後端程序。這些程序可能是平行工作者。

  • 查詢表現欠佳，因為需要大量緩衝區。

罕見情況

如果可能原因都不是真正原因，可能表示發生下列情況：

  • CPU 正在換入換出程序。

  • CPU 環境切換次數變多。

  • Aurora PostgreSQL 程式碼遺漏等待事件。

動作

如果 CPU 等待事件在資料庫活動中佔多數，則不見得表示有效能問題。效能降低時才需要回應此事件。

調查資料庫是否造成 CPU 使用率上升

在績效詳情中檢查 os.cpuUtilization.nice.avg 指標。如果此值遠低於 CPU 使用率，表示佔用 CPU 以非資料庫的程序為主。

判斷連線數目是否增加

在 Amazon CloudWatch 中檢查 DatabaseConnections 指標。您的動作取決於在 CPU 等待事件變多期間，連線數目是增加還是減少。

連線增加

如果連線數目上升，請將耗用 CPU 的後端程序數目與 vCPU 數目做比較。可能的情況如下：

  • 耗用 CPU 的後端程序數目小於 vCPU 數目。

    在此情況下，連線數目不是問題。但您仍然可以嘗試降低 CPU 使用率。

  • 耗用 CPU 的後端程序數目大於 vCPU 數目。

    在此情況下，請考慮下列選項：

    • 將連線至資料庫的後端程序數目減少。例如，實作連線集區解決方案，例如 RDS Proxy。如需進一步了解，請參閱 使用 Amazon RDS Proxy for Aurora。

    • 加大執行個體以取得更多 vCPU。

    • 如適用，請將一些唯讀工作負載重新導向至讀取器節點

連線未增加

在績效詳情中檢查 blks_hit 指標。尋找 blks_hit 增加與 CPU 使用率之間的關聯性。可能的情況如下：

  • CPU 使用率與 blks_hit 有關。

    在此情況下，請找出與 CPU 使用率最有關的 SQL 陳述式，並尋找計劃變更。您可以使用下列任一技巧：

    • 手動解釋計劃，並與預期的執行計劃做比較。

    • 查明每秒區塊命中數和每秒本機區塊命中數是否增加。在績效詳情儀表板的 Top SQL (常用 SQL) 區段中，選擇 Preferences (偏好設定)。

  • CPU 使用率與 blks_hit 無關。

    在此情況下，請判斷是否發生下列任何情形：

    • 應用程式與資料庫之間快速連線和斷線。

      請開啟 log_connections 和 log_disconnections，然後分析 PostgreSQL 日誌，以診斷此行為。考慮使用 pgbadger 日誌分析器。如需詳細資訊，請參閱 https://github.com/darold/pgbadger。

    • 作業系統超載。

      在此情況下，績效詳情會指出後端程序耗用 CPU 比平常更久。在績效詳情 os.cpuUtilization 指標或 CloudWatch CPUUtilization 指標中查證。如果作業系統超載，請檢查增強型監控指標以進一步診斷。具體來說，請檢查程序清單及每個程序耗用的 CPU 百分比。

    • 常用 SQL 陳述式耗用太多 CPU。

      檢查與 CPU 使用率有關的陳述式，了解是否可以少用 CPU。執行 EXPLAIN 命令，專注於影響最大的計劃節點上。考慮使用 PostgreSQL execution plan visualizer。若要試用此工具，請參閱 http://explain.dalibo.com/。

回應工作負載變更

如果工作負載已變更，請尋找下列類型的變更：

新查詢

檢查是否需要新的查詢。如果是，請確定其執行計劃和每秒執行次數合理。

資料集變大

決定是否應該分割 (如果尚未分割)。此策略可以減少查詢需要擷取的分頁數。

維護或建立索引

檢查是否需要排定維護。最佳實務是將維護活動排定在尖峰活動之外。

新函數

檢查這些函數在測試期間是否正常執行。具體來說，請檢查每秒執行次數是否合理。

新運算子

檢查在測試期間是否正常執行。

平行執行查詢增加

判斷是否發生下列任何情況：

  • 涉及的關聯或索引突然變大，明顯不同於 min_parallel_table_scan_size 或 min_parallel_index_scan_size。

  • 最近變更 parallel_setup_cost 或 parallel_tuple_cost。

  • 最近變更 max_parallel_workers 或 max_parallel_workers_per_gather。