linux – 解释/ proc / diskstats中的读取,写入和总IO时间

发布时间：2020-12-14 03:03:07 所属栏目：Linux 来源：网络整理

导读：我注意到当我查看/ proc / diskstats的输出时,读取的总时间,写入的总时间和执行IO的总时间之间存在差异.例如,我在/ proc / diskstats中看到一个条目： $cat /proc/diskstats...8 0 sda 944150584 590524 235547588959 780672196 833280352 534699043 3225076

我注意到当我查看/ proc / diskstats的输出时,读取的总时间,写入的总时间和执行IO的总时间之间存在差异.例如,我在/ proc / diskstats中看到一个条目：

$cat /proc/diskstats
...
8       0 sda 944150584 590524 235547588959 780672196 833280352 534699043 322507689696 3472000824 1 812190100 4246357772
...

根据https://www.kernel.org/doc/Documentation/iostats.txt的文件,

Field 4 — # of milliseconds spent reading
This is the total number of milliseconds spent by all reads (as
measured from __make_request() to end_that_request_last()).

Field 8 — # of milliseconds spent writing
This is the total number of milliseconds spent by all writes (as
measured from __make_request() to end_that_request_last()).

Field 10 — # of milliseconds spent doing I/Os
This field increases so long as field 9 is nonzero.

因此,我希望第十个字段是第四个字段和八个字段的总和,因为我预计总IO时间是读取时间和写入时间之和.但是,我从来没有注意到这种情况,而且我总是观察到第四和第八个字段的总和大于十分之一(例如,在上面的行中(780672196 3472000824 – 812190100 = 3440482920)我想知道是否有人可以解释为什么这些数字不同,似乎第十个领域试图捕捉不同于第四和第八场的总和的东西.

解决方法

我没有查看源代码,但似乎差异源于两种不同的会计模式.

#4和#8字段汇总了每个请求完成的时间.这意味着并行发出的请求仍然有助于使计数增长.

#10字段仅计算队列和磁盘繁忙的实际时间,因此它们将并行发出的请求计为单个请求.

让我们举一个实际的例子.在/ boot分区上,我写了一个~4 MB的文件.看看统计数据：

[root@localhost boot]# cat /proc/diskstats | grep sda1
   8       1 sda1 46256 0 255703 19332 2063 0 4162 538 0 11207 19862
[root@localhost boot]# dd if=initramfs-0-rescue-7dc32e3935ba4ce1ae50a0a8170e4480.img of=/dev/null
84099+1 records in
84099+1 records out
43058701 bytes (43 MB) copied,0.347783 s,124 MB/s
[root@localhost boot]# cat /proc/diskstats | grep sda1
   8       1 sda1 46342 0 339807 23011 2063 0 4162 538 0 11551 23540
[root@localhost boot]#

读取文件需要~0.35s,或~350ms.然而,#4和#10的反应方式反应非常不同：第一次增加约4000,而后者只增加约350.很容易看出它具有“正确”值：它是第10场,正如我们所知道的那样dd表示整个操作耗时约350ms,而#10场则增加了相同的量.

那么,为什么#4领域增长如此之多,以及它真正衡量的是什么？

首先,让我们了解请求级别发生了什么.默认情况下,dd使用512B请求,但linux pagecache的工作粒度为4KB,因此我们应该期待大约1000 x 4KB的请求.这1000个请求被放入一个队列并逐个发出(为简单起见,让我们假装NCQ不存在)并分派到磁盘.由于机械磁盘非常适合顺序读取,因此它们通常使用预读策略 – 即：它们读取的数据多于所需数据.这意味着,在第一个4K请求完成后,所有其他后续请求将在很短的时间内提供.

让我们做一些数学运算,通过大量的简化：

>请求数：1000(所有请求同时进入队列)
>第一次请求完成的时间：4ms
>所有后续请求完成的时间：0ms(是的,我告诉过你这是一个疯狂的简化)

按字段#4测量的总请求时间：1000个队列内请求*每个4ms == 4000ms.这大致是#4领域增加的价值……

底线：

>字段#4和#8从单个请求的角度测量服务I / O请求所花费的时间,将其乘以请求数
>字段#10告诉您I / O路径中使用的实际经过时间(“挂钟”)

绘制一个approssimative并行：想到多核CPU.两个进程可以同时锤击CPU,每个进程执行60秒.使用的总CPU时间为120秒(60秒* 2),但实际经过的时钟时间总计为60秒,因为两个进程同时运行.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!