2013-04-17 70 views
0

我已經在亞馬遜EC2(新加坡地區)上發佈了我的網站,並且我已經在同一地區使用MySQL RDS介質實例進行數據存儲。由於COUNT查詢引起的亞馬遜RDS CPU利用率

在我的情況下,大多數select查詢都有一些COUNT的功能。這些查詢顯示非常緩慢的結果。我已經在表上創建了適當的索引,並且我檢查了EXPLAIN命令來分析這些查詢。它向我展示了全表掃描是獲得結果所必需的。

在我的RDS中實例上,我已經使用以下設置配置了自定義參數組。

log_queries_not_using_index = true, 
slow_query_log = true, 
long_query_time = 2 sec, 
max_connections = 303, 
innodb_buffer_pool_size = {DBInstanceClassMemory*3/4} 

昨天我的CPU利用率超過95%,我的網站因此崩潰。流量沒有大幅增加。

此外,我將數據轉儲到本地系統,並測試了其中一個COUNT查詢。雖然它在RDS上運行需要大約1.5秒,但在本地系統上運行它只需要大約400毫秒。我的本地系統(4GB內存,英特爾酷睿2 2.8GHz的)上的配置是:

max_connections = 100, 
slow_query_log = true, 
long_query_time = 2 sec, 
innodb_buffer_pool_size = 72351744 

那麼,什麼可能是在CPU利用率峯值的原因以及RDS之間在性能上時間差我的本地系統?

感謝,

回答

1

根據表大小 - RDS實例使用EBS存儲數據 - 如果你正在做一個表掃描和將要得到的從EBS而不是本地緩存中的數據內存中的密鑰,然後掃描它。因此 - 您可能會看到CPU駐留的RDS實例與SAN中的EBS數據之間的網絡延遲增加。當您在本地計算機上執行相同的查詢時,唯一的滯後是磁盤磁頭尋道時間。

然後是CPU時間之間的差 - 一個m1.medium具有較少的CPU時間(以及因此更小的掃描結果的機會)比基於的EC2單元Amazon的定義中的Core2雙核。

HTH - 一般來說,我會盡量避免在查詢中執行COUNT,因爲這是一個非常低效的查詢(正如您所見),當數據庫可能並將繼續導致令人討厭的不良結果時正在實時變化的負載水平下。

R