MySQL案例:一次單核CPU佔用過高問題的處理
阿新 • • 發佈:2018-12-19
客戶現場反饋,top的檢查結果中,一個CPU的佔用一直是100%。實際上現場有4個CPU,而且這個伺服器是mysql專屬伺服器。
我的第一反應是io_thread一類的引數設定有問題,檢查以後發現read和write的thread設定都是4,這和CPU數一致,因此可以斷定這並不是單顆CPU佔用過高的問題。
接下來需要確認MySQL究竟有沒有利用到多核CPU,這個時候需要的工具叫做pidstat,命令如下:
pidstat -u -t -p 18158
得到的結果如下圖所示:
可以看出其實mysqld是可以利用到多核CPU的,那麼此時可以得到一個推斷:
某個CPU上做的事情太佔資源了
一般這種最佔資源的工作一定會在INNODB_TRX裡留下一些端倪,因此檢查一下:
反覆的檢查TRX,發現mysql在不停的執行這個SQL,只是where條件裡的值發生了變化,至此我可以推斷出業務應該是寫了一個迴圈來遍歷一個list,然後對每個item都執行update操作。
應該是寫了這麼一段程式碼在處理問題:
for (item in list) {
update_db(item);
}
檢查這個表並沒有索引,給where條件中的列加上索引,再次檢查CPU的佔用,發現現在的佔用已經降低到了16%左右,雖然還是很高,但是已經實際上解決了該問題。
這裡我有點感慨,DBA並不是你會寫SQL就可以乾的,DBA實際上是運維人員的一種,運維要掌握多少種技能恐怕只有運維小夥伴們清楚,其實技術難度並不比寫Java程式碼低。DBA掌握多少種檢查問題的手段,DBA面對問題時能不能第一時間找準方向,這都是經驗和功力的展現。