请选择 进入手机版 | 继续访问电脑版

[LINUX] 容易 被误读的iostat(Linux体系 )

[复制链接]
查看48 | 回复3 | 2021-9-5 02:19:47 | 显示全部楼层 |阅读模式

iostat重要 用于报告中心 处理器(CPU)统计信息和整个体系 、适配器、tty 装备 、磁盘和 CD-ROM 的输入/输出统计信息,下面小编就为大家具体 的讲解Linux体系 中容易 被误读的IOSTAT。

iostat(1)是在Linux体系 上查看I/O性能最基本的工具,然而对于那些认识 别的 UNIX体系 的人来说它是很容易 被误读的。比如在HP-UX上 avserv(相称 于Linux上的 svctm)是最紧张 的I/O指标,反映了硬盘装备 的性能,它是指I/O哀求 从SCSI层发出、到I/O完成之后返回SCSI层所斲丧 的时间,不包括在SCSI队列中的等待时间,以是 avserv表现 了硬盘装备 处理I/O的速率 ,又被称为disk service time,假如 avserv很大,那么肯定是硬件出标题 了。然而Linux上svctm的含义大相径庭 ,究竟 上在iostat(1)和sar(1)的man page上都说了不要信任 svctm,该指标将被废弃:

“Warning! Do not trust this field any more. This field will be removed in a future sysstat version.”

在Linux上,每个I/O的匀称 耗时是用await表示的,但它不能反映硬盘装备 的性能,由于 await不仅包括硬盘装备 处理I/O的时间,还包括了在队列中等待的时间。I/O哀求 在队列中的时间 尚未发送给硬盘装备 ,即队列中的等待时间不是硬盘装备 斲丧 的,以是 说await表现 不了硬盘装备 的速率 ,内核的标题 比如I/O调度器什么的也有大概 导致await变大。那么有没有哪个指标可以衡量硬盘装备 的性能呢?非常遗憾的是,iostat(1)和sar(1)都没有,这是由于 它们所依靠 的/proc/diskstats不提供这项数据。要真正明白 iostat的输出结果 ,应该从明白 /proc/diskstats开始。

  1. # cat /proc/diskstats
  2. 8 0 sda 239219 1806 37281259 2513275 904326 88832 50268824 26816609 0 4753060 29329105
  3. 8 1 sda1 338 0 53241 6959 154 0 5496 3724 0 6337 10683
  4. 8 2 sda2 238695 1797 37226458 2504489 620322 88832 50263328 25266599 0 3297988 27770221
  5. 8 16 sdb 1009117 481 1011773 127319 0 0 0 0 0 126604 126604
  6. 8 17 sdb1 1008792 480 1010929 127078 0 0 0 0 0 126363 126363
  7. 253 0 dm-0 1005 0 8040 15137 30146 0 241168 2490230 0 30911 2505369
  8. 253 1 dm-1 192791 0 35500457 2376087 359162 0 44095600 22949466 0 2312433 25325563
  9. 253 2 dm-2 47132 0 1717329 183565 496207 0 5926560 7348763 0 2517753 7532688
复制代码

/proc/diskstats有11个字段,以下内核文档表明 了它们的含义https://www.kernel.org/doc/Documentation/iostats.txt,我重新表述了一下,留意 除了字段#9之外都是累计值,从体系 启动之后不停 累加:

(rd_ios)读操作的次数。(rd_merges)合并读操作的次数。假如 两个读操作读取相邻的数据块时,可以被合并成一个,以进步 服从 。合并的操作通常是I/O scheduler(也叫elevator)负责的。(rd_sectors)读取的扇区数目 。(rd_ticks)读操作斲丧 的时间(以毫秒为单位)。每个读操作从__make_request()开始计时,到end_that_request_last()为止,包括了在队列中等待的时间。(wr_ios)写操作的次数。(wr_merges)合并写操作的次数。(wr_sectors)写入的扇区数目 。(wr_ticks)写操作斲丧 的时间(以毫秒为单位)。(in_flight)当前未完成的I/O数目 。在I/O哀求 进入队列时该值加1,在I/O竣事 时该值减1。

