MySQL基础建设之硬盘篇

MySQL基础建设之硬盘篇 

随着业务的不断增长，之前的环境越来越乱，由此欲重建整个MySQL数据库基础环境

主要目的是要考虑 数据冗余、性能、平衡 目的是让机器的性能最大的发挥，同时比较好维护

一、硬件选型

1.节点统计

目前已将各库进行分隔，但由于每台机器都过老过保，业务稳定但是硬件问题多多，出于节约成本，将机器数合并至两台数据库上

2.数据量统计

出于规划硬盘空间，需将每台机器所占用的data数据、binlog、slow log 及近期备份的日志文件总和一一列出，如下所示

某机房

功能业务

data空间使用情况

slow log空间使用情况

bin_log目录使用情况

某同步系统|主库

192G

4.9G

3.2G

某同步系统|从库

281G

43M

3.2G

某api服务|主库

6.2G

300M

3G

某api服务|从库

6.6G

13M

3G

综合业务服务|主库

2.9G

2M

4.8G

综合业务服务|从库

1.4G

92M

3.2G

账号服务 | 主库

4.7G

207M

44G

账号服务 | 从库

43G

（*_center 文件占用空间过多）

1M

58M

积分服务 | 主库

1.5G

200M

11G

积分服务 | 从库

2.2G

20M

11G

游戏 | 主库

1.4G

1.8G

753M

游戏 | 从库

1.4G

115M

776M

微博业务   | 主库

2.0G

2.5G

674M

微博业务  | 从库

5.5G 

(ibdata2占略大)

8G

661M

3.硬件选型

总结以上对容量进行相加，可以算出单台机器600G容量就足够，但是考虑到以后几年的扩容情况，这里使用2T的空间，稍后会介绍到

最终，服务器选择了DELL R420；硬盘选择了Crucial M550 ，具体可以看其参数，价格就不要关注了：

 本文来自 http://yijiu.blog.51cto.com 盗贴 可耻

M550官方说明 http://www.edgememory.com/ssds.aspx

据说理论上iops能达到7w+  那么下面就来试试

二、一个坑：压力测试

1.压测工具选择

这里使用的是Fio，也可以是其他压测工具，因个人喜好而异

系统做好了，分别做了两个不同的RAID级别，一个是RAID1 一个是RAID0

在网上搜索了一通，看别人都这么做的，所以这里也跟着学了直接复制，可是网上的文章坑很多

不要模仿，之前就是直接复制

顺序写:

fio -name iops -rw=write -bs=4k -runtime=60 -iodepth 32 -filename /dev/sdb1 -ioengine libaio -direct=1

随机写:

fio -name iops -rw=randwrite -bs=4k -runtime=60 -iodepth 32 -filename /dev/sda1 -ioengine libaio -direct=1

随机读:

fio -name iops -rw=randread -bs=4k -runtime=60 -iodepth 32 -filename /dev/sda1 -ioengine libaio -direct=1

 本文来自 http://yi  jiu.bl og.51ct o.com 盗 贴 可耻

那么用fio来进行RAID0的压测，使用随机写的方式得出结果：

[root@localhost io_test]# fio -filename=/io_test/test -iodepth=64 -ioengine=libaio  -direct=1 -rw=randwrite -bs=4k -size=500G -numjobs=64 -runtime=20 -group_reporting -name=test-rand-writell

test-rand-writell: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64

...                                                   

fio-2.1.10

Starting 64 processes

test-rand-writell: Laying out IO file(s) (1 file(s) / 512000MB)

Jobs: 30 (f=30): [_wwww_w__www______ww___ww___ww_w__ww__ww_w_wwww_w_w_w______w__ww] [3.3% done] [0KB/70497KB/0KB /s] [0/17.7K/0 iops] [eta 11m:20s]           

