最近業(yè)主要求要把系統(tǒng)從電信云遷移到區(qū)里面的政數(shù)云，遷移前電信云是8核16G的配置，遷移后政數(shù)云是32核32G的配置，按理說遷移后性能應(yīng)該非常好，結(jié)果老是系統(tǒng)崩潰，查找原因是MySQL占用CPU過高，占用率達(dá)到了1800%。于是進(jìn)行了一系列的問題排查解決。
1、因要快速解決問題，不能影響客戶使用，第一想到是存儲(chǔ)可能是因?yàn)榇娴酵鈷斓臄?shù)據(jù)盤上，數(shù)據(jù)盤不是固態(tài)的，性能不足，于是把存儲(chǔ)及mysql關(guān)聯(lián)的全部改成系統(tǒng)盤。事后觀察還是CPU過高。
2、于是優(yōu)化SQL,把常用業(yè)務(wù)功能里面的SQL拉出來排查，發(fā)現(xiàn)之前的這條SQL大概1秒能出來，現(xiàn)在4-10秒才出來，于是EXPLAIN查看具體情況，其中查到定位到一個(gè)子查詢是慢的原因，大概是如下這樣
select e,count(e) from t where a=xx and b=xx and c=xx and d=xx group by e
對(duì)a、b、c、d建了聯(lián)合索引，e是主鍵索引
explain后
Using temporary表示由于排序沒有走索引，于是加了order by null,再看還是Using temporary，分析using index condition應(yīng)該是走的聯(lián)合索引，那Using temporary應(yīng)該是后面group by引起的，那就是e字段有問題，e字段是主鍵，也沒有走主鍵索引。于是把聯(lián)合索引修改成a、b、c、d、e,再次explain后
查詢速度立馬到了1秒。但后面還是CPU過高。于是考慮mysql配置。
3、修改MYSQL配置如下
innodb_buffer_pool_size = 8000M
innodb_buffer_pool_chunk_size= 8000M
innodb_buffer_pool_instances=8
tmp_table_size = 1024M
max_heap_table_size = 1024M
wait_timeout = 90
interactive_timeout = 90
max_connections = 500
觀察高峰期后，還是CPU過高，導(dǎo)致系統(tǒng)崩潰。
4、查看讀寫系統(tǒng)性能
安裝iotop和IOStat的檢測工具包：
#yum -y install sysstat
#yum -y install iotop
對(duì)比遷移前后對(duì)比，發(fā)現(xiàn)kb_read差距挺大。
對(duì)比后發(fā)現(xiàn)讀寫能力不足，于是查看云空間回執(zhí)表，如下：
分布式存儲(chǔ)按理解應(yīng)該沒有多大問題，也沒有表示懷疑。于是帶著疑問問供應(yīng)商，為啥現(xiàn)有的系統(tǒng)性能不如以前，發(fā)現(xiàn)給我們的磁盤存儲(chǔ)是分布式存儲(chǔ)，但同是也是共享存儲(chǔ)，意思是這個(gè)區(qū)域所有的政務(wù)系統(tǒng)都是共用這塊存儲(chǔ)，可能涉及查詢業(yè)務(wù)比較多，所以讀的能力差，而寫的能力還可以。因?yàn)榇讼到y(tǒng)用戶比較大，而且調(diào)優(yōu)慢SQL耗時(shí)較大，也是個(gè)巨大的工程，于是提出改變，改用FC-SAN,解決問題。
