多线程降低了NUMA上的套接字吞吐量

Question

我在一台16核NUMA机器上用Red Had Linux对一个Java程序进行了基准测试。我测量了Java DatagramSocket(用于UDP)的吞吐量，即每秒能够接收和发送多少数据包(64字节大小)。这个程序由一个套接字和n个监听套接字的线程组成。当数据包到达时，它们会将有效负载复制到byte[]数组中，用该数组创建一个新的DatagramPacket，并直接将其发送回它的来源。可以把它想象成UDP层上的ping。

>

我发现，当使用多个线程（即两个或四个线程）时，Java DatagramSocket套接字的吞吐量要小得多。如果我只使用一个线程侦听套接字，那么我的吞吐量为每秒122000个数据包，而多个线程的吞吐量仅为每秒65000个数据包。现在，我知道线程可能会在NUMA机器的任何核心上执行，如果内存必须从一个节点传输到另一个节点，那么内存访问就会变得昂贵。然而，如果我有两个线程，那么只有一个线程应该在“错误”的内核上执行，而另一个线程仍然应该实现非常高的吞吐量。另一种可能的解释是Datagramsocket中的同步问题，但这些只是猜测。有人对真正的解释有很好的洞察力吗？

我发现在多个端口上多次（并行）执行此程序可以实现更高的总体吞吐量。我用一个线程启动了四次程序，每个程序在单独的端口（5683，5684，5685和5686）上使用套接字。这四个程序的总吞吐量为每秒 370，000 个数据包。总之，在同一端口上使用多个线程会降低吞吐量，而使用多个端口和一个线程会增加吞吐量。这怎么能解释呢？

系统规格：

硬件：2个AMD Opteron（TM）处理器6212处理器上的16个内核组织在4个节点中，每个节点具有32 GB RAM。频率：1.4 Ghz，2048 KB缓存。

node distances:
node   0   1   2   3
  0:  10  16  16  16
  1:  16  10  16  16
  2:  16  16  10  16
  3:  16  16  16  10

操作系统是Red Hat Enterprise Linux工作站版本6.4 (Santiago)，内核版本< code > 2 . 6 . 32-358 . 14 . 1 . el6 . x86 _ 64 。Java版本< code >“1 . 7 . 0 _ 09”，Java(TM) SE运行时环境(< code>build 1.7.0_09-b05)，Java HotSpot(TM) 64位服务器VM (build 23.5-b02，混合模式)，我使用了< code>-XX: UseNUMA标志。服务器和客户端通过10GB以太网连接。

Answer 1

一般来说，只使用一个线程时效率最高。将东西并行化将不明显地引入成本。只有当您可以并行执行的额外工作量超过此成本时，吞吐量的增加才会出现。

现在，阿姆达尔定律说明了吞吐量的理论增长与您的工作中有多少可以并行化/不能并行化有关。例如，如果您的任务只有50%是可并行化的，那么无论您在问题上投入多少线程，您都只能获得2倍的吞吐量增长。请注意，您在链接中看到的图表忽略了添加线程的成本。实际上，本机操作系统线程确实会增加相当多的成本，尤其是当许多线程试图访问共享资源时。

在您的例子中，当您只使用一个套接字时，大多数工作都不可并行化。因此，使用单个线程可以获得优异的性能，而添加线程会因为增加成本而使性能变得更差。在第二个实验中，通过使用多个套接字增加了可以并行处理的工作量。因此，尽管使用线程增加了一些成本，但您还是获得了吞吐量。