Home  >  Article  >  Database  >  MySQL基础建设之硬盘篇

MySQL基础建设之硬盘篇

WBOY
WBOYOriginal
2016-06-07 14:56:011288browse

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

涉及资料:官方手册,如下所示

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 Inpu

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn