使用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 |
等等 |
评论