ioping

一个实时显示磁盘io延时的工具,以类似ping 的输出一样展示输出结果

常用参数:

-c count
stop after count requests.
-i interval
Set time between requests to interval(Default 1s).
-l 速度
default size(-s size)/speed = interval(-i)
如果size=4k 如果要实现80iops则-l 320k
-L 顺序,同时每次操作块大小会变成256k.(即-s 256k)
-D Derect IO
-s size
指定请求数据块的大小(默认:4k)
4k时那么平均每次读写的扇区就是8个
-S wsize
指定工作路径的大小,如果不指定,默认是1m的,也就是io会只在这个1m的块上执行,指定该参数执行ioping会先创建一个指定大小的块文件,再开始读写。
-W 写io。会从0磁道开始写,要与-WWW一起使用。
-G 混合读写
-k 在使用目录做测试时,保留ioping.tmp(-S 创建的文件,默认会完成测试后自动删除)。
-Y sync IO

把要测试的盘挂载到一个目录比如/test,cd /test开始测试

测试4k随机写(写测试必须使用目录或者文件)

ioping -W -WWW -S 1G -D -c 100 .

测试顺序读(读可以测试设备)

ioping -L -D -S 1G -c 100 .

以下是man page方法:

简单用法:

使用默认值和当前目录显示磁盘I / O延迟,直到被中断

[root@node-1 ops]# ioping -D /dev/sda
4 KiB <<< /dev/sda (block device 557.9 GiB): request=1 time=56.1 ms (warmup)
4 KiB <<< /dev/sda (block device 557.9 GiB): request=2 time=8.89 ms
4 KiB <<< /dev/sda (block device 557.9 GiB): request=3 time=9.45 ms
4 KiB <<< /dev/sda (block device 557.9 GiB): request=4 time=5.37 ms
4 KiB <<< /dev/sda (block device 557.9 GiB): request=5 time=5.34 ms
4 KiB <<< /dev/sda (block device 557.9 GiB): request=6 time=7.24 ms
4 KiB <<< /dev/sda (block device 557.9 GiB): request=7 time=2.62 ms (fast)
4 KiB <<< /dev/sda (block device 557.9 GiB): request=8 time=8.16 ms
4 KiB <<< /dev/sda (block device 557.9 GiB): request=9 time=10.2 ms (slow)
4 KiB <<< /dev/sda (block device 557.9 GiB): request=10 time=7.02 ms
^C
--- /dev/sda (block device 557.9 GiB) ioping statistics ---
9 requests completed in 64.3 ms, 36 KiB read, 140 iops, 560.3 KiB/s
generated 10 requests in 9.11 s, 40 KiB, 1 iops, 4.39 KiB/s
min/avg/max/mdev = 2.62 ms / 7.14 ms / 10.2 ms / 2.24 ms

测量磁盘搜索率(iops,avg)

$ ioping -R /dev/sda

--- /dev/sda (device 465.8 GiB) ioping statistics ---
186 requests completed in 3004.6 ms, 62 iops, 0.2 MiB/s
min/avg/max/mdev = 6.4/16.0/26.8/4.7 ms

测量磁盘顺序速度(MiB / s)

$ ioping -RL /dev/sda

--- /dev/sda (device 465.8 GiB) ioping statistics ---
837 requests completed in 3004.1 ms, 292 iops, 72.9 MiB/s
min/avg/max/mdev = 2.0/3.4/28.9/2.0 ms

获取磁盘每秒顺序速度(bytes)

[root@node-1 ops]# ioping -RLB . | awk '{printf "%s MB\n",$4/1024/1024}'
1129.74 MB

raw 统计

ioping -p 100 -c 200 -i 0 -q .
100 26694 3746 15344272 188 267 1923 228 100 26694
100 24165 4138 16950134 190 242 2348 214 100 24165
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (1) 请求次数统计
(2) 运行时间 (usec)
(3) 每秒的请求次数 (iops)
(4) 传输速度 (bytes/sec)
(5) 最低的请求时长 (usec)
(6) 平均请求时长 (usec)
(7) 最大的请求时长 (usec)
(8) request time standard deviation (usec)
(9) 总的请求数 (including too slow and too fast)
(10) 总的运行时长 (usec)

名词解释

tps: 每秒接收的I/O请求数,等于r/s + w/s

avgrq-sz: 平均每次io请求扇区数

avgqu-sz: 平均每次io等待队列数

maxsect: max sectors per request

​ 通过blockdev --getmaxsect /dev/sdx获取,sas默认值512,sata默认值128

sector: 扇区,每个扇区512Bytes,1k=2sect

iops: 每秒的io次数

此次测试使用的硬盘为sas 10k, iops为140, 平均io time/per为14ms

写测试实例

同步IO写

测试一:

