我应该使用SSD还是加内存?

本文是mysqlperformance上一篇关于单节点scale up的反思,作者通过benchmark给出了不同数据场景下scale up的选择方案,其中给出了三个评测点:

数据完全fit内存

数据比内存大一点点

数据是内存的3倍

不同点选择不同的方案进行scale up。虽然是一篇针对mysql的,但是个人觉得对于所有数据系统都是值得借鉴,当然,纯内存的cache除外-_-

原文地址:http://www.mysqlperformanceblog.com/2010/04/08/fast-ssd-or-more-memory/

尽管scale-out(向外扩展)是当前非常流行的MySQL扩展方式,有趣的是在以下的条件下,scale up(向上扩展)也是不错的选择-廉价的内存,快速的存储设备,更高的用电效率。我现在每周都能遇到一个使用Fusion-IO设备的客户。我曾经见过的最有趣的选择是,在系统仍有很多可用的read资源的时候去购买一块SSD——-如果是我的话,我宁愿去购买内存,而将存储设备提供给写操作。

以下是我的benchmark:

  • Percona-XtraDB-9.1 release
  • Sysbench OLTP workload with 80 million rows (about 18GB worth of data+indexes)
  • XFS Filesystem mounted with nobarrier option.
  • Tests run with:
    • RAID10 with BBU over 8 disks
    • Intel SSD X25-E 32GB
    • FusionIO 320GB MLC
  • 对每一个测试用例,分别使用从2G 到 22G的buffer pool (以此模拟数据大小跟内存可用大小之间的差异).
  • 硬件是 Dell 900.

首先,我们使用在RAID10上做的测作为一个基准.  Y轴上transactions/second (越多越好), X轴上innodb_buffer_pool_size的大小:

让我指出这个图有趣的几个特点:

  • A箭头所指的地方就是内存可以装下全部数据的时候,这个时候性能最好。很重要的事,一旦你达到这个点,你完全不需要增加内存。
  • B箭头所指的地方就是数据大小刚刚超过buffer pool的时候.这对大部分用户来说是最痛苦的-因为此时内存下降哪怕10%(即数据大小超过内存10%)性能将下降2.6倍。在线上应用中,最符合这一点的就是”上周一切都运行良好,但现在越来越慢”.这种情况我觉得增加内存是目前最好的办法。
  • C箭头所指的地方就是数据大概是buffer pool的3倍,这时你增加内存可能不是一个好办法,可能SSD才更加适合,请看下图:

在上面所说到的C箭头所指的地方(即数据是内存的三倍大), 在这个图中Fusion-IO提高了大概5倍的性能 ( Intel SSD提高了2倍). 如果使用内存来提高性能,你需要增加60%的内存来达到2倍当前性能的提升,或者增加260%的内存来达到5倍当前性能的提升,设想一下当你达到C箭头这个地方,你的内存是32G而数据是100G,那么现在就很有趣了:

  • 你能再往机器上添加一个32G的内存吗(内存槽够用不?)
  • 你的预算允许装载SSD吗?(因为你很可能会需要不止一块SSD,很多人都使用了8块SSD).
  • 2倍或者5倍的性能提升有用么?.

这里我们保持尽可能多热数据,但是可能我们这里讨论的更多的是不要低估了你的活跃数据量,因为很可能它比你的预期要多很多。

注意:这里的测试仅仅表现了趋势,具体的各个点的细节会和你的机器有关.

下面是我的测试结果:

Buffer pool, GB FusionIO Intel SSD RAID 10
2 450.3 186.33 80.67
4 538.19 230.35 99.73
6 608.15 268.18 121.71
8 679.44 324.03 201.74
10 769.44 407.56 252.84
12 855.89 511.49 324.38
14 976.74 664.38 429.15
16 1127.23 836.17 579.29
18 1471.98 1236.9 934.78
20 2536.16 2485.63 2486.88
22 2433.13 2492.06 2448.88

anyShare赠人玫瑰,手有余香,分享知识,德艺双馨!
          

无觅相关文章插件,快速提升流量

分类 理论原地 · tag , ,