我正在努力提高我的理解，遵循这个（到目前为止）尚未回答的问题：Fedora VM 升级期间可能的限制因素 - 不是磁盘、CPU 或网络？
我运行了以下测试负载，花了 200 秒才能完成。
sudo perf trace -s time perf stat dnf -y --releasever=30 --installroot=$HOME/fedora-30 --disablerepo='*' --enablerepo=fedora --enablerepo=updates install systemd passwd dnf fedora-release vim-minimal
我在相当默认、直接安装的 Fedora Workstation 29 上运行它。它不是虚拟机。内核版本为5.0.9-200.fc29.x86_64。 IO调度器是mq-deadline.
我使用 LVM 和ext4文件系统。我没有在我的磁盘或文件系统上使用任何加密。我根本没有安装任何网络文件系统，因此我没有读取或写入网络文件系统。
我有 4 个“CPU”：2 个核心，每个核心有 2 个线程。
我只有一个磁盘，/dev/sda即 SATA HDD。 HDD 支持 NCQ：cat /sys/class/block/sda/device/queue_depth显示32。
vmstat 5显示非空闲CPU时间有时升至1个CPU左右，即空闲率低至75%。
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
...
1 1 3720 1600980 392948 3669196 0 0 14 30634 8769 1876 4 3 78 15 0
1 1 3720 1600144 393128 3669884 0 0 0 3460 1406 1468 0 1 80 18 0
0 1 3720 1599424 393356 3670532 0 0 0 6830 1416 1480 0 1 73 25 0
0 1 3720 1598448 393700 3671108 0 0 0 7766 1420 1362 0 1 78 20 0
0 1 3720 1597296 393940 3671616 0 0 0 5401 1374 1367 1 2 87 11 0
0 1 3720 1596332 394312 3672416 0 0 0 1162 1647 1558 1 2 85 13 0
3 0 3720 1652064 394564 3673540 0 0 0 17897 15406 1784 1 3 74 23 0
0 0 3720 1972876 394600 3541064 0 0 0 522 8028 18327 3 3 84 10 0
1 0 3720 1974152 394600 3541108 0 0 0 9 422 879 2 1 97 0 0
0 0 3720 1974136 394600 3541120 0 0 0 0 204 455 0 0 99 0 0
(end of test)
而“IO等待”时间（下图所示的wa字段）则上升了高达25%。我认为这意味着 100% 的一个 CPU。但显示我的磁盘利用率与此不直接匹配。远低于 100%：cpuvmstatatopsar -d 5
22:46:44 disk busy read/s KB/read writ/s KB/writ avque avserv _dsk_
...
22:49:34 sda 5% 0.4 4.0 69.5 413.0 36.9 0.68 ms
22:49:39 sda 8% 0.2 60.0 120.6 30.6 18.7 0.66 ms
22:49:44 sda 8% 0.0 0.0 136.2 16.7 20.4 0.61 ms
22:49:49 sda 10% 0.0 0.0 157.1 44.2 21.4 0.65 ms
22:49:54 sda 9% 0.0 0.0 196.4 39.3 48.0 0.47 ms
22:49:59 sda 9% 0.0 0.0 148.9 36.6 32.6 0.62 ms
22:50:04 sda 10% 0.0 0.0 137.3 130.6 37.2 0.70 ms
22:50:09 sda 11% 0.0 0.0 199.6 5.4 13.5 0.55 ms
22:50:14 sda 2% 0.0 0.0 50.2 4.5 11.8 0.32 ms
22:50:19 sda 0% 0.0 0.0 0.8 11.0 13.3 0.75 ms
(end of test)
“IO等待”时间怎么会高于磁盘利用率呢？
以下是取自 sar 联机帮助页的定义：
%io等待：
系统有未完成的磁盘 I/O 请求期间，一个或多个 CPU 处于空闲状态的时间百分比。
因此，%iowait 意味着从 CPU 的角度来看，没有任务可运行，但至少有一个 I/O 正在进行。 iowait 只是一种空闲时间，无法安排任何事情。该值在指示性能问题方面可能有用，也可能没有用，但它确实告诉用户系统处于空闲状态并且可能需要进行更多工作。
https://support.hpe.com/hpsc/doc/public/display?docId=c02783994
在多 CPU 系统上定义“IO 等待”是很棘手的。看CPU 如何知道有 IO 待处理？。但即使您认为我将上面的“IO 等待”数字乘以 4 是错误的，它仍然会高于磁盘利用率数字！
atopsar -d我预计（以及atop// sar -d/iostat -x中的磁盘利用率数字mxiostat.py）是根据其中之一计算的内核 iostat 字段。链接的文档提到“字段 10 - 执行 I/O 所花费的毫秒数”。还有一个更详细的定义，尽管我不确定它提到的功能是否仍然存在于当前的多队列块层中。
感谢perf测试命令中的 ，我还可以报告 dnf 的fdatasync()调用对 200 秒的运行时间中的 81 秒负责。这个证据向我表明，“IO 等待”数据比磁盘利用率数据给出了更准确的印象。
199.440461084 seconds time elapsed
60.043226000 seconds user
11.858057000 seconds sys
60.07user 12.17system 3:19.84elapsed 36%CPU (0avgtext+0avgdata 437844maxresident)k
496inputs+2562448outputs (25major+390722minor)pagefaults 0swaps
Summary of events:
...
dnf (6177), 2438150 events, 76.0%
syscall calls total min avg max stddev
(msec) (msec) (msec) (msec) (%)
--------------- -------- --------- --------- --------- --------- ------
fdatasync 3157 81436.062 0.160 25.795 465.329 1.92%
wait4 51 43911.444 0.017 861.009 32770.388 74.93%
poll 45188 6052.070 0.001 0.134 96.764 5.58%
read 341567 2718.531 0.001 0.008 1372.100 50.63%
write 120402 1616.062 0.002 0.013 155.142 9.61%
getpid 50012 755.423 0.001 0.015 207.506 32.86%
...
答案1
“IO等待”时间上升高达25%。我认为这意味着 100% 的一个 CPU”。
不，这基本上就是你开始出错的地方。 I/O 等待根本不需要 CPU 核心。 I/O 等待基本上是内核中的一种状态，意味着“不要在此进程上浪费 CPU，它仍在等待外部操作完成”。当内核看到一个 I/O 操作完成时，它会找到等待的进程并重新调度它。
因此，您可以让 100 个进程等待 I/O，在一秒挂钟时间内，它们将累积 100 秒的 I/O 等待时间。然而，CPU 可能正忙于为第 101 个进程提供服务。
此外，您还可以将 I/O 等待与磁盘利用率进行比较。虽然磁盘是 I/O 的一种形式，但它们并不是唯一的形式。网络套接字也可以等待。当您使用远程文件系统时，这种类型的 I/O 可能会被隐藏。