ioping -DWWW -S 1G -s 4k -l 560k .
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb4 0.00 0.00 0.00 140.00 0.00 0.55 8.00 0.02 0.15 0.00 0.15 0.15 2.10

扇区达到8之后,tps、avgrq、avgqu和await符合预期

测试二:

测试命令:
ioping -DWWW -S 1g -s 256k -l 35m .
04/20/2019 03:07:59 PM
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb4 0.00 0.00 0.00 140.00 0.00 35.00 512.00 0.03 0.20 0.00 0.20 0.20 2.80

Note:

扇区达到512后,符合预期

size为256k时,刚好avgrq为512个sector;

此时tps = 35m / 256k = 140 , 与测试结果w/s相符,也于10k sas盘的iops参数相符;

观察此时avgqu为0.04,几乎没有队列等待, iops = 140 / (1 + 0.04) = 134;

w_wait: 0.29;

且util值为4%,接近0;

可以认为此时是硬盘的最佳io处理状态,可以作为基准状态;

测试三:

ioping -DWWW -S 1g -s 256k -l 70m .
正常的盘:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb4 0.00 0.00 0.00 280.00 0.00 70.00 512.00 0.05 0.18 0.00 0.18 0.17 4.80
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc1 0.00 0.00 0.00 153.00 0.00 38.25 512.00 0.95 6.21 0.00 6.21 6.19 94.70

Note:

稳定后,wMB/s和avgrq达到参数值后,也符合预期,此时如果wMB达不到参数值的话就会增加util,并tps也会达不到预期。

正常的盘和异常的盘在这个压力下,已经显现了差距

size不变,增加数据量及加快给数据的速度,speed为70m,此时util开始接近100%;

此时计算tps = 70m / 256 k = 280 ,与实际测出结果有一定差距,

但是此时avgqu-sz已经达到0.95,接近1,

根据avgqu,计算iops ≈ 280 / (1 + 0.95) = 143 接近153;

w_wait: 6.21有所增加,但是依然符合io time;

再增加speed,后实际结果也没有大的变化,只增加这个值此时已经没有测试效果;

测试四:

增加size
测试命令:
ioping -DWWW -S 1g -s 512k -l 35m .
iostat输出:
正常的盘:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb4 0.00 0.00 0.00 140.00 0.00 35.00 512.00 0.02 0.16 0.00 0.16 0.09 1.20
异常的盘
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdc1 0.00 0.00 0.00 140.00 0.00 35.00 512.00 0.06 0.42 0.00 0.42 0.24 3.40

Note:

wMB/s和avgrq达到参数值后,符合预期

低压力的情况下,正常的盘和异常的盘区别不大

size为512k=1024sector,为测试一的两倍,也就是每次request都要分成两次完成,因为每次是512个sector;

计算tps = 35m / 512k = 70 , 但是结果是140, 结合size,那么新的tps计算方法就应该是: tps = speed / size × (size_k *2 /maxsect)

tps = 35 * 1024 / 512 * (512 * 2 / 512) = 140

avgqu-sz: 0.06

w_wait: 0.42;

数据总量不变的情况下,增加request的size,会增加tps,并保持io处理能力不下降。

测试五:

ioping -DWWW -S 1g -s 512k -l 70m .
正常的盘:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb4 0.00 0.00 0.00 280.00 0.00 70.00 512.00 0.05 0.17 0.00 0.17 0.11 3.00
异常的盘:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdc1 0.00 0.00 0.00 220.00 0.00 55.00 512.00 1.44 6.52 0.00 6.52 4.15 91.20

Note:

正常的盘在wMB/s avgrq达到参数值后符合预期,如果达不到参数值则会出现iops降低,util增加和avgqu增加,以及await增加

异常的盘已经基本上达不到参数值了

size: 512k

计算tps: 70 * 1024 / 512 * 2 = 280, 与实际测试的值略有差距;

avgqu: 1.44 , 根据avgqu 没有avgqu时的tps = 280 / (1 + 1.44) = 114;

此时w_wait: 6.52,处于合理状态的范围;

测试六:

ioping -DWWW  -S 1g -s 5m -l 150m .
正常的盘:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb4 0.00 0.00 0.00 600.00 0.00 150.00 512.00 1.07 1.79 0.00 1.79 0.14 8.30
异常的盘:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdc1 0.00 0.00 0.00 460.00 0.00 115.00 512.00 9.31 20.33 0.00 20.33 1.99 91.60

Note:

此时正常的盘,达到参数值后,依然符合预期,而异常的盘已经远远达不到了。

size: 5m

计算tps: 150 / 50 * (5 * 1024 * 2 / 512) = 600

由于有avgqu值偏大,此时已经不具有生产使用意义

