multithreading会降低NUMA上的套接字吞吐量

我使用Red Had Linux在16核心NUMA机器上testing了一个Java程序。 我测量了一个Java DatagramSocket（对于UDP）的吞吐量，就每秒能接收和发送多less个数据包（64字节大小）而言。 程序由一个socket和n个线程组成，这些线程正在socket上侦听。 当一个数据包到达时，他们会将有效载荷复制到一个byte []数组中，然后用该数组创build一个新的DatagramPacket，然后直接将其发送回来。 把它看作是UDP层上的一个ping。

我发现使用多个线程（即两个或四个）时，Java DatagramSocket套接字的吞吐量将显着降低。 如果我只使用一个线程来侦听套接字，则每秒吞吐量为122,000个，而多个线程每秒只能达到65,000个数据包。 现在，我知道一个线程可能会在NUMA机器的任何核心上执行，并且如果内存必须从一个节点移动到另一个节点，那么内存访问将变得非常昂贵。 但是，如果我有两个线程，只有一个线程应该在“错误”的核心上执行，而另一个线程仍然应该达到很高的吞吐量。 另一个可能的解释是Datagramsocket中的同步问题，但这只是猜测。 有什么真正的解释是有人有一个很好的洞察力？

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

系统规格：

如何在Linux中使用Perl中的fcgi的unix域套接字的抽象名称？

如何查看已打开套接字连接的进程的线程ID？

在Python 3中给出一个套接字和inode的进程ID

通过sendto（）的UDP广播在OS / X上返回“无法分配请求的地址”，但不是Linux

用于Linux（和Windows）的Async C ++通信库

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

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

操作系统是一个红帽企业Linux工作站版本6.4（圣地亚哥）与内核版本2.6.32-358.14.1.el6.x86_64 。 Java版本"1.7.0_09" ，JavaTM SE运行环境（ build 1.7.0_09-b05 ），Java HotSpot™64位服务器VM（ build 23.5-b02,mixed mode ），并且我使用了-XX:+UseNUMA标志。 服务器和客户端通过10GB以太网连接。

在Windows上的multithreading应用程序中阻塞服务器/侦听套接字的最佳方法？

绑定失败：地址已被使用

C + +套接字发送/ recv与写/读

多个TCP套接字，一个停滞

无法连接到StreamSocketListener

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

现在， Amdahl的定律说明了在你的工作中有多少是可并行/不可并行的东西，吞吐量的理论增益。 例如，如果只有50％的任务是可并行化的，那么不管有多少线程抛出问题，只能增加吞吐量x2。 请注意，您在链接中看到的图表忽略了添加线程的成本。 实际上，本地操作系统线程确实增加了相当多的成本， 当他们中的很多人试图访问共享资源。

在你的情况下，当你只使用一个套接字时，你的大部分工作是不可并行的。 因此，使用单个线程会带来更好的性能，添加线程会使其更糟，因为它们会增加成本。 在第二个实验中，通过使用多个套接字增加了可以并行化的工作。 因此，尽管通过使用线程增加了一些成本，但在吞吐量方面却增加