test-rand-writell: (groupid=0, jobs=64): err= 0: pid=4305: Wed Apr  8 00:49:59 2015

  write: io=1452.2MB, bw=74239KB/s, iops=18559, runt= 20028msec

    slat (usec): min=15, max=80419, avg=3437.87, stdev=8530.70

    clat (msec): min=1, max=747, avg=216.14, stdev=107.04

     lat (msec): min=1, max=755, avg=219.57, stdev=108.24

    clat percentiles (msec):

     |  1.00th=[    6],  5.00th=[   30], 10.00th=[   69], 20.00th=[  126],

     | 30.00th=[  161], 40.00th=[  190], 50.00th=[  217], 60.00th=[  243],

     | 70.00th=[  269], 80.00th=[  306], 90.00th=[  355], 95.00th=[  396],

     | 99.00th=[  474], 99.50th=[  506], 99.90th=[  578], 99.95th=[  603],

     | 99.99th=[  693]

    bw (KB  /s): min=  115, max=38223, per=1.54%, avg=1141.21, stdev=1116.54

    lat (msec) : 2=0.55%, 4=0.11%, 10=1.68%, 20=1.63%, 50=3.58%

    lat (msec) : 100=7.34%, 250=47.92%, 500=36.62%, 750=0.58%

  cpu          : usr=0.24%, sys=1.88%, ctx=424437, majf=0, minf=1842

  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.3%, 32=0.6%, >=64=98.9%

     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

     issued    : total=r=0/w=371717/d=0, short=r=0/w=0/d=0

     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):

  WRITE: io=1452.2MB, aggrb=74239KB/s, minb=74239KB/s, maxb=74239KB/s, mint=20028msec, maxt=20028msec

Disk stats (read/write):

  sda: ios=0/371765, merge=0/13948, ticks=0/2776215, in_queue=2776513, util=99.24%

IOPS只有1.8W ，那么需要考虑的为啥只有1.8W 那么继续往下看

      本 文来 自 ht tp://y ijiu.bl og.51 cto .com 盗 贴可耻

2.压测工具命令各参数

上面涉及到了FIO，可是好多地方容易被忽略，那么下面就来解释一下之间的参数关系

涉及命令：

fio -filename=/io_test/test -iodepth=64 -ioengine=libaio  -direct=1 -rw=randwrite -bs=4k -size=500G -numjobs=64 -runtime=20 -group_reporting

涉及参数解释

Filename                测试文件名称，通常选择需要测试的盘的data目录。 

iodepth                 IO深度 

-ioengine=libaio        使用libaio模式

direct=1                测试过程绕过自身缓存

bs=4k                   单次io的块文件大小为4k

numjobs=64              本次的测试线程为64

那么知道各参数都是什么作用了，接下来就需要了解硬件各之间的关系了，知道之间怎么去调度的才可以明白压测的实际意义

三、缓存、深度及并发 

1.缓存

缓存就不解释了。之前听到好多人说压测的时候文件必须要大，其实是错误的，首先来看 -bs=4k,所以这里是在测试4k 的文件，而当时的内存是80G，通常只要测试到比 80G 多就可以体现出性能了，但是这里有一个direct=1的参数所在，那么我们不需要这么大的文件进行压测， 500G有点浪费磁盘寿命，在直接跳过缓存之后，80G 都是没有必要的了，但是有必要写入2G-10G 左右， RAID卡本身就有缓存的功能，所以，只需要大于这个缓存本身就行了，所以写入2G可以保证，已经开始越过 H710P 的cache。节约时间，节省使用寿命。

2.IO深度和并发

在这个测试里面 蛮重要的一个参数是 -iodepth 64

首先要确定 iodepth 应该走到多少，才会有一个合理的结果，要从 iodepth 到底是影响哪些层面去分析，CPU还是内存还是其他？

#接下来可以试着做一个 4 并发 和 一个 8并发的测试来查看结果，可以自行测试，不再放结果了

direct如果是影响 CPU 的话，那么应该是数字越小，CPU消耗越大。因为数字越小，CPU 要批量往硬盘发数据的次数就是越多，但是数字越大，积压的内存理论上应该越多

同时，硬盘一次能接收的数量总是有个极限的，所以应该是接近这个极限比较好，具体这么极限怎么计算，可能很难。可能要考虑到 CPU 内存，硬盘缓冲等一系列因素

知道以上的结论，接下来就不断调整深度和并发数进行测试就好了

四、RAID卡特性

采购阵列卡的时候必须了解其特性，在官方 Guide 文档里面 15 页有详细介绍

首先是SSD的产品介绍

http://www.edgememory.com/ssds.aspx

RAID阵列卡的产品介绍

http://www.dell.com/learn/us/en/04/campaigns/dell-raid-controllers?c=us&l=en&s=bsd&cs=04&redirect=1

明白之间的管理又查阅了老外的资料几个连接比较符合目前的情况

http://blog.xbyte.com/author/lyndsieezell/page/2/