测试名称 size speed 测试tps 计算tps avgqu-sz wait util MB/s
256k 35m 140 140 0.04 0.29 4% 35
256k 70m 153 280 0.95 6.21 94.7% 38.25
512k 35m 140 140 0.06 0.42 3.4% 35
512k 70m 220 280 1.44 6.52 91.2% 55
5m 150m 460 600 9.31 20.33 91.6% 115

当size为256k时 avgrq-sz就已经等于maxsect,此时增加-l speed的值并不能提升iops了,只能增加-s的size,

而增加size必然会带来增加avgqu-sz即等待队列,也就会导致wait上升.

10k的sas的iops为140,此时140256k = 140/4m = 35m 此时-l 35m,基本上就是硬盘最高繁忙度了util接近100%,此时要降低util,就必须增加-s的size(增加了等待的队列,也可以理解是增加了io通道或者iodepth), 比如size=512k,此时util降低一半,tps=35m/0.5m2 =140

io供给速度快时,util增加的情况下,tps就达不到计算的结果。

读测试实例

ioping -D -S 100g -s 4m -l 160m /dev/sdc1
iostat输出
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdc1 0.00 0.00 486.00 0.00 121.50 0.00 512.00 9.66 19.78 19.78 0.00 2.04 99.30
此时看wait开始增加到较高的值了,且avgqu-sz已经很高了。

磁盘测试可以根据计算的方式获取预期的瓶颈范围

avgqu-sz开始接近1的时候就是盘的性能最佳状态。

即最佳状态为-s 256k -l 35m此时tps 140 util接近100%

磁盘在等待队列avgqu-sz <= 4的情况下处于较好的状态,最终获取最大承受范围约 -s 1.5m -l 150m,此时承载能里达到最大承载临界值。(队列avgqu-sz每增加1几乎tps就增加一倍)

04/19/2019 12:03:34 AM
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdc1 0.00 0.00 388.00 0.00 97.00 0.00 512.00 4.32 11.20 11.20 0.00 2.56 99.50 04/19/2019 12:03:35 AM
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdc1 0.00 0.00 370.00 0.00 92.50 0.00 512.00 4.37 11.83 11.83 0.00 2.68 99.10

异步IO 写

测试一:

ioping -ADWWW -S 1g -s 4k -l 560k .
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb4 0.00 0.00 0.00 140.00 0.00 0.55 8.00 0.00 0.01 0.00 0.01 0.01 0.20

wMB/s和 avgrq达到预期后,其他的输出都符合预期

ioping -AD -W -WWW -S 1G -s 256k -l 35m .
04/20/2019 02:42:57 PM
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb4 0.00 0.00 0.00 140.00 0.00 35.00 512.00 0.02 0.16 0.00 0.16 0.16 2.20

符合预期

ioping -AD -W -WWW -S 1G -s 256k -l 70m .
04/20/2019 02:46:11 PM
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb4 0.00 0.00 0.00 280.00 0.00 70.00 512.00 0.05 0.17 0.00 0.17 0.17 4.90

开始阶段avgrq只能到达256,此时iops为500左右

异步io的util不高

ioping -AD -W -WWW -S 1G -s 512k -l 35m .
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb4 0.00 0.00 0.00 140.00 0.00 35.00 512.00 0.03 0.21 0.00 0.21 0.11 1.60

表现与sync io一样,此时iops一致

ioping -AD -W -WWW -S 1G -s 512k -l 70m .
04/20/2019 02:50:49 PM
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb4 0.00 0.00 0.00 280.00 0.00 70.00 512.00 0.07 0.26 0.00 0.26 0.14 3.90

符合预期

ioping -AD -W -WWW -S 1G -s 512k -l 140m .

04/20/2019 02:52:43 PM
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb4 0.00 0.00 0.00 542.00 0.00 135.50 512.00 0.21 0.39 0.00 0.39 0.24 12.80 04/20/2019 02:52:44 PM
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb4 0.00 0.00 0.00 440.00 0.00 110.00 512.00 0.85 1.93 0.00 1.93 1.43 62.80

数据量增大后,tps就很难稳定了

ioping -AD -W -WWW -S 1G -s 2m -l 140m .
04/20/2019 02:54:11 PM
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb4 0.00 3.00 0.00 623.00 0.00 140.20 460.88 0.44 0.70 0.00 0.70 0.12 7.50
ioping -AD -W -WWW -S 1G -s 5m -l 140m .
04/20/2019 02:55:19 PM
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb4 0.00 0.00 0.00 540.00 0.00 135.00 512.00 2.54 4.71 0.00 4.71 0.29 15.40
异步IO读

