标签: iotop

在我新安装的 CentOS 7.5 的终端中使用sudo iotop(latest version 0.6-2.el7) 时，我收到以下错误消息：

Traceback (most recent call last):
  File "/sbin/iotop", line 17, in <module>
    main()
  File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 620, in main
    main_loop()
  File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 610, in <lambda>
    main_loop = lambda: run_iotop(options)
  File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 508, in run_iotop
    return curses.wrapper(run_iotop_window, options)
  File "/usr/lib64/python2.7/curses/wrapper.py", line 43, in wrapper
    return func(stdscr, *args, **kwds)
  File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 501, in run_iotop_window
    ui.run()
  File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 155, in run
    self.process_list.duration)
  File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 434, in refresh_display
    lines …

我的命令：

gunzip -c serial2udp.image.gz |
sudo dd of=/dev/mmcblk0 conv=fsync,notrunc status=progress bs=4M

我的输出：

15930949632 bytes (16 GB, 15 GiB) copied, 1049 s, 15.2 MB/s    

0+331128 records in
0+331128 records out
15931539456 bytes (16 GB, 15 GiB) copied, 1995.2 s, 8.0 MB/s

卡：SanDisk Ultra 32GB MicroSDHC Class 10 UHS 存储卡速度高达 30MB/s
发行版：16.0.4 xenial with xfce
内核版本：4.13.0.37-generic

我知道从我读过的内容来看，花 17 分钟似乎是合理的。玩块大小似乎并没有太大区别（bs=100M 仍然表现出类似时间戳的这种行为）。为什么更新挂起，并且在 16 分钟内没有生成完成的报告？

iotop 告诉我 mmcqd/0 此时仍在后台运行（以 99% IO），所以我认为某处有一个缓存占用了最后的 5MB，但我认为 fsync 应该确保不会发生iotop 显示此时 dd 也没有交通路口。ctrl-c 几乎没用，我不想在写入后损坏我的驱动器。

我有一个工作站（2 个 Intel Xeon 系列 CPU 和 128GiB 的 RAM）运行多个虚拟机，虽然组合 CPU 使用率 <30%，但平均负载在 20 到 25 之间。例如，如果我执行一个tar -xzvf vm_data.tgz --directory vm4/ --strip-components=1命令，那么该gzip过程是90％ -其99％的时间已被I / O和命令需要永远完成：

另一方面，与 SATA 3.0 或 SSD（我使用的是单个金士顿 SA400S37960G SSD）硬件限制相比，对磁盘的实际读取和写入非常低。

什么可能导致进程（gzip在我的示例中）在 I/O 之后等待而实际磁盘读取和写入似乎非常低？我的第一个想法是，也许系统中断非常高，这就是阻塞 I/O 的原因，但根据/proc/interrupts这一点，情况似乎并非如此，因为没有一个计数器在快速增加。