为什么strace不显示该过程正在等待某些东西？

强大的力量strace让我失望了。这怎么可能？

time foo显示foo运行需要几秒钟（“真实”），但在用户空间（“用户”）和内核（“ sys”）中使用的CPU时间都可以忽略不计。对于好奇，foo定义如下。

因此，它花费大部分时间等待其他事情，而不是执行CPU指令。正常情况下，我可以看到它的等待状态strace-即哪个系统调用长时间处于阻塞状态。不幸的是，这种方法行不通。

strace -ttt -T -C -w foo显示系统调用，时间戳和系统调用所花费的（实际）时间的摘要。但是，此特定过程显示出在系统调用内花费的总（实际）时间微不足道。

foo实际上是journalctl -b -u dev-hugepages.mount。除非我每次都必须将最后一个参数更改为一个不同的systemd单元，以便重现此参数。换句话说，我正在调查的延迟是在我第一次尝试获取任何一个systemd单元的日志时发生的。 编辑：在回答了主要问题之后，我还意识到我遇到这个问题会导致延迟的原因。

此过程花费的时间是一个特定的问题，显然并非在所有系统上都发生。https://github.com/systemd/systemd/issues/7963

遇到此问题的通常原因是该进程阻塞了页面错误。这些是通过内存映射aka进行的对文件的读取或可能的写入mmap()。您可能已经注意到一些mmap()系统调用跟踪。

如果您使用的是/usr/bin/time程序而不是time内置的Shell，您可能还会注意到：

0.04user 0.10system 0:02.29elapsed 6%CPU (0avgtext+0avgdata 40464maxresident)k
73632inputs+0outputs (376major+1081minor)pagefaults 0swaps

majorpagefault是需要文件系统IO的那些。 minorPagefault的重要性要低得多（可能只有“ TLB遗漏”）。

我怀疑inputs是已读取的总页数。目前，我认为文件映射页面的大小始终相同。在大多数情况下为4096字节，但您可以检查getconf PAGESIZE。

因此，这代表约290兆字节，每秒读取速度超过100兆字节，这是我的硬盘的标准速度。谜团已揭开！

另请注意，您假设您拥有用于此过程的整个可用CPU。否则，可以简单地阻塞该进程，等待其他进程产生CPU。

strace仅显示进程由于系统调用进入（然后离开）内核的时间。或在传递unix信号时。但是，还有其他类型的中断strace根本不显示。所以这些包括

• 页面错误。
• 计时器中断。当当前进程用尽了它在CPU上分配的时间片时，可用于切换到其他进程。