使用LAMP架構搭建網站環境大約是從2006年初開始的,MySQL的性能優化一直沒有做得很好,總是遇到問題再臨時解決,專門去調優又難以見到非常明顯的效果。所以今年初開始采用阿裡雲服務的時候就再也不用自己搭建的MySQL了,而是采用現成的RDS雲數據庫,希望阿裡能幫忙做DBA的工作。
不過也沒有那麼理想,2月份當時轉網站的時候也是遇到數據庫反應慢的問題(某條查詢語句需要運行100秒以上),懷疑是RDS服務器性能瓶頸就多次提升硬件配置還是沒有解決,最後是自己反複排查、讓阿裡雲技術支持人員幫忙分析,發現是導入大批數據後複雜SQL語句的執行計劃有問題,某個統計數據出現錯誤,進行數據表分析(或者優化?)後解決。
後來把轉移過來的MyISAM存儲引擎替換為InnoDB希望加快速度,但在有一台勁捷公司的RDS上引起IOPS明顯上升,隻好還原為MyISAM,咨詢阿裡客服也說讀取量大、寫入量小的情況下,MyISAM更有優勢。但另外一台多庫公司的RDS上運行還正常,就維持InnoDB不變。
最近幾天又從在武漢電信托管的服務器上向多庫公司的阿裡雲服務器轉移一批站點,以前的MyISAM轉過來不變,還順便去把原來轉為InnoDB的表都還原為MyISAM,結果很快出現連接數超過限制的情況,采取屏蔽采集IP、修改RDS參數等辦法都沒有解決,先沒有懷疑“InnoDB的表都還原為MyISAM”是原因,隻以為剛轉過來的站點修改DNS後流量逐步增大就出現RDS瓶頸。
後來和同事一起拿着一本《MySQL調優與系統架構》的書,對着RDS的各種參數進行設置,又去讀取RDS的各種狀态數據,發現我們購買的1200M内存配置RDS裡面隻有16M用于MyISAM的key_buffer_size,而且這個關鍵參數還是不能自己修改的,再仔細看用于InnoDB的innodb_buffer_pool_size達到1000M左右(另外一台600M内存配置的RDS分配innodb_buffer_pool_size大約500M,key_buffer_size還是16M,還有一台240M内存配置的RDS分配innodb_buffer_pool_size大約200M,key_buffer_size還是16M),這樣的話應該是把大約80%的内存分配到InnoDB做緩沖池了,我們如果隻用到MyISAM或者絕大多數都用MyISAM,那就讓絕大多數内存閑置了(或者被少數InnoDB表占用了),這很有可能就是現在我們遇到性能問題的原因。
這兩個關鍵參數在RDS管理後台是無法修改的,所以我們不得不把一部分MyISAM表再次轉換為InnoDB引擎,從效果上來看,很快就發現RDS的連接數、CPU利用率都下降穩定在正常範圍内了,隻是IOPS有一定增加但也在可承受範圍内。這樣算是找到問題所在及基本上解決了。
考慮下一步進行的嘗試:
- 對比InnoDB和MyISAM存儲表分别的查詢量,将更多的表轉為InnoDB,并綜合查看平衡點;
- 考慮一個庫中不同的表混合使用兩種存儲引擎,在讀多寫少的表用MyISAM,讀多寫也多的表用InnoDB;
- 雖然MySQL 5.6中InnoDB也支持全文檢索,但MyISAM明顯性能更優,考慮将這相關的表使用MyISAM。
2015年7月1日補充:有經過多輪調整,發現幾個特點補充記錄:
- InnoDB對硬盤空間的占用超過MyISAM數倍,在數據量大的情況下(例如幾百個庫、每個庫100多個表、大表可能超過1G),這個成本都不容忽視;
- InnoDB對IOPS的壓力遠大于MyISAM,所以我們後來還是盡量使用MyISAM,雖然有一些缺點(例如穩定性、寫性能等);
- RDS對InnoDB的支持逐步增強,對MyISAM的支持逐步降低,我們新購買的美國數據中心RDS MySQL5.6,居然需要人工申請、承諾風險才能為我們打開MyISAM支持;
- RDS自帶的參數不能保證是最适當的,很多時候需要自己再調整,例如query_cache_type默認為0,需要設置為1打開查詢緩存功能并重啟RDS,另外還有好些不需要重啟的參數需要調整,例如:
參數名 | 變更前的參數值 | 變更後的參數值 |
---|---|---|
table_definition_cache | 512 | 2048 |
table_open_cache | 2000 | 4000 |
tmp_table_size | 262144 | 16777216 |
myisam_sort_buffer_size | 262144 | 16777216 |
query_prealloc_size | 8192 | 16384 |
query_cache_size | 0 | 33554432 |
query_alloc_block_size | 8192 | 16384 |
key_cache_block_size | 1024 | 16384 |
等等 |
评论