我从开发人员的角度看待这个问题。我编写的代码被放置在 RHEL 虚拟机上，该虚拟机是企业系统中众多虚拟机之一。所使用的文件系统是远程网络连接存储设备。
在批处理过程中，我们发现一些简单命令存在很大差异。因此我们设置了一个测试来获取更多信息，但现在我不知道我们发现了什么。
我们每 30 分钟运行以下命令并记录输出。这是一个 6 GB 文件的副本。我看到的是，当系统忙于运行大量作业并且此测试命令的 CPU 时间较低时，经过的时间从 11 秒跳到 190 秒。
我可以看到，当 CPU 较低时，列“I”（文件系统输入）会被填充，但当 CPU 较高时则不会。列“w”（非自愿交换）也高得多。
我的问题是，当 CPU 时间减少时，这个作业/命令发生了什么，迫使它运行这么长时间？交换输入/输出是否会将所有数据存储在其他速度慢得多的设备上？通常，交换输入/输出期间会发生什么？
正在运行的命令：
/usr/bin/time -a -o filename.txt cp file.txt fileCopy.txt
| 日期 | 时间 | 埃 | 年代 | 乌 | 磷 | C | 瓦 | 我 | 哦 |
|---|---|---|---|---|---|---|---|---|---|
| 2022 年 3 月 14 日 | 5:19:02 | 64.9 | 16.23 | 1.03 | 26% | 3005 | 29210 | 12000016 | 12000000 |
| 2022 年 3 月 14 日 | 5:49:02 | 12.7 | 11.63 | 0.79 | 97％ | 2069 | 76 | 0 | 12000000 |
| 2022 年 3 月 14 日 | 6:19:02 | 100.39 | 14.74 | 0.78 | 15％ | 1034 | 29925 | 12000136 | 12000000 |
| 2022 年 3 月 14 日 | 6:49:24 | 191.32 | 18.86 | 0.94 | 10％ | 3374 | 36164 | 12001024 | 12000000 |
| 2022 年 3 月 14 日 | 7:19:02 | 71.61 | 15.61 | 0.88 | 23% | 1610 | 30316 | 12000296 | 12000000 |
| 2022 年 3 月 14 日 | 7:49:02 | 70.73 | 17.5 | 0.91 | 26% | 1408 | 29540 | 12000072 | 12000000 |
| 2022 年 3 月 14 日 | 8:19:02 | 10.95 | 9.89 | 0.7 | 96％ | 1709 | 75 | 0 | 12000000 |
| 2022 年 3 月 14 日 | 8:49:02 | 11.01 | 10.22 | 0.73 | 99％ | 239 | 85 | 0 | 12000000 |
/usr/bin/time 手册页中的列描述
e Elapsed real time (in seconds).
S Total number of CPU-seconds that the process spent in kernel mode.
U Total number of CPU-seconds that the process spent in user mode.
P Percentage of the CPU that this job got, computed as (%U + %S) / %E.
c Number of times the process was context-switched involuntarily (because the time slice expired).
w Number of waits: times that the program was context-switched voluntarily, for instance while waiting for an I/O operation to complete.
I Number of filesystem inputs by the process.
O Number of filesystem outputs by the process.
答案1
在此上下文中，P 表示此作业获得的 CPU 时间与总耗时之比。接近 100% 表示几乎所有时间都在 CPU 上，因此这些运行的 CPU 受到限制。与其他运行相比，其他运行的限制因素是其他因素。系统（又称内核）时间多于系统时间，这是 I/O 密集型任务的典型特征。
鉴于工作负载是复制一个 6 GB 的文件，我们可以推断 11 秒的运行平均每秒写入超过 0.5 GB。O 列确认每次写入次数相同，与简单的复制一个文件过程一致。
但是，输入列有很大波动。慢速运行时的读取量与写入量大致相同。但快速运行时不进行任何读取！我假设文件仍然缓存在 RAM 中，与上次读取时一样。DRAM 甚至比固态存储快得多。这是一个很大的速度提升，直到在内存压力下操作系统会丢弃缓存的数据，并且必须再次从慢速存储中读取。
因此，这是一项耗时 200 秒的任务，有时可能需要 12 秒。可能是由于 Linux 页面缓存。
要找到性能问题的根本原因，通常需要对整个系统有更深入的了解，而不仅仅是任何特定的指标集。
正在使用的文件系统是远程网络附加存储设备。
请注意，您的复制内容是通过网络存储进行的，因此它也可能是远程系统或两者之间的网络上的任何内容。远程存储性能。网络（可能是 IP）速度和利用率。或者它可能位于此 VM 的本地，其中客户机正在与基础架构上运行的其他所有东西争夺资源。
总是可以更深入地了解事物的工作原理。网络存储（NFS？）是否重要，或者您是否也认为本地磁盘也存在这种情况？0.7 秒的用户 CPU 时间实际上是相当多的工作，管理许多系统调用需要多少时间？当大部分时间都在等待缓慢的内存和非常慢的存储时，CPU 繁忙实际上意味着什么？这不是一个容易回答的问题，但是一旦事物运行良好，也许就不需要深入挖掘了。