性能问题 : CPU intensive work performs better with more concurrency in Erlang

Question

tl;博士
当我以更高的并发性(例如一次 10K 与 4 次)执行 CPU 密集型任务时，我的 erlang 程序会获得更好的性能。为什么？

我正在使用 erlang 编写一个 map reduce 框架，并且我正在做性能测试。

我的 map 功能是高度 CPU 密集型的(主要是纯计算)。它还需要访问一些静态数据，所以我的机器上有一些持久的(即在应用程序生命周期中存在的)工作进程，每个进程在内存中都有一部分数据，并等待 map 请求。 map 的输出被发送到 manager 进程(它向 worker 发出 map 请求)，在那里执行 reduce(非常轻量级)。

无论如何，我注意到当我立即为工作人员收到的每个 map 请求生成一个新进程时，我获得了更好的吞吐量，而不是让工作进程本身一个一个地同步执行 map 请求(从而留下一堆的进程队列中的 map 请求，因为我一次触发所有 map 请求)。

代码片段:

%% When I remove the comment, I get significant performance boost (90% -> 96%)
%% spawn_link(fun()->
                %% One invocation uses around 250ms of CPU time
                do_map(Map, AssignedSet, Emit, Data),
                Manager ! {finished, JobId, self(), AssignedSet, normal},
%%       end),

与在紧密循环中执行相同计算时相比，使用“立即生成”方法(例如，完全并行运行的 10000 个 map reduce 作业)获得了 96% 的吞吐量(效率)。当我使用“ worker 一一执行”的方法时，我只能得到 90% 左右。

我知道 Erlang 应该擅长并发的东西，我印象深刻的是，即使我一次执行 10K map reduce 请求而不是 100 等，效率也不会改变!但是，由于我只有 4 个 CPU 内核，如果我使用 4 或 5 等较低的并发性，我希望获得更好的吞吐量。

奇怪的是，我的 CPU 使用率在 2 个不同的实现中看起来非常相似(在所有内核上几乎完全固定为 100%)。性能差异相当稳定。 IE。即使我只执行 100 个 map reduce 作业，我仍然可以通过“立即生成”方法获得大约 96% 的效率，而当我使用“一对一”方法时，效率大约为 90%。同样，当我测试 200、500、1000、10K 作业时。

我首先怀疑工作进程队列中的排队是罪魁祸首，但即使我应该在工作进程队列中只有 25 条消息，我仍然看到性能较低。 25 条消息对于导致阻塞来说似乎很小(我正在做选择性消息匹配，但不是过程必须将消息放回队列的方式)。

我不确定我应该如何从这里开始。我做错了什么，还是我完全错过了什么？

更新

我做了一些更多的测试，发现性能差异可以根据条件消失(特别是我划分静态数据的工作进程数量)。看来我还有很多东西要学!

Answer 1

假设有 1 个工作进程和 3 个 map 操作，我们有第一个变体:

  _______   _______   _______
 |   m   | |   m   | |   m   |
 |       | |       | |       |
_|       |_|       |_|       |_
a         a         a         r

哪里 a是管理任务(从消息队列读取，分发 map 等) m是实际 map 和 r正在发回结果。为每个 map 生成一个进程的第二个变体:

  _________________._
 |   m              r
 |  ___________________._
 | |   m                r
 | |  _____________________._
_|_|_|   m                  r
a a a

如您所见，管理任务( a )与 map ( m )和发回结果( r )同时进行。

这将使 CPU 一直忙于 map (即计算密集型)工作，而不是时不时地出现短暂下降。这很可能是您在吞吐量中看到的小幅增长。

由于您从一开始就具有相当高的并发性，因此您只会看到吞吐量的相对较小的增长。将此与理论上仅运行一个工作进程(如第一个变体)进行比较，您会看到更大的 yield 。