我有这个珀尔 脚本和我发现这pv命令并决定使用它来获取有关吞吐量随机性发生情况的一些反馈。经过几次测试1我决定限制该命令，如下所示：
perl_commands < /dev/urandom | pv -L 512k | tr -cd SET
5.5MiB 0:00:11 [ 529kiB/s] [ <=> ]
我暂停使用systemctl suspend（阿奇邦）。当我恢复时，该命令仍然运行，并在其对话框中包含自挂起以来经过的时间，但看起来好像限制我设置不再强制，吞吐量为 2-3MiB/s，CPU 更高 - 就像没有限制一样。一段时间后，这消退我可以看到该限制仍然有效。
例如，如果我仅运行该命令几秒钟，则吞吐量需要几秒钟才能恢复到其设置的限制。另一方面，在一小时内生成 815Mb 的数据，然后暂停 30 分钟，然后命令需要大约 5 分钟才能返回到我设置的限制 - 在那段时间 CPU 使用率就像没有节流一样。
因此，并不是说限制没有被强制执行，而是从挂起状态到内存似乎会影响这种情况下的吞吐量。为什么以及可以改变这种行为吗？
1. 该命令在未节流时使用一个 CPU 核心。限制为 512KiB\s 时，CPU 使用率约为 10-15% 或更少。需要大约 2GB 的随机性（和一些时间）来填充我的 80x40 终端窗口（取决于 SET）。
答案1
pv不知道系统电源状态。它所看到的只是时钟在某个时刻发生了很大的变化。
我的猜测是，pv并不关心两个时钟读数之间的时间量是否突然变大，而只是根据时间间隔计算吞吐量。由于间隔很大，看起来吞吐量很低。
吞吐量计算是多次时钟读取的平均值（观察中大约为 5 分钟）。只要所考虑的间隔包括暂停所花费的时间，计算出的吞吐量值就会非常低。一旦间隔再次仅由清醒时间组成，吞吐量将恢复到预期水平。
例如，假设您暂停了 5 分钟。然后恢复后，pv计算出最后 5 分钟内传输了 500kB，这意味着吞吐量仅为 1.7kB/s 左右。这远低于 500kB 阈值，因此pv需要传输更多数据一段时间以进行补偿。最终吞吐量计算将再次稳定。
挂起系统与挂起进程不同pv。挂起系统对于程序来说是透明的。挂起进程会在其唤醒时向其发送 SIGCONT 信号。pv有一个 SIGCONT 信号处理程序，这会导致它或多或少地减去挂起所花费的时间（我还没有检查如果它被不可捕获的 SIGSTOP 信号挂起，它到底会做什么，但它不应该引起太大的扰动，与系统暂停不同）。
答案2
在这种情况下，确保我们保持在限制以下是最重要的因素，您可以尝试这种替代方案 -流媒体（此处每 2 分钟显示一次吞吐量摘要）：
cstream -t -512k -T 120
允许负数的吞吐量选项似乎是针对这种情况设计的：
-t num Limit the throughput of the data stream to num bytes/second.
Limiting is done at the input side, you can rely on cstream not
accepting more than this rate. If the number you give is posi-
tive, cstream accumulates errors and tries to keep the overall
rate at the specified value, for the whole session. If you give
a negative number, it is an upper limit for each read/write
system call pair. In other words: the negative number will
never exceed that limit, the positive number will exceed it to
make good for previous underutilization.
用于暂停进程或系统。