MySQL性能调优之Memory or SSD？

当一个传统的向外扩展的方式对于MySQL来讲变得流行，看看我们不得不扩充哪一方面（便宜的内存？快速存储？更好的电源效率？）将会变得非常有趣。这里确实有很多种选择——我每周大概会遇到一个客户使用Fushion-IO 卡。然而，我却看到了他们一个有趣的选择——他们选择购买一个SSD，当他们每秒仍然能读取很多页的时候（这时，我宁愿选择购买内存来取代），而使用存储驱动器做“写操作”使用。在这里，我提出几个参考标准来供你确认是否是以上我说的这种情况：

Percona-XtraDB-9.1 release
Sysbench（开源性能测试工具）的OLTP有8千万行的“工作量”（大概等同于18GB的数据+索引）
XFS 文件系统选择nobarrier选项安装
测试运行具有：

1. 带有BBU的RAID 10硬盘超过8块（所谓BBU，社区的解释是在掉电的情况下，能够cache数据72h，当机器供电正常，再从cache中将数据写入磁盘）2. Inter SSD X25-E 32GB3. FushionIO 320GB MLC【1】

对于每一次测试，在运行的时候将缓冲池设置在2G到22G之间（为了和合适的内存比较性能）
硬件配置：

Dell PowerEdgeR9004 QuadCoreIntel（R） Xeon（R） CPU E7320 @ 2.13GHz （16 cores in total）32GB of RAMRAID10 on 8disks 2.5” 15K RPMSFusionIO 160GBSLCFusionIO 320GBMLCOS:CentOS 5.5XFS filesystem开始，我们对RAID 10的存储做一个测试以建立一个基线。Y轴是每秒传输的数据（传输速率，它越大越好）。X轴是innodb_buffer_pool_size的大小。
我特地挑选了关于该测试中的三个有趣的点

A点，当数据完全符合缓冲池大小（最佳性能）。一旦你达到该点，简直就像内存的进一步增加，了解该信息很重要。
B坐标出现在当数据刚开始超过缓冲池的大小。这对于许多用户来讲是最让人头疼的一点了。因为当内存下降仅10%，而性能却比原来降低了2.6倍。在产品中，这通常应对着这样的说辞——“上个星期一切看起来都还OK，但它却正在变得越来越慢！”。我想建议你，增加内存是迄今为止最好的做法，在这种情况下。
C点展示数据大约是缓冲池三倍的地方。它是一个有趣的点，既然你不能够计算出内存的花费（可能不了解未来遇到瓶颈需要耗费多少购买内存的成本），这是购买一个SSD可能更为合适。

Hibernate 三种状态ORA-12154 和 TNS-03505 监听错误的解决方法相关资讯 MySQL数据库基础教程

MySQL服务器Linux IO调度器算法的（10/16/2012 20:53:36）
MySQL SQL语句过长引起的问题（06/14/2012 17:25:17）
MySQL Workbench “Error Code: （04/28/2012 21:16:54）

Linux自动启动MySQL （07/30/2012 11:05:29）
MySQL 中explain的用法（05/04/2012 08:53:12）
MySQL的备份与恢复（04/20/2012 09:06:25）

本文评论查看全部评论（0）