首頁 > 資料庫 > mysql教程 > MySQL基础建设之硬盘篇

MySQL基础建设之硬盘篇

WBOY
發布: 2016-06-07 14:56:01
原創
1312 人瀏覽過

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

相關標籤:
來源:php.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板