☰

I/O 效率低下的原因？

tag-icon • tag-icon rsync performance file-copy io
I/O 效率低下的原因？

我正在rsync将一个巨大的文件夹从外部 3.5 英寸硬盘移到内部 3.5 英寸硬盘，转速均为 5.400 rpm。当使用它dstat来查看当前吞吐量时，我经常看到如下模式：

--total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
 20   6  34  40   0|  98M   90M|1272B 3652B|   0     0 |1702  4455 
 21   6  37  37   0| 121M   90M|1646B 4678B|   0     0 |2057  6488 
 17  24  29  30   0|  77M   95M| 630B 2416B|   0     0 |1581  4644 
 20   5  33  43   0|  86M   84M|1372B 2980B|   0     0 |1560  4146 
 20   6  30  44   0|  80M   75M| 700B 2722B|   0     0 |1484  3942 
 11   2  47  39   0|  39M   65M| 642B 1332B|   0     0 | 765  1507 
  0   0  50  50   0|   0    91M|  70B  354B|   0     0 | 136    70 
  0   0  50  49   0|   0    71M| 306B  346B|   0     0 | 146   119 
  0   0  50  50   0|   0    83M|  70B  346B|   0     0 | 145    60 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  36    84 
  0   0  50  50   0|   0     0 | 164B  646B|   0     0 |  35    71 
  0   0  50  50   0|   0     0 | 140B  802B|   0     0 |  30    64 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  27    68 
  0   0  50  50   0|   0    34M| 134B  346B|   0     0 |  86    68 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  30    71 
  0   0  50  50   0|   0     0 |2320B  346B|   0     0 |  40    76 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  29    71 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  25    50 
 -----------------------------[snip]------------------------------
  0   0  50  50   0|   0     0 |2230B  346B|   0     0 |  35    61 
  0   0  50  50   0|   0    60M|  70B  346B|   0     0 | 118    83 
  1   7  42  50   0| 256k  104M| 230B  500B|   0     0 | 281   480 
 21   5  31  42   0| 117M   76M|1120B 3392B|   0     0 |1849  4309 
 23   5  36  36   0| 137M   56M|1202B 3958B|   0     0 |2149  5782 
 24   5  36  35   0| 138M  100M|1284B 4112B|   0     0 |2174  6021

比如说，在几秒钟到一分钟的时间内，读取和写入吞吐量都降至零。这里的瓶颈是什么？

我的意思是，由于两个驱动器的速度大致相同，因此它们都不应该闲置太久。更进一步，至少一个驱动器应该始终处于读取或写入状态。系统还在等什么？

系统空闲，唯一吃cpu的就是rsync任务。内存为8GB，CPU为第七代i5四核。内部硬盘通过 SATA 连接到主板（Gigabyte G170X-Ultra Gaming）。在这两种情况下，文件系统都是 ext4，在内部（写入）端使用 dmcrypt/LUKS 进行加密。可能是这个原因吗？如果是这样，如何检查 dmcrypt 的性能？我看到，当发生传输丢失时，CPU 50% 空闲，50% 等待。我可以从中得出什么结论？

它是具有内核版本的最新 Archlinux 4.13.11-1-ARCH。有什么要注意的吗？提前致谢。

更新： iotop被指出比 更准确dstat。不幸的是，当吞吐量降至零时iotop也显示为零。dstat我做了一个截屏视频来展示它。

答案1

有两套工具可以获取一些块级设备统计信息。第一个是延迟性来自布伦丹·格雷格的性能工具。它生成磁盘操作延迟的简单直方图，例如：

>=(ms) .. <(ms)   : I/O      |Distribution                          |
     0 -> 1       : 1913     |######################################|
     1 -> 2       : 438      |#########                             |
     2 -> 4       : 100      |##                                    |
     4 -> 8       : 145      |###                                   |
     8 -> 16      : 43       |#                                     |
    16 -> 32      : 43       |#                                     |
    32 -> 64      : 1        |#                                     |

工具集中的另一个脚本iosnoop显示命令及其操作，例如：

COMM         PID    TYPE DEV      BLOCK        BYTES     LATms
/usr/bin/mon 31456  R    8,0      9741888      4096       2.14
/usr/bin/mon 31456  R    8,0      9751408      4096       0.16
/usr/bin/mon 31456  R    8,0      20022728     4096       1.44
/usr/bin/mon 31456  R    8,0      19851752     4096       0.26
jbd2/sda3-41 416    WS   8,0      130618232    65536      1.89
jbd2/sda3-41 416    WS   8,0      209996928    65536      1.92
jbd2/sda3-41 416    WS   8,0      210006528    8192       1.94

然后是块跟踪包记录低级块操作blktrace，然后显示各种信息，以及许多其他命令，包括来自（的blkparse简单摘要）bttpdf 用户指南）：

$ sudo blktrace /dev/sda  # ^C to stop
=== sda ===
  CPU  0:                  180 events,        9 KiB data
  CPU  1:                 1958 events,       92 KiB data
  Total:                  2138 events (dropped 0),      101 KiB data
$ ls -ltra # one file per cpu
-rw-r--r--    1 root   root       8640 Nov  5 10:16 sda.blktrace.0
-rw-r--r--    1 root   root      93992 Nov  5 10:16 sda.blktrace.1
$ blkparse -O -d combined.output  sda.blktrace.*  # combine cpus
$ btt -i combined.output 
    ALL           MIN           AVG           MAX           N
Q2Q               0.000001053   0.106888548   6.376503027         253
Q2G               0.000000795   0.000002266   0.000011060         184
G2I               0.000000874   0.000979485   0.002588781         328
Q2M               0.000000331   0.000000599   0.000002716          70
I2D               0.000000393   0.000480112   0.002435491         328
M2D               0.000002044   0.000028418   0.000126845          70
D2C               0.000080986   0.001925224   0.010111418         254
Q2C               0.000087025   0.002603157   0.010120629         254
...

例如，D2C 是硬件设备执行一项操作所需的时间。

您还可以sudo smartctl -a /dev/sda在每张光盘上运行以查看是否显示任何故障。

答案2

我猜想这dstat会使用文件描述符级别的 I/O 统计信息，即应用程序调用write()，并且一旦系统调用返回dstat就会看到增加的数据。

但这并不意味着数据实际上已经被写入。我猜想这些看似暂停的阶段是将缓冲区写入块设备的阶段。这是有道理的，在这些时间内，I/O 等待值甚至高于dstat测量数据传输的阶段。

iotop区分磁盘和缓存的写入和读取。也许该工具可以提供有趣的附加信息。

相关内容