为什么`strace` 不显示这个进程正在等待什么？

Question

强者strace让我失望。这怎么可能？

---

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

所以它大部分时间都在等待其他东西，而不是执行 CPU 指令。通常，我可以看到它是如何等待的strace——即长时间阻塞的系统调用。不幸的是，这种方法不起作用。

strace -ttt -T -C -w foo显示系统调用、时间戳以及在系统调用中花费的（实际）时间的摘要。但是这个特定的过程显示在系统调用中花费的整体（真实）时间可以忽略不计。

---

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

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

Answer 1

遇到此问题的通常原因是进程因页面错误而阻塞。这些是通过内存映射（又名 ）执行的文件读取或可能写入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

major页面错误是需要文件系统 IO 的页面错误。 minor页面错误不太重要（可能只是“TLB 未命中”）。

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

所以这表示大约 290 兆字节，每秒读取超过 100 兆字节，这是像我这样的硬盘的标准速度。谜团已揭开！

另请注意，您假设您有一个完整的可用 CPU 用于此过程。否则，进程可能会被阻塞，等待其他进程让出 CPU。

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

• 页面错误。
• 定时器中断。这用于在当前进程耗尽其在 CPU 上分配的时间片时切换到不同的进程。