纵有疾风起
人生不言弃

SQL Server 服务器磁盘测试之SQLIO篇(二)

         上次放出了一篇文章,针对磁盘卷簇大小默认4KB和自定义64KB进行了测试,测试内容为随机和顺序读写,大小为8KB和64KB,有人觉得这并没有照顾到SQL Server所有的IO使用情景。这篇测试文章,我们就来尽可能模拟一下SQL Server IO的行为,全方位对簇大小4KB、8KB和64KB做一次验证,注意:本次我们增加了簇为8KB的大小。

重点说明:本测试使用的是两块SSD组成的RAID1

首先,我们先来分析SQL Server的IO行为,参考网址:Choosing what SQLIO tests to Run and Automating the Tests

下面的几点是我根据文章整理,并非完全翻译:

1、SQL Server每个逻辑CPU上都会分配一个调度器,每个调度器上根据系统负载不同,会有多个Worker Thread,但是在同一个时刻,每个调度器上只能有一个Worker Thread处于运行状态,即:每个逻辑CPU在同一时刻只能支配一个Worker Thread干活。也就是说:SQLIO Param.txt 文件中定义的testfile.dat 8 0×0 5000 不能超过测试服务器逻辑CPU的数目,我测试的服务器为:2物理CPU*6核心*双线程=24逻辑CPU,即最大设置为:testfile.dat 24 0×0 5000

2、SQL Server间歇性的写入数据,写数据的行为由CheckPoint或者Lazy Writer(当内存有压力的时候)完成。当二者触发执行时,由单一的线程将内存中的脏页写入磁盘,因此当测试“写”的时候,在Param.txt 中配置超过1个线程都是毫无意义的,因为这种行为在即使多个数据库时也是串行的,(当然你可以配置线程数为2来压榨出IO写能力的极限)。并且,SQL Server在写入数据的时候,大部分情况下一次性写入32个page即256K的数据,因此你应该配置写入的Size为256K。但是也有例外,那就是Eager Writer,该行为在将数据库恢复模式设置为“大容量日志模式”时,最小化记录日志时将触发,该行为的写入Size为8KB(或者可能是64KB)。

3、SQL Server连续不断的进行数据读取操作,绝大多数的读操作是8KB为单位的,预读的块大小是64个page即512KB,直接读取整个区Extent即64KB也是较为常见的,因此对于读操作,测试8KB、64KB、512KB就可以了。

4、对于日志写,定一个测试Size是非常困难的,因为写入日志的大小取决于系统的负荷大小,但是一般不会超过60KB,但是对于测试,“我”建议使用8KB作为测试单位,这个大小覆盖了Eager Writer和Log Writer。在微软亚太博客的这篇文章中:SQL server每个日志写(log write)究竟有多大?,我们也可以了解到,SQL Server的日志写确实很不固定,一个简单的commit是512byte,而负荷较高时,接近60KB,在这里,我决定擅自再使用一个接近512byte的1KB作为测试大小,并且实际上,我用ProcessMonitor在生产环境抓取了一段时间Log Writer后,绝大多数的日志写确实在1K以下。

QQ图片20140423115548

5、作者的第5条认为SAN存储,由于有巨大的缓存,并且优化了读写机制,所以读写的差距不是很大,所以建议只使用Random作为测试方式,这一点,我决定不苟同于作者,仍然按照Data和Log的读写特性来进行测试,随机和顺序都会照顾到。

综上所述,根据个人知识点,测试要点总结如下:

QQ截图20140422162044

1、我们首先建立两个Para.txt文件,一个Thread为逻辑CPU数目24,另外一个Thread我们设置为1,对应于上图中“使用线程数”中的内容,另外,我还将测试文件testfile.dat的大小调整为了5000M。

本次我为了避免误差,仅使用同一组RAID1来完成这三组簇分别为4KB/8KB/64KB大小的测试。

ParamMT.txt

D:\testfile.dat 24 0x0 5000

ParamST.txt

D:\testfile.dat 1 0x0 5000

2、以下为测试脚本,我们将-o参数从1开始增加,然后以翻倍的形式,测试出IO的最大能力。

