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

【问题标题】：Multithreading decreases socket throughput on NUMA多线程降低了 NUMA 上的套接字吞吐量
【发布时间】：2013-09-24 07:26:27
【问题描述】：

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

我发现，当使用多个线程（即两个或四个）时，Java DatagramSocket 套接字的吞吐量要小得多。如果我只使用一个线程来监听套接字，我可以实现每秒 122,000 个数据包的吞吐量，而多个线程只能实现每秒 65,000 个数据包的吞吐量。现在，我了解到线程可能会在 NUMA 机器的任何核心上执行，并且如果内存必须从一个节点传输到另一个节点，那么内存访问会变得很昂贵。但是，如果我有两个线程，那么只有一个应该在“错误”的核心上执行，而另一个应该仍然可以实现非常高的吞吐量。另一种可能的解释是 Datagramsocket 中的同步问题，但这些只是猜测。有没有人对真正的解释有很好的了解？
我发现在多个端口上多次（并行）执行该程序可以获得更高的整体吞吐量。我用一个线程启动程序四次，每个程序都使用一个单独端口（5683、5684、5685 和 5686）上的套接字。四个程序的总吞吐量为每秒 370,000 个数据包。总之，在同一个端口上使用多个线程会降低吞吐量，而在一个线程上使用多个端口会增加吞吐量。这怎么解释？

系统规格：

硬件：2 个 AMD Opteron(TM) 处理器上的 16 个内核 6212 个处理器组织在 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 Workstation 版本 6.4 (Santiago)，内核版本为 2.6.32-358.14.1.el6.x86_64。 Java 版本 "1.7.0_09"、Java(TM) SE 运行时环境 (build 1.7.0_09-b05)、Java HotSpot(TM) 64 位服务器 VM (build 23.5-b02, mixed mode)，我使用了 -XX:+UseNUMA 标志。服务器和客户端通过 10GB 以太网连接。

【问题讨论】：

您应该从提供基准测试代码开始。
我不明白您为什么要在诸如网络之类的非并行事物上测试并行性。尝试使用多个线程写入单个磁盘时，您会得到类似的结果。
你能用 4 个不同的套接字测试 4 个线程吗？我的猜测是它会明显优于 4 个线程/1 个套接字，但可能比 4 个进程/4 个套接字稍差。顺便说一句，DatagramSocket.receive() 是 synchronized。

标签： java linux multithreading sockets numa

【解决方案1】：

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

现在，Amdahl's law 说明了与您的工作中有多少是由可以并行化/不能并行化的内容组成的理论吞吐量增益。例如，如果您的任务只有 50% 是可并行化的，那么无论您为问题抛出多少线程，您都只能获得 x2 的吞吐量增加。请注意，您在链接中看到的图表忽略了添加线程的成本。实际上，本机操作系统线程确实增加了相当多的成本和特别是。当他们中的许多人试图访问共享资源时。

在您的情况下，当您只使用一个套接字时，您的大部分工作都无法并行化。因此，使用单线程可以提供卓越的性能，而添加线程会因为它们增加的成本而变得更糟。在您的第二个实验中，您通过使用多个套接字增加了可以并行化的工作。因此，尽管使用线程增加了一些成本，但您还是获得了吞吐量。

【讨论】：