有句话需要特别注意：

For 2 and 4 disk arrays, performance for 100% sequential I/O was improved by utilizing FastPath.

在2块和4块盘的阵列里面，配置 FastPath 会带来 IO 方面 100% 的性能提升

1、参考其他人的压测经验

这里不得不说一下，作者使用了RAID10来做压力测试，前期iops达到了2.6W，这里提到了 发现了H710P的FastPATH功能，专门为SSD的使用

前沿部分最后提到：

压测真实数据只有60% 随机，其他都为顺序压测

最后提到最主要的是需要明白使用什么样的IO调度方式，这里我理解为文件系统层面的io调度方式

  本 文来 自 htt p:/ /yiji  u.blog.51cto.com 盗贴 可耻

以下为RAID 5 和 RAID10的压测结果

RAID10的压测结果如下：

6块SSD做的RAID10可能会导致性能的下降，建议使用较少的磁盘数量比数量多的更佳

对于长期频繁读写，较大数量的RAID阵列（理解为4块以上为较大）；容量更小的SSD的可能更有意义（老外反复提到）

RAID 5 的压测结果

在压测中，总结：对于较大的阵列，在FastPATH工作中，FastPATH是否禁用后性能是否有影响，需要进行实际测试；因为它需要将一块磁盘拿出来做奇偶校验，所以可能会进行频繁的调度

但是如图上所显示，RAID 5 在后期可能会略有下降

 本文来 自 h ttp :/ /yijiu.blog .51c to.com 盗 贴~可耻

最后作者又提到，如果使用raid5做读写工作都非常频繁的场景下建议使用多块小硬盘

对于io负载较高的场景下，最好是使用容量大的SSD,以及数量较少的RAID的阵列；这里可以理解为4块盘之内的RAID阵列包括4块盘 

最后说明：在RAID 1/10和5使用SSD表现良好，但是出于实际考虑，需要确保是否符合当前的负载情况，不能盲目选型，不然可能无法达到预期的性能

第二篇文档也明确提到以上观点

http://www.cnblogs.com/ylqmf/archive/2013/02/28/2936895.html

在对RAID 0 的阵列上使用bs=4k 的随机读测试，只有128kb的效果比较明显，比之前提高了24%.与4kb的小小相比，单块盘的RAID 0 效率要高41%

文中提到未压缩的压测结果：

设置的CrystalDiskMark默认模式，主要用于不压缩数据

在没有压缩数据的顺序读写的测试中，顺序读最快的性能与更小的bs来实现，使用4k比 128k的性能高11% ,顺序写测试高于单块硬盘的283%的性能；

512kb压测对比

随机读写

最快的size 为8kb ，比单盘性能要高出 74% -- 88%

在随机测试中，所有szie大小的性能都差不多，但都远高于单块盘。

在测试RAID 0两个随机读取写测试中，不管多少size为4kb块没有任何优势

在顺序读写，以及在 512 kiB 块的随机测试，RAID 0的单块盘的性能比典型的RAID 0性能提高了80% - 324%

总结：

文中作者通过对比得出，size大小，大小其实不重要，只要高于本身缓存；如果场景是比较大文件的传输或者是需要大量压缩文件的场景，可以选择128kib的大小配置，如果不是，可以使用任意值； 因此，文章中又提到，不是采用了单块大容量的SSD，而是选择了两个小容量的ssd做为RAID 0 效果会更佳，（这里也提到了用容量小的SSD做RAID效果会更好）

而且以上的文章反复都提到了FASTPATH这个功能，那么下面将其功能开启再试试

五、设置FastPATH

1.FastPATH的作用

涉及资料：官方手册，如下所示

wKioL1VWphiCq-uGAAPxVCvOlOk549.jpg

我们知道了我们的RAID卡是支持FastPATH的功能的，那么接下来要设置FastPATH功能

 本文来 自 ht~t p://yi~ji~u.bl~og.51~cto.co~m ~盗贴 可耻

2.开启FastPATH

FastPATH 默认为开启状态；主要作用为直接写入缓存和不进行预读操作

 Fastpath I/O (H710P and H810 only)

Fastpath I/O is a method of increasing Input/Output Operations per Second (IOPS) by using the 2nd core of the PERC (Gemini core) to directly execute I/O and completely bypass caching.

Fastpath I/O is most beneficial for SSD disks.

