【问题标题】:What are the reasons for elapsed time to greatly exceed user+kernel time?经过时间大大超过用户+内核时间的原因是什么?
【发布时间】:2011-10-18 17:29:38
【问题描述】:

我看到很多线程询问经过时间(墙上时间)小于用户+内核时间的情况,我了解多线程如何导致这种情况。但是,当通过以下方式定时执行某些 MPI 代码时:

$ time mpirun -n 4 ./a.out

我看到经过的时间范围为 4-5 分钟,用户时间约为 40 秒,内核时间约为 40 秒。我认为进程之间的屏障同步可能是原因的一部分,或者可能只是获取有关单个 MPI 进程的信息,但我仍然无法准确解释导致我的读数的原因。谁能解释一下?

非常感谢。

【问题讨论】:

  • 睡眠时间不属于用户时间和内核时间。线程可以在磁盘上等待、在网络上等待、在管道上等待、在互斥体上等待……

标签: time kernel mpi wall-time


【解决方案1】:

对于许多进程,我预计挂钟时间会大大超过总 CPU 时间。很少有进程受 CPU 限制,因此它们将花费大量时间等待。幸运的是,等待时间不再计入该过程。导致等待的事情:

  • 任何类型的 I/O(磁盘、网络、进程间管道等)。
  • 进程之间的资源同步。
  • 分配给其他进程的时间片。
  • 内存交换(现在不常见)。
  • 任何其他类型的中断都很好。

即使是重型统计软件也可能执行 I/O,这会导致 CPU 利用率低于挂钟时间。

一个极端的例子是将一个大文件从磁盘上的一个分区复制到同一个磁盘上的另一个分区。这可能会花费大量的 Wall 时间而 CPU 时间很少。如果您有能力使用ionice,则可以在磁盘忙于其他工作的情况下使 Wall time 更长。

以下命令显示的实际(挂钟)时间可能会明显高于用户和系统时间的总和。

time bash -c "read ans"

【讨论】:

    【解决方案2】:

    用户/内核时间仅在处理器使用时增加。如果您的代码主要在诸如磁盘或网络 IO 之类的东西上等待,那么实际经过的时间将远远大于 CPU 时间。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2015-05-22
      • 2012-01-12
      • 1970-01-01
      • 1970-01-01
      • 2017-11-19
      • 2016-05-07
      • 2017-11-23
      • 1970-01-01
      相关资源
      最近更新 更多