☰

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

tag-icon • tag-icon performance time strace
为什么“strace”不显示该进程正在等待某些东西？

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

time foo显示foo运行需要几秒钟（“real”），但在用户空间（“user”）和内核（“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

答案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 MB，读取速度超过每秒 100 MB，这是像我这样的硬盘的标准速度。谜团已揭开！

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

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

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

相关内容