Fastpath I/O is not available on H710 controller, only available on H710P and H810 controllers.

Fastpath I/O is automatically available on eligible VDs.

Fastpath eligible VDs should have the following properties:

Write-Through

No Read Ahead

No Background Operation (e.g. Background Initialization, Patrol Read or Consistency Check ) in progress.

 服务器重启，ctrl+r进阵列卡中选择对应的VD，然后按enter键查看write policy 和read policy 并设置以上选项

先别着急配置，这里有涉及到两个知识点：

Write-Through          #设置为直接写

No Read Ahead          #设置为非预读  

 本文来自 http://y ~iji~u.bl  og.51cto.com 盗贴可耻

3.回写、直写和预读、非预读

关于write back 和Write Through

默认为回写的方式，对于某些数据模式和配置，直写会获得更好的性能

回写、Write Back    

主要利用阵列卡的内存，进行缓存，然后sync到磁盘

直写、Write Through  

主要是将传递的数据不通过raid阵列卡的缓存，直接写入到磁盘中，关闭写缓存，可释放缓存用于读操作

预读：

在没有系统的IO请求的时候事先将数据从磁盘中读入到缓存中，然后在系统发出读IO请求的时候，就会实现去检查看看缓存里面是否存在要读取的数据，如果存在(即命中)的话就直接将结果返回

如果禁用非预读的话，则直接去硬盘中读取数据

那么明白以上两点，设置RAID如下图所示：

 wKiom1VWpMCRLcB5ABazITi4MzU685.jpg

 本文来 自 ht~t p://yi~ji~u.bl~og.51~cto.co~m ~盗贴 可耻

六、埋坑：还是压力测试

了解了上面所有的知识点及之间的调度关系，接下来再进行压力测试，但是有个地方很担心，当发压力的时候，是否磁盘还没走到顶，CPU 已经走到顶了。这里借助了zabbix进行对系统进行监控 将出更新设置为1秒一次，因为只有2台机器

wKioL1VWpl2g1STmAAUaUCZV-WA031.jpg

  本文来   自  ht~t p://yi~ji~u. bl~og .51~cto.co~m ~盗贴 可耻

进行64 iodepth 的随机写和顺序写，结果如下：

进行了4个线程，随机写分别都是5200，4线程以4kb的写入，那就是一共 28k

平均下来 随机读的iops，68000左右。那么与官方手册上说明的是一致了

压测结果统计

读/写

IOPS

随机写

5200

顺序写

18512

随机读

68000

以上只对RAID1进行说明，具体怎样还需要实际去测试

七、RAID选型

经过上面对FastPATH的了解，接下来选择合适的RAID类型

1.FastPATH特性及生效范围

官方手册15页明确说明,对于以下生效的行为都有标注，如下所示

wKiom1VWpQXg26DqAAPGBG6lrPU801.jpg

就是说，以目前的状态来看，只有RAID5和RAID1两者可以选择了

2.选型

以上，还在纠结于RAID1还是RAID5

持FastPATH，跟RAID1一样只对读有性能的提高，但是RAID5会用其中一块盘做奇偶校验，如果是读的话应该没有影响，但是写的话可能不如RAID1 ，因为之前看那两篇压测的文章上明确说明会有一层调度算法进行奇偶校验。所以目前比较好的就是RAID1了

最终选择了RAID1，服务器上为4块硬盘，分别做了2个RAID1

本 文来 自 ht~t p://yi~ji~u.bl~og.51~ct~o.co~m ~盗贴 可耻

八、寿命问题

以RAID5的角度来说，SSD 的寿命受限于写的次数。RAID 每次都会多写一份，但是 RAID 1 也会。

我们的硬盘是 M550，质保是3年。现在的页面我已经找不到 M550 的写入寿命了，之前有篇文档说这款硬盘的寿命应该是 120万次

假设我们做 RAID 5 ，于是寿命减半（不确定是否会减半，但是肯定会减少），那就是 60万次。

现在目前960G 的硬盘，假设我们有 900G 作为数据存储空间。60 万次 也就是 514 EB 的总写入量，平分到到三年质保期，每一天要写入 大约 481 TB（应该没算错）的量这个硬盘才会坏。所以寿命问题应该不是我们担心的了。

©著作权归作者所有：来自51CTO博客作者zuzhou的原创作品，谢绝转载，否则将追究法律责任

mysql优化压力测试数据库相关