在进行下一组测试前,我们只需要将后面的写入文件Cluster_4KB_test中的4KB全部替换为8KB或者64KB即可。
echo ****** Read Tests *****

echo ******random_R_8KB**********
sqlio -kR -s300 -frandom -o1 -b8 -LS -BH -FparamMT.txt > Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o2 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o4 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o8 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o16 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5


echo ******random_R_64KB**********
sqlio -kR -s300 -frandom -o1 -b64 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o2 -b64 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o4 -b64 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o8 -b64 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o16 -b64 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5



echo ******random_R_512KB**********
sqlio -kR -s300 -frandom -o1 -b512 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o2 -b512 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o4 -b512 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o8 -b512 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o16 -b512 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5



echo ******random_W_8KB**********
sqlio -kW -s300 -frandom -o1 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o2 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o4 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o8 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o16 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5



echo ******random_W_256KB**********
sqlio -kW -s300 -frandom -o1 -b256 -LS -BH -FparamST.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o2 -b256 -LS -BH -FparamST.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o4 -b256 -LS -BH -FparamST.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o8 -b256 -LS -BH -FparamST.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o16 -b256 -LS -BH -FparamST.txt >> Cluster_4KB_test.txt
timeout /T 5



echo ******sequential_W_1KB**********
sqlio -kW -s300 -fsequential -o1 -b1 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o2 -b1 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o4 -b1 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o8 -b1 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o16 -b1 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5



echo ******sequential_W_8KB**********
sqlio -kW -s300 -fsequential -o1 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o2 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o4 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o8 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o16 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5

 
3、在进行了漫长的等待后,我们终于拿齐了三个文件,用SqlioAnalyzer导出为文件,值得注意的是,导入txt文件时,报错,只需要将”1 thread”全部替换为”1 threads”,再次导入即可。
4、整理,取出每组测试最大值,所得结果如下。
看到结果,我惊呆了,在尽可能模拟SQLServer IO行为的前提下,我们这组SSD组成的Raid1不再是簇为64KB时性能全面领先!
  • 先说第个直方图,我们可以看到,在顺序写时,三种簇大小下几乎是没有差别的;
  • 个直方图,在随机读取64KB和512KB时,簇为4KB相比其它两种情况是有优势的;其它读写情况下,还是簇为8KB和64KB时占据优势。
  • 我们上面已经说过,SQL Server的随机读,绝大多数还是以8KB为单位的,从这点来看,依然还是簇为8KB和64KB比簇为4KB在全局来讲,要占据优势,而簇为64KB比8KB的优势,是微乎其微的。
2014-04-29_122339
然后根据需要比较的项做成直方图,随机看IOS/sec,顺序看MB/sec。
QQ截图20140429121832
QQ截图20140429121903
 

测试总结:

在尽可能模拟SQL Server IO行为的前提下,我们测试的两块SSD硬盘组成的RAID1表现出了与第一篇测试文章时不同的性能行为。

SSD的特性是不再以物理寻道的形式获取数据,而是电子存储芯片颗粒直接读写,再也没有磁头移动消耗的时间,并且,SSD硬盘的并发读写能力是建立在多线程之上的,在同一时刻的工作绝不会局限于一个颗粒之上,本例我们测试的最大线程为24(测试服务器逻辑CPU数目),也许这是制约这组SSD硬盘没有发挥出最大功效的原因吧。即使这样,我们仍然可以察觉出簇为64KB比4KB时是有优势的。

如果您有不同意见,请提出,我们继续讨论。

手头上没有SAS硬盘的RAID,如果您有兴趣,可以试一下,差别应该会更大一些。

 

文章转载于:https://www.cnblogs.com/zc_0101/p/3698974.html

原著是一个有趣的人,若有侵权,请通知删除

未经允许不得转载:起风网 » SQL Server 服务器磁盘测试之SQLIO篇(二)

分享到: 生成海报
avatar

评论 抢沙发

评论前必须登录!

立即登录   注册

切换注册

登录

忘记密码 ?

切换登录

注册

我们将发送一封验证邮件至你的邮箱, 请正确填写以完成账号注册和激活