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

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

#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秒,因为两个进程同时运行.