往期分享
RDS MySQL 小版本更新最佳實踐 RDS MySQL 執行個體空間問題 RDS MySQL 記憶體使用問題 RDS MySQL 活躍線程數高問題 RDS MySQL 慢SQL問題 RDS MySQL 執行個體IO高問題概述
CPU使用率過高問題是RDS PG使用者遇到的性能問題中較常見的一類。當RDS SQL Server執行個體的CPU使用率持續較高時，很容易導緻資料庫通路卡慢的情況，例如一些很簡單的查詢請求的響應時間也會很久甚至逾時失敗。
資源監控
在RDS控制台的“監控與報警”頁中的“标準監控”->“資源監控”下，可以檢視指定時間段内執行個體的CPU使用率資訊。
對于RDS PG來說，CPU使用率持續大于80%以上，通常表明系統處于高負載的情況，并且很可能存在較嚴重的性能問題。
CPU基本概念
- CPU使用率，CPU使用率指的是CPU執行工作時間的比例，包含了所有符合條件的活動的時鐘周期，比如停滞等待IO而導緻較高的使用率，CPU使用率又被分為核心時間和使用者時間。
- 使用者時間，執行使用者态程式的時間被稱為使用者時間。
- 核心時間，執行核心态代碼的時間為核心時間，包含系統調用，核心線程和中斷的時間。
- 上下文切換，核心程式切換CPU讓其在不同的位址空間上操作
- 中斷，由實體裝置發送給核心的信号，通常是請求I/O服務
CPU高的常見原因
掃描行高
檢視資源監控可以看出CPU使用率很高。
檢視引擎監控操作行數
發現存在大量的全表掃描行，這個是導緻CPU高的主要問題，對于一個查詢來說，如果該查詢傳回10行資料，我們需要盡量保證SQL通過索引掃描10行資料傳回，此時效率是最高的，而不是全表掃描100W行資料後過濾掉99%的資料，傳回10行給用戶端。評價一個查詢是否掃描行很高就可以通過該查詢的傳回行和掃描行相比可以知道，如果掃描行遠大于傳回行說明該SQL可以通過建立合适索引可以極大程度的降低SQL的響應時間以及降低CPU資源的使用率。
通過das的性能洞察可以找出問題SQL
找到慢SQL後，可以參考RDS PG慢SQL問題，進行SQL的優化。
活躍會話高
檢視資源監控
發現CPU使用率較高，此時系統态占用達到了23%，說明可能存在大量的系統調用或者中斷導緻系統态CPU使用率較高。
檢視下引擎監控的操作行數
發現此時全表掃描行數并不高。
檢視下引擎監控的連接配接情況
發現此時活躍會話數已達到279個，此執行個體規格為2C4G，因為CPU隻有兩個core，同時卻有279個會話同時運作，此時CPU會頻繁的進行上下文切換，導緻CPU的系統态占用增加，降低了CPU實際去執行SQL的時間。此時說明資料庫資源已遠超目前能提供服務的負載。一般合理的活躍會話數量是目前執行個體規格CPU數量的2-3倍，例如執行個體規格為2C4G，性能最高的情況為活躍會話數不超過4-6個，此時CPU使用效率最高，絕大多數CPU資源都用于執行SQL，而不是進行上下文切換或者中斷等。
檢視DAS中的會話管理，檢視目前活躍狀态的SQL以及數量。
檢視DAS中的性能洞察檢視目前具體的SQL分布，以及SQL的等待事件
對于這類情況，需要考慮進行規格的更新，或者降低并發降低活躍會話的數量，儲存活躍會話在一個合理的範圍内。