3

我有一个func在单核上运行时可能花费约 50 秒的功能。现在我想在一台多次获得 192 核 CPU 的服务器上运行它。但是当我添加工作进程时说，180，每个核心的性能都会变慢。最差的 CPU 需要大约 100 秒来计算func。

有人能帮助我吗？

这是伪代码

using Distributed
addprocs(180)
@everywhere include("func.jl") # defines func in every process

First try using only 10 workers

@sync @distributed for i in 1:10
    func()
end
@sync @distributed for i in 1:10
    @time func()
end

From worker #: 43.537886 seconds (243.58 M allocations: 30.004 GiB, 8.16% gc time)
From worker #: 44.242588 seconds (247.59 M allocations: 30.531 GiB, 7.90% gc time)
From worker #: 44.571170 seconds (246.26 M allocations: 30.338 GiB, 8.81% gc time)
...
From worker #: 45.259822 seconds (252.19 M allocations: 31.108 GiB, 8.25% gc time)
From worker #: 46.746692 seconds (246.36 M allocations: 30.346 GiB, 11.21% gc time)
From worker #: 47.451914 seconds (248.94 M allocations: 30.692 GiB, 8.96% gc time)

Seems not bad when using 10 workers
Now we use 180 workers

@sync @distributed for i in 1:180
    func()
end
@sync @distributed for i in 1:180
    @time func()
end

From worker #: 55.752026 seconds (245.20 M allocations: 30.207 GiB, 9.33% gc time)
From worker #: 57.031739 seconds (245.00 M allocations: 30.176 GiB, 7.70% gc time)
From worker #: 57.552505 seconds (247.76 M allocations: 30.543 GiB, 7.34% gc time)
...
From worker #: 96.850839 seconds (247.33 M allocations: 30.470 GiB, 7.95% gc time)
From worker #: 97.468060 seconds (250.04 M allocations: 30.827 GiB, 6.96% gc time)
From worker #: 98.078816 seconds (250.55 M allocations: 30.883 GiB, 10.87% gc time)

时间几乎从 55s 线性增加到 100s。

我通过top命令检查了 CPU 使用率可能不是瓶颈（“id”保持 >2%）。RAM 使用率也一样（使用了约 20%）。

其他版本信息：Julia 版本 1.5.3 平台信息：操作系统：Linux (x86_64-pc-linux-gnu) CPU：Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz

更新：

  1. 替代func最小示例（简单的 for 循环）不会改变减速。
  2. 将进程数减少到 192/2 可以缓解减速

新的伪代码是

addprocs(96)
@everywhere function ss()
    sum=0
    for i in 1:1000000000
        sum+=sin(i)
    end
end

@sync @distributed for i in 1:10
    ss()
end
@sync @distributed for i in 1:10
    @time ss()
end

From worker #: 32.8 seconds ..(8 others).. 34.0 seconds

...
@sync @distributed for i in 1:96
    @time ss()
end

From worker #: 38.1 seconds ..(94 others).. 45.4 seconds
4

1 回答 1

1

当从 10 个进程变为 180 个并行进程时，您正在测量每个工作人员执行func()并观察单个进程的性能下降的时间。

这对我来说看起来很正常：

  • 英特尔内核使用超线程，因此您实际上有 96 个内核（更详细地说 - 超线程内核仅增加 20-30% 的性能）。这意味着您的 168 个进程需要共享 84 个超线程内核，而 12 个进程获得完整的 12 个内核。
  • CPU 速度由油门温度（https://en.wikipedia.org/wiki/Thermal_design_power）决定，当然运行 10 个进程与 180 个进程相比有更多空间
  • 你的任务显然是在争夺内存。他们总共分配了超过 5TB 的内存，而你的机器却比这少得多。垃圾收集的最后一英里总是最昂贵的——因此，如果您的垃圾收集器受到挤压并争夺内存，则性能不平衡，垃圾收集时间长得惊人。

查看此数据，我建议您尝试：

addprocs(192 ÷ 2)

看看性能将如何变化。

于 2021-11-17T16:10:19.980 回答