我们有三个据称相同的系统，其中一个是 RHEL7 系统，该系统经常（每 5 天到一周）陷入某种奇怪的资源匮乏情况。主要症状似乎是启动新进程（和线程？）时出现严重延迟。我尝试并研究了大量事情，简而言之，系统看起来完全处于空闲状态，内存和 CPU 都随时可用/空闲……虽然许多进程可能显示为“D”状态，但 /proc/stat 显示procs_blocked 0。似乎没有沉重的 IO 负载。
这是我正在关注的问题的一个奇怪的表现......在最后两次这样的场合，我运行了以下操作并得到了准确（在 0.01 秒内）相同的结果：
$ time sleep 0
real 2m21.006s
user 0m0.000s
sys 0m0.007s
也就是说，运行延迟了 141 秒，这有点奇怪sleep 0。也许值得注意的是，我还做了以下事情：
$ strace -c sleep 0
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
59.00 0.001606 535 3 open
19.32 0.000526 131 4 mprotect
8.89 0.000242 242 1 1 access
6.58 0.000179 59 3 fstat
2.87 0.000078 9 8 mmap
0.96 0.000026 5 5 close
0.62 0.000017 17 1 munmap
0.55 0.000015 3 4 brk
0.40 0.000011 11 1 execve
0.37 0.000010 10 1 nanosleep
0.33 0.000009 9 1 read
0.11 0.000003 3 1 arch_prctl
------ ----------- ----------- --------- --------- ----------------
100.00 0.002722 33 1 total
所以...这两者实际上并不一致，这令人费解...我预计会看到一些系统调用一直在消耗，但是（就像这种情况下的许多指标一样）一切看起来都很顺利。
显然有数百万个变量（例如这是一个 VM，我查看了 CPU_READY 等），并且我试图研究那些对我来说有意义的变量……但是那个可重复的整秒延迟对我来说很突出。
strace知道是什么原因导致启动这样一个基本过程时出现 141 秒暂停吗？而且最重要的是，在?中不会显示出来。
更新
好的，有两条新信息。我们关闭了该系统，并移动了一个虚拟磁盘，其中有 15TB东西到最新的服务器，这样我们就可以复制所有内容 - 旧磁盘是 EXT4，新磁盘是 XFS，所以我们正在挂载和复制，而不是永久地重新挂载 VMDK。
现在，新系统正在做着同样的事情。
所以，可能我们移动的磁盘是一个因素。但是这些系统的配置应该几乎相同，所以它可能只是稍后才显现出来。但是，是的，那个磁盘可能是一个因素。
还有另一点：
我尝试中断time sleep 0命令 - 即输入命令，按 Enter 键，然后立即按 ctrl+C。猜猜怎么着？...
[matthew.williamson@nwcal-cee-ti04 ~]$ time sleep 0 ^C real 0m47.003s user 0m0.000s sys 0m0.004s
47 秒……可靠。如果你还没猜到的话，47*3 = 141 秒。因此，sleep 0 的时间正在执行某物三次需要 47 秒才能返回。那会是什么？我想我会再看看 strace。
哦...顺便说一下，那个磁盘不是根分区，所以time也不sleep应该触碰它...所以这很奇怪...如果它相关，它一定会破坏内核中的某些真正好的东西。