【问题标题】:Weird CPU usage: 100% utilization, but temperature abnormally low奇怪的 CPU 使用率:100% 使用率,但温度异常低
【发布时间】:2020-05-26 15:04:24
【问题描述】:

我的算法/cpu 遇到了奇怪的行为,我想知道是什么原因造成的。

我使用的 CPU:AMD 2990WX 32c/64t,操作系统:带有 4.15.0-64-generic 内核的 Ubuntu 18.04LTS。

算法(Julia 1.0.3):

@sync @distributed for var in range(0.1,step=0.1,stop=10.0)
                       res=do_heavy_stuff(var) #solves differential equation,
                                               #basically, multiplying 200x200 matrices many times
                       save(filename,"RES",res)
end

函数 do_heavy_stuff(var) 在单个 CPU 内核上需要大约 3 个小时来解决。 当我与 10 个进程并行启动它时 (julia -p 10 my_code.jl),每个并行循环需要大约 4 小时,这意味着每 4 小时我会保存 10 个文件。随着 CPU 频率从 4.1Ghz 下降到 3.4Ghz,预计会放缓。

如果我启动 3 个单独的实例,每个实例有 10 个进程,因此总 CPU 利用率为 30 个内核,一个循环周期仍需要约 4 小时,这意味着我每 4 小时完成 30 次运行并保存。

但是,如果我同时运行 2 个实例(一个为 0,另一个为 +10),每个实例有 30 个进程julia -p 30 my_code.jl,我看到(使用htop),CPU 利用率为 60(+)个线程,但算法变得非常慢(20 小时后仍保存零个文件)。此外,我发现 CPU 温度异常低(~45C 而不是预期的 65C)。

从这些信息中我可以猜到,使用(几乎)我的 cpu 的所有线程使它做一些无用的事情,消耗 CPU 周期,但没有进行浮点操作。我看不到 SSD 的 I/O,我只使用了一半的 RAM。

我启动了 mpstat mpstat -A:https://pastebin.com/c19nycsT 我可以看到我所有的核心都只是在空闲状态下冷却,这解释了低温,但是,我还是不明白 瓶颈到底是什么?我该如何从这里排除故障?有什么方法可以查看(不接触硬件)问题是 RAM 带宽还是其他问题?

编辑:我注意到我使用 mpstat 错误。显然 mpstat -A 给出了自计算机启动以来的 cpu 统计信息,而我需要的是可以使用 mpstat -P ALL 2 获得的短时间集成结果。不幸的是,我只是在我杀死有问题的代码后才知道这一点,所以 没有来自 mpstat 的真实数据。但是,我仍然感兴趣,如何解决这种情况,核心似乎在做某事,但结果没有显示?如何找到瓶颈?

【问题讨论】:

  • 请注意,您实际上是在运行多个 Julia 进程,而不是 线程
  • 是的,谢谢,我知道这一点以及资源的可分离性,您是在暗示,因此,我得到了太多的缓存未命中?
  • 不,我只是想指出您没有使用正确的术语。我不知道是什么可能导致您观察到的减速。
  • 当您在进程或线程上进行同步时,同步可能会导致除一个线程之外的所有线程都等到最后一个线程完成。您可能需要在代码执行中寻找资源争用或这样的全线程等待状态。发布一个简短但有效的问题示例可能会有所帮助。
  • 我编辑了问题以修正术语。我知道同步可能会使某些进程等待其他进程,但是根据我过去的同步经验,当进程等待时,它们不会在 htop 中显示为使用 CPU 周期。提供工作示例可能很容易,但是提供简短的工作示例即使不是不可能也非常困难。

标签: linux multithreading optimization julia cpu-usage


【解决方案1】:

由于您使用的是多处理,因此观察者行为最可能的原因有两个:

  • I/O 上的长时间延迟。当您处理大量磁盘数据或从网络读取数据时,您的进程自然会过时。在这种情况下,CPU 使用率可能较低且执行时间较长。
  • do_heavy_stuff 的执行时间差异很大。这种差异可能来自不稳定的 I/O 或不同的模型参数导致不同的执行时间。为什么这是一个问题需要了解@distributed 如何在工作进程之间共享工作负载。也就是说,每个工作人员都获得了一个相等的for 循环。例如,如果您有4 工人,第一个工人在0.1:0.1:2.5 范围内获得var,第二个工人2.6:0.1:5.0 等等。现在,如果某些var 值导致繁重的任务,那么第一个工人可能会得到 5 小时的工作,而其他工人可能会得到 1 小时的工作。这意味着@sync 在 5 小时后完成,只有一个 CPU 一直在实际工作。

看了你的帖子,我强烈认为第二个原因。

【讨论】:

  • 感谢您的回答。我认为我们可以排除您的第一个猜测,因为磁盘或网络没有 I/O。现在,考虑第二个建议。任务之间确实存在一些差异,但并没有那么大,此外,当使用类似的脚本时,我启动进程之间执行时间差异很大的任务时,我确实看到(htop)正在等待的进程没有使用 CPU 周期.因此,对于您建议的推理,这种行为并不典型。
  • 如果不亲身体验您的代码,我不相信可以提出更多建议。也许您可以尝试制作一个 MWE 来暴露不良行为?
猜你喜欢
  • 2017-10-03
  • 1970-01-01
  • 1970-01-01
  • 2017-08-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-27
  • 1970-01-01
相关资源
最近更新 更多