留意 :是I/O哀求 进入队列时,而不是提交给硬盘装备 时。(io_ticks)该装备 用于处理I/O的天然 时间(wall-clock time)。

请留意 io_ticks与rd_ticks(字段#4)和wr_ticks(字段#8)的区别,rd_ticks和wr_ticks是把每一个I/O所斲丧 的时间累加在一起,由于 硬盘装备 通常可以并行处理多个I/O,以是 rd_ticks和wr_ticks每每 会比天然 时间大。而io_ticks表示该装备 有I/O(即非空闲)的时间,不思量 I/O有多少,只思量 有没有。在现实 计算时,字段#9(in_flight)不为零的时间 io_ticks保持计时,字段#9(in_flight)为零的时间 io_ticks制止 计时。(time_in_queue)对字段#10(io_ticks)的加权值。字段#10(io_ticks)是天然 时间,不思量 当前有几个I/O,而time_in_queue是用当前的I/O数目 (即字段#9 in-flight)乘以天然 时间。固然 该字段的名称是time_in_queue,但并不真的只是在队列中的时间,此中 还包含了硬盘处理I/O的时间。iostat在计算avgqu-sz时会用到这个字段。

iostat(1)是以/proc/diskstats为基础计算出来的,由于 /proc/diskstats并未把队列等待时间和硬盘处理时间分开,以是 凡是以它为基础的工具都不大概 分别提供disk service time以及与queue有关的值。

注:下面的公式中“Δ”表示两次取样之间的差值,“Δt”表示采样周期。

r/s:每秒读操作的次数=[Δrd_ios/Δt]r/s:每秒读操作的次数=[Δwr_ios/Δt]tps:每秒I/O次数=[(Δrd_ios+Δwr_ios)/Δt]rkB/s:每秒读取的千字节数=[Δrd_sectors/Δt]*[512/1024]wkB/s:每秒写入的千字节数=[Δwr_sectors/Δt]*[512/1024]rrqm/s:每秒合并读操作的次数=[Δrd_merges/Δt]wrqm/s:每秒合并写操作的次数=[Δwr_merges/Δt]avgrq-sz:每个I/O的匀称 扇区数=[Δrd_sectors+Δwr_sectors]/[Δrd_ios+Δwr_ios]avgqu-sz:队列里的匀称 I/O哀求 数目 =[Δtime_in_queue/Δt]

(更适当 的明白 应该是匀称 未完成的I/O哀求 数目 。)await:每个I/O匀称 所需的时间=[Δrd_ticks+Δwr_ticks]/[Δrd_ios+Δwr_ios]

不仅包括硬盘装备 处理I/O的时间,还包括了在kernel队列中等待的时间。r_await:每个读操作匀称 所需的时间=[Δrd_ticks/Δrd_ios]

不仅包括硬盘装备 读操作的时间,还包括了在kernel队列中等待的时间。w_await:每个写操作匀称 所需的时间=[Δwr_ticks/Δwr_ios]

不仅包括硬盘装备 写操作的时间,还包括了在kernel队列中等待的时间。%util:该硬盘装备 的繁忙比率=[Δio_ticks/Δt]

表示该装备 有I/O(即非空闲)的时间比率,不思量 I/O有多少,只思量 有没有。svctm:已被废弃的指标,没什么意义,svctm=[util/tput]

对iostat(1)的适当 解读有助于准确 地分析标题 ,我们团结 现实 案例进一步讨论。

关于rrqm/s和wrqm/s

前面讲过,假如 两个I/O操作发生在相邻的数据块时,它们可以被合并成一个,以进步 服从 ,合并的操作通常是I/O scheduler(也叫elevator)负责的。

以下案例对很多 硬盘装备 实验 同样的压力测试,结果 惟有sdb比别的 硬盘都更快一些,但是 硬盘型号都一样,为什么sdb的表现不一样?

容易

被误读的iostat(Linux体系
)

可以看到别的 硬盘的rrqm/s都为0,而sdb不是,就是说发生了I/O合并,以是 服从 更高,r/s和rMB/s都更高,我们知道I/O合并是内核的I/O scheduler(elevator)负责的,于是检查了sdb的/sys/block/sdb/queue/scheduler,发现它与别的硬盘用了不同的I/O scheduler,以是 表现也不一样。

%util与硬盘装备 饱和度

%util表示该装备 有I/O(即非空闲)的时间比率,不思量 I/O有多少,只思量 有没有。由于当代 硬盘装备 都有并行处理多个I/O哀求 的本领 ,以是 %util即使达到100%也不意味着装备 饱和了。举个简化的例子:某硬盘处理单个I/O必要 0.1秒,有本领 同时处理10个I/O哀求 ,那么当10个I/O哀求 依次次序 提交的时间 ,必要 1秒才能全部完成,在1秒的采样周期里%util达到100%;而假如 10个I/O哀求 一次性提交的话,0.1秒就全部完成,在1秒的采样周期里%util只有10%。可见,即使%util高达100%,硬盘也仍然 有大概 还有余力处理更多的I/O哀求 ,即没有达到饱和状态。那么iostat(1)有没有哪个指标可以衡量硬盘装备 的饱和程度呢?很遗憾,没有。

await多大才算有标题

await是单个I/O所斲丧 的时间,包括硬盘装备 处理I/O的时间和I/O哀求 在kernel队列中等待的时间,正常环境 下队列等待时间可以忽略不计,姑且把await当作衡量硬盘速率 的指标吧,那么多大算是正常呢?

对于SSD,从0.0x毫秒到1.x毫秒不等,具体 看产品手册;

对于机械硬盘,可以参考以下文档中的计算方法:

http://101.96.10.61/cseweb.ucsd.edu/classes/wi01/cse102/sol2.pdf

大致来说一万转的机械硬盘是8.38毫秒,包括寻道时间、旋转耽误 、传输时间。

在实践中,要根据应用场景来判定 await是否正常,假如 I/O模式很随机、I/O负载比较高,会导致磁头乱跑,寻道时间长,那么相应地await要估算得大一些;假如 I/O模式是次序 读写,只有单一进程 产生I/O负载,那么寻道时间和旋转耽误 都可以忽略不计,重要 思量 传输时间,相应地await就应该很小,乃至 不到1毫秒。在以下实例中,await是7.50毫秒,好像 并不大,但思量 到这是一个dd测试,属于次序 读操作,而且只有单一使命 在该硬盘上,这里的await应该不到1毫秒才算正常:

  1. Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
  2. sdg 0.00 0.00 133.00 0.00 2128.00 0.00 16.00 1.00 7.50 7.49 99.60
复制代码

对磁盘阵列来说,由于 有硬件缓存,写操作不等落盘就算完成,以是 写操作的service time大大加快了,假如 磁盘阵列的写操作不在一两个毫秒以内就算慢的了;读操作则未必,不在缓存中的数据仍然 必要 读取物理硬盘,单个小数据块的读取速率 跟单盘差不多


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

avatar 尹恩沛 | 2021-9-17 03:02:42 | 显示全部楼层
小弟默默的路过贵宝地~~~
回复

使用道具 举报

avatar 樱花283 | 2021-10-4 03:43:26 | 显示全部楼层
admin楼主,我告诉你一个你不知道的的秘密,有一个牛逼的网站,他卖的服务器是永久的,我们的网站用 服务器都是在这家买的,你可以去试试。访问地址:http://fwq.mxswl.com
回复

使用道具 举报

avatar 绘粹凭 | 2021-10-15 22:30:57 | 显示全部楼层
学习雷锋,好好回帖!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则