MySQL基础建设之硬盘篇-tutorial mysql-php.cn

MySQL 基础建设之硬盘篇随着业务的不断增长，之前的环境越来越乱，由此欲重建整个MySQL数据库基础环境主要目的是要考虑数据冗余、性能、平衡目的是让机器的性能最大的发挥，同时比较好维护一、硬件选型 1. 节点统计目前已将各库进行分隔，但由于每台机

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的作用

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