如何對我的 Amazon DocumentDB 執行個體疑難排解並解決 CPU 高使用率的問題?
我發現 Amazon DocumentDB (with MongoDB compatibility) 資料庫執行個體的 CPU 使用率很高。
簡短說明
Amazon DocumentDB 執行個體的 CPU 使用率會協助您了解如何對進行中的工作負載執行目前配置的資源。
您可能會因為下列原因而發現 CPU 使用率增加:
- 使用者造成的繁重工作負載
- 無效率查詢
- 叢集中的寫入器負擔過重,因為叢集中的讀取負載不平衡
- 讀取器的硬體組態低於寫入器,無法與高寫入工作負載進行同步
- 內部任務,例如 Amazon DocumentDB 叢集中的垃圾回收
- 太多資料庫連線 (閒置)
- 短連線爆量
若要識別 Amazon DocumentDB 執行個體中 CPU 使用量的主要來源,請檢閱下列各方面的資訊:
- Amazon CloudWatch 指標
- Performance Insights
- 原生資料庫查詢
- 檢查查詢的效率
- 激進的日誌記錄設定
找出原因之後,分析並最佳化您的工作負載以減少 CPU 使用量。如果問題仍然存在,則請根據您的工作負載增加執行個體大小。
解決方法
使用 CloudWatch 指標
Amazon DocumentDB 會與 CloudWatch 整合,並可讓您收集和分析叢集的作業指標。
CloudWatch 指標可讓您在延伸期間內識別 CPU 及其比例指標型樣。檢閱這些指標,然後在 CloudWatch 主控台中進行監控:
- 使用 DatabaseConnections 和 DatabaseConnectionsMax 來識別以相關時間表開啟的連線數目。
- 使用 WriteIOPs、ReadIOPs、ReadThroughput 和 WriteThroughput 以了解 Amazon DocumentDB 執行個體的整體工作負載。
- 使用 DocumentsDeleted、DocumentsInserted、DocumentsReturned 和 DocumentsUpdated。這些指標可協助您了解 Amazon DocumentDB 執行個體的使用者工作負載。
- 如果您使用 T3 或 T4 執行個體類別,則請檢閱 CPUCreditBalance 和 CPUSurplusCreditBalance 以檢查是否計算節流。
使用 Performance Insights 指標
使用 Amazon DocumentDB Performance Insights 以識別有助於資料庫載入和等待狀態的查詢。在管理指標選項下,使用平均作用中階段作業以檢閱負載和 CPU 分配 (系統百分比、使用者百分比或總百分比)。
平均負載大於 vCPU 數量,即表示執行個體負載過重。例如,平均負載可能會小於資料庫執行個體類別的 vCPU。這表示 CPU 節流可能不是應用程式延遲的原因。檢查平均負載並分析相關的等待狀態,以了解新增 CPU 使用量的來源,例如 I/O、鎖定和閂鎖。
使用原生資料庫查詢
原生查詢可協助您分析工作負載並檢查 CPU 使用量。使用 MongoDB Shell 來執行此查詢。這樣會列出目前在 Amazon DocumentDB 執行個體上執行的所有作業:
db.adminCommand({currentOp: 1, $all: });
此查詢會使用 currentOp 命令以列出封鎖或執行超過 10 秒的所有查詢:
db.adminCommand({aggregate: 1, pipeline: [{$currentOp: {}}, {$match: {$or: [{secs_running: {$gt: 10}}, {WaitState: {$exists: true}}]}}, {$project: {_id:0, opid: 1, secs_running: 1, WaitState: 1, blockedOn: 1, command: 1}}], cursor: {} });
若要分析系統使用量結果,請在您發現 CPU 使用量過高的執行個體上執行此查詢。此查詢會傳回在每個名稱空間中執行的所有查詢彙總。它還會列出所有內部系統任務,以及每個名稱空間的唯一等待狀態數量。
db.adminCommand({aggregate: 1, pipeline: [{$currentOp: {allUsers: true, idleConnections: true}}, {$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}], cursor: {} });
**注意事項:**內部任務下的 GARBAGE_COLLECTION 指標是 Amazon DocumentDB 叢集中的 MVCC 實作。這是一種背景清掃程式,可移除停用的文件版本,並與資料庫上更新或刪除的數量相關。系統會根據回收層次的內部閾值觸發清掃流程,並會導致讀取/寫入 IOPS 和 CPU 使用量。
檢查查詢的效率
檢查寫入查詢的索引超載
太多的索引或與資料庫相關聯的大量未使用的索引可能會增加寫入的超載。檢閱索引統計資料以分析索引使用量並加以識別。
檢查 explain 的查詢計畫
查詢可能會緩慢執行,因為這些查詢需要對回收進行完整掃描以選擇相關文件。建立適當的索引以提高查詢速度。
使用 explain 命令來識別您想要在其上建立索引的欄位。您還可以使用分析工具日誌以擷取長時間執行的查詢及其作業的詳細資料。
檢查回收的統計資料
為您使用的回收檢查這些統計資料:
- 檢閱 Performance Insights 中的「熱門查詢」區段,以識別造成最大負載的回收。
- 檢閱回收的統計資料,以了解對該統計資料執行的插入、更新和刪除作業的數量。您還可以檢閱執行的索引掃描和完整回收掃描的數量。
- 分割回收以減少要處理的文件大小,尤其是若您有大量的更新作業。
檢查「激進的日誌記錄」設定
事件稽核的優先順序高於資料庫流量。如果不需要稽核,則您可以將該稽核關閉。如果您確實需要稽核,則請設定 audit_logs 參數,以僅記錄需要的事件。規劃增加的負載,然後在需要時切換到更大的執行個體類別。
若為分析工具日誌,請確定已為 profiler_threshold_ms 參數設定正確的值,以避免激進的日誌記錄。檢閱您的應用程式工作負載,以識別長時間執行時間分類查詢所需的正確閾值。
確認您已針對您想要匯出至 CloudWatch 的日誌啟用日誌匯出選項。
使用最佳實務
將讀取工作負載卸載至讀取器
如果您在 Amazon DocumentDB 叢集中有多個資料庫執行個體,請將讀取工作負載卸載至讀取器執行個體。您以抄本集進行連接時,可以指定連線的 readPreference。如果您指定了 secondaryPreferred 的讀取喜好設定,則用戶端會嘗試將讀取查詢遞送至您的抄本。用戶端嘗試將寫入查詢遞送至您的主要資料庫執行個體。
請注意,讀取器具有最後的一致性。如果工作負載需要更強的先寫後讀一致性,則請使用動態讀取喜好設定,並在查詢層次予以覆寫。例如,您可能會在連線層次預設為 secondaryPreferred,因此會將查詢移至次要。如果您有需要更強的先寫後讀一致性的查詢,您可以覆寫預設值。請參閱此範例:
db.collection.find().readPref("primary")
將一或多個讀取器執行個體新增至叢集
如果您的 Amazon DocumentDB 叢集具有單一資料庫執行個體 (僅限寫入器),則請將一或多個讀取器資料庫執行個體新增至叢集。然後,使用 readPreference=secondaryPreferred 以有效地處理負載。
使用「Amazon DocumentDB 分析工具」來識別慢速查詢
使用 Amazon DocumentDB 分析工具來記錄慢速查詢。如果查詢重複出現在慢速查詢日誌中,則您可能會需要其他的索引以改善效能。
尋找具有一個或多個階段的長時間執行查詢,該階段至少要執行一個 COLLSCAN 階段。這表示查詢階段必須讀取回收中的每個文件,以提供查詢的回應。
如需詳細資訊,請參閱 Amazon DocumentDB (with MongoDB compatibility) 中的設定檔慢速執行查詢。
使用 CloudWatch 建立警報通知
建立 CloudWatch 警報,在 CPU 使用率指標超過特定閾值時通知您。
對資料庫執行個體的執行個體類別進行縱向擴展
如果沒有進一步的查詢調整範圍,請對叢集中執行個體的執行個體類別進行縱向擴展以處理工作負載。
**注意事項:**如果您對執行個體類別進行縱向擴展,則這項動作會增加成本。如需詳細資訊,請參閱 Amazon DocumentDB 定價。
相關資訊
相關內容
- 已提問 2 個月前lg...
- 已提問 1 年前lg...
- 已提問 1 年前lg...
- 已提問 1 年前lg...
- AWS 官方已更新 1 年前
- AWS 官方已更新 2 個月前
- AWS 官方已更新 2 年前