ioping测试的更多相关文章

  1. IO测试工具 - 用于IO测试 ; linux benchmarks

    IO测试工具,用于磁盘IO测试,下面进行使用列表进行记录: iozone fio dd ioping iotop iostat bonnie++ crystalDisk Atto as-ssd-ben ...

  2. SignalR系列续集[系列8:SignalR的性能监测与服务器的负载测试]

    目录 SignalR系列目录 前言 也是好久没写博客了,近期确实很忙,嗯..几个项目..头要炸..今天忙里偷闲.继续我们的小系列.. 先谢谢大家的支持.. 我们来聊聊SignalR的性能监测与服务器的 ...

  3. Apache Ignite之集群应用测试

    集群发现机制 在Ignite中的集群号称是无中心的,而且支持命令行启动和嵌入应用启动,所以按理说很简单.而且集群有自动发现机制感觉对于懒人开发来说太好了,抱着试一试的心态测试一下吧. 在Apache ...

  4. 测试一下StringBuffer和StringBuilder及字面常量拼接三种字符串的效率

    之前一篇里写过字符串常用类的三种方式<java中的字符串相关知识整理>,只不过这个只是分析并不知道他们之间会有多大的区别,或者所谓的StringBuffer能提升多少拼接效率呢?为此写个简 ...

  5. TechEmpower 13轮测试中的ASP.NET Core性能测试

    应用性能直接影响到托管服务的成本,因此公司在开发应用时需要格外注意应用所使用的Web框架,初创公司尤其如此.此外,糟糕的应用性能也会影响到用户体验,甚至会因此受到相关搜索引擎的降级处罚.在选择框架时, ...

  6. .NET Core系列 :4 测试

    2016.6.27 微软已经正式发布了.NET Core 1.0 RTM,但是工具链还是预览版,同样的大量的开源测试库也都是至少发布了Alpha测试版支持.NET Core, 这篇文章 The Sta ...

  7. 渗透测试工具BurpSuite做网站的安全测试(基础版)

    渗透测试工具BurpSuite做网站的安全测试(基础版) 版权声明:本文为博主原创文章,未经博主允许不得转载. 学习网址: https://t0data.gitbooks.io/burpsuite/c ...

  8. 在ubuntu16.10 PHP测试连接MySQL中出现Call to undefined function: mysql_connect()

    1.问题: 测试php7.0 链接mysql数据库的时候发生错误: Fatal error: Uncaught Error: Call to undefined function mysqli_con ...

  9. 【初学python】使用python调用monkey测试

    目前公司主要开发安卓平台的APP,平时测试经常需要使用monkey测试,所以尝试了下用python调用monkey,代码如下: import os apk = {'j': 'com.***.test1 ...

随机推荐

  1. centos源码安装mysql5.7

    http://blog.csdn.net/langzi7758521/article/details/51435985

  2. 日志备份shell脚本

    脚本注释已经很清楚了,就不再啰嗦了. 算了,还是多说一句吧,脚本设计完成之后,就可以加入计划任务,让电脑帮你打工了. 注:关于计划任务crontab,我会专门写一篇笔记. 最最最后一句, find $ ...

  3. linux 系统函数 basename和dirname

    在linux系统中有这样两个系统函数,basename 和  dirname 1.basename 用于 获取文件名, 1.1 当给定扩展名作为参数之后,甚至可以直接获取文件名 2.与basename ...

  4. 【图像处理】DVR H.264视频编码基本知识

    视频编码技术基本是由ISO/IEC制定的MPEG-x和ITU-T制定的H.26x两大系列视频编码国际标准的推出.从H.261视频编码建议,到 H.262/3.MPEG-1/2/4等都有一个共同的不断追 ...

  5. C学习笔记-gdb

    gdb即GNU debugger,用来调试程序 gdb使用前提 要使用gdb,则需要在编译源代码时候使用-g参数 gcc -g –o test test.c 启动gdb gdb 程序名 [corefi ...

  6. Guava源码阅读-io-Files

    package com.google.common.io; 今天阅读一个非常常用的类Files,文件操作类. readLines(File file, Charset charset),这个方法将Fi ...

  7. 使用Docker Maven 插件进行镜像的创建以及上传至私服

    1.在进行服务容器化部署的时候,需要将服务以及其运行的环境整个打包做成一个镜像,打包的过程有两种办法,第一种是首选通过maven打成jar包,然后再编写dockerfile,执行docker buil ...

  8. 什么是负载均衡SLB

    负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务.负载均衡可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性. 请看视频简介 ...

  9. Python—格式化输出

    Python提供了很多种格式化方式(包括但不限于以下几种): [,]分隔 name = 'jack' age = -0.5 print(name, 'is', age, 'years old.') j ...

  10. Docker-PS命令解析

    查看 docker 容器,必然要用到 docker ps 命令.其基本格式为: docker ps [OPTIONS] 关键在于 OPTIONS(选项): 1 常见用法 1. 最常见的用法 $ doc ...