原文链接:How to receive a million packets per second
译文链接:每秒如何接收上百万数据包
译者:曾越
上周聊天的时候,我无意间听到一个同事说:"Linux网络堆栈(Linux network stack)太慢了!你不能指望它用一个CPU每秒处理50000个以上的数据包!"
这引发了我深深的思考。我认同每个核心50kpps对任何实际的应用来说可能就是极限了,但Linux网络堆栈的能力只是如此吗?让我们换个角度来更有趣的叙述这件事。
在Linux系统中,写一个能每秒接收1000000 UDP数据包的程序有多难?
我希望,回答这个问题的过程,也能成就一篇关于现代网络堆栈设计的优秀教程。
首先,让我们假设:
- ● 测量数据包每秒(packets per second 缩写pps)比测量字节每秒(bytes per second简写Bps)更有意义。你可以通过优化管道(piplelining)和发送更长的数据包来实现高Bps。但提高pps比这难得多。
- ● 既然我们对pps更感兴趣,我们的实验将会使用短UDP消息(short UDP messages)。更准确的说:32字节的UDP负载(UDP payload)。在以太网层(Ethernet layer)中是74字节。
- ● 在实验中我们会使用两个物理服务器:接受端(receiver)和发送端(sender)。
- ● 它们都配有2个6核2GHz的Xeon处理器。如果在每个核心上启用超线程技术(hyperthreading),则可分别模拟24个处理器。核心有一块Solarflare公司的多队列10G网卡(multi-queue 10G network card),已经配置了11个接收队列(receive queue)。更详细的之后讨论。
- ● 测试程序的源码可以从这里得到: udpsender, udpreceiver。
准备 Prerequisites
4321端口给UDP数据包。在开始之前,我们必须确保通信不会被iptables干扰。
1
2
|
receiver$ iptables -I INPUT 1 -p udp --dport 4321 -j ACCEPT
receiver$ iptables -t raw -I PREROUTING 1 -p udp --dport 4321 -j NOTRACK
|
为了一会儿方便,先定义一些具体的的IP地址:
1
2
3
4
|
receiver$
for
i
in
`seq 1 20`;
do
\
ip addr add 192.168.254.$i/24 dev eth2; \
done
sender$ ip addr add 192.168.254.30/24 dev eth3
|
1.简单方法 The naive approach
一开始先让我们做个最简单的实验。一次简单的发送和接收会传递多少个数据包呢?
发送者的伪代码:
1
2
3
4
5
|
fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
fd.bind((
"0.0.0.0"
, 65400))
# select source port to reduce nondeterminism
fd.connect((
"192.168.254.1"
, 4321))
while
True:
fd.sendmmsg([
"\x00"
* 32] * 1024)
|
尽管我们可以使用常用的send系统调用,但它并不高效。内核的上下文切换将会有不小的消耗,最好极力避免它。幸运的是,一个方便的系统调用最近被加入到了Linux中:sendmmsg。它允许我们一次发送大量的数据包。让我们来试试1024个数据包。
接受者的伪代码:
1
2
3
4
5
|
fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
fd.bind((
"0.0.0.0"
, 4321))
while
True:
packets = [None] * 1024
fd.recvmmsg(packets, MSG_WAITFORONE)
|
类似地, recvmmsg也是recv系统调用的高效版本。
让我们试一试:
1
2
3
4
5
6
7
8
9
10
|
sender$ ./udpsender 192.168.254.1:4321
receiver$ ./udpreceiver1 0.0.0.0:4321
0.352M pps 10.730MiB / 90.010Mb
0.284M pps 8.655MiB / 72.603Mb
0.262M pps 7.991MiB / 67.033Mb
0.199M pps 6.081MiB / 51.013Mb
0.195M pps 5.956MiB / 49.966Mb
0.199M pps 6.060MiB / 50.836Mb
0.200M pps 6.097MiB / 51.147Mb
0.197M pps 6.021MiB / 50.509Mb
|
使用这种简单方法,我们可以达到197kpps和350kpps之间。不算太糟。不幸的是,并不稳定。内核会使我们的程序在CPU核心之间shuffle。给CPU固定进程会有些作用:
1
2
3
4
5
6
7
8
|
sender$ taskset -c 1 ./udpsender 192.168.254.1:4321
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.362M pps 11.058MiB / 92.760Mb
0.374M pps 11.411MiB / 95.723Mb
0.369M pps 11.252MiB / 94.389Mb
0.370M pps 11.289MiB / 94.696Mb
0.365M pps 11.152MiB / 93.552Mb
0.360M pps 10.971MiB / 92.033Mb
|
现在,内核调度程序(kernel scheduler)把进程固定在指定的CPU上了。这改善了处理器缓存本地化(processor cache locality),使数据更稳定,这正是我们想要的。
2.发送更多的数据包 Send more packets
虽然370k pps对简单的程序并不算太糟,但离1Mpps的目标还很远。接受更多必然要发送更多。用2个独立的线程发送试试:
1
2
3
4
5
6
7
|
sender$ taskset -c 1,2 ./udpsender \
192.168.254.1:4321 192.168.254.1:4321
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.349M pps 10.651MiB / 89.343Mb
0.354M pps 10.815MiB / 90.724Mb
0.354M pps 10.806MiB / 90.646Mb
0.354M pps 10.811MiB / 90.690Mb
|
接受端的数量并没有增长。ethtool –S命令可以展示数据包的去向:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
receiver$ watch
'sudo ethtool -S eth2 |grep rx'
rx_nodesc_drop_cnt: 451.3k/s
rx-0.rx_packets: 8.0/s
rx-1.rx_packets: 0.0/s
rx-2.rx_packets: 0.0/s
rx-3.rx_packets: 0.5/s
rx-4.rx_packets: 355.2k/s
rx-5.rx_packets: 0.0/s
rx-6.rx_packets: 0.0/s
rx-7.rx_packets: 0.5/s
rx-8.rx_packets: 0.0/s
rx-9.rx_packets: 0.0/s
rx-10.rx_packets: 0.0/s
|
通过以上统计,NIC说明成功传递大约350kpps到RX-4号队列。 rx_nodesc_drop_cnt 是一个Solarflare公司特制的计数器,它报告NIC传送到内核时丢失450kpps。有时数据包传送失败的原因很隐晦。在我们的例子里它倒是很显眼:RX-4号队列传送数据包到CPU#4。CPU#4除了读取这350kpps的数据外,已经什么都做不了了。在htop中看看效果:
传统地,网卡有一个用于在硬件和内核间传递数据包的RX队列。这个设计有明显的局限性——数据包的传送量不能超过一个CPU的处理上限。为了更好的利用多核系统,NIC开始支持多RX队列。设计很简单:每一个RX队列绑定一个单独的CPU,这样传送数据包给所有的RX队列,NIC就可以利用所有的CPU资源。但有一个问题:给定一个数据包,NIC如何确定推送到哪一个RX队列呢?
不能使用Round-robin均衡,因为它可能会把一个连接中的数据包重排序。一个替代方案是:通过数据包的hash来决定RX队列。hash来自元组(源IP,目的IP,源端口,目的端口)。这能保证一个流中的数据包总是在同一个RX队列中结束,不可能发生某个流中的数据包重排序。
在我们的例子中,hash可以这样使用:
1
|
RX_queue_number = hash(
'192.168.254.30'
,
'192.168.254.1'
, 65400, 4321) % number_of_queues
|
多队列哈希算法 Multi-queue hashing algorithms
哈希算法可以使用ethtool设置。我们的设置如下:
1
2
3
4
|
receiver$ ethtool -n eth2 rx-flow-hash udp4
UDP over IPV4 flows use these fields
for
computing Hash flow key:
IP SA
IP DA
|
以上的意思是:对IPV4的UDP数据包,NIC将计算哈希(源IP,目的IP)地址。例如:
1
|
RX_queue_number = hash(
'192.168.254.30'
,
'192.168.254.1'
) % number_of_queues
|
因忽略了端口参数,这相当受限。大部分NIC允许自定义哈希方法。再使用ethtool选择元组(源IP,目的IP,源端口,目的端口)计算哈希:
1
2
|
receiver$ ethtool -N eth2 rx-flow-hash udp4 sdfn
Cannot change RX network flow hashing options: Operation not supported
|
不幸的是,我们的NIC不支持——我们只好使用受限的(源IP,目的IP)哈希。
非一致性内存访问性能注意事项 A note on NUMA performance
目前为止,我们所有的数据流都分配给了一个RX队列,并且只匹配一个CPU。让我们以此为基础,来试试多CPU。在我们的配置中,接收端主机有两个单独的进程“仓库“,它们各是一个NUMA节点。
我们将一个单线程接收端固定到4个CPU中的1个。四种情况分别是:
- 1.在另一个CPU上运行接收端,但在同一个用于RX队列的NUMA节点上。如上文所述,性能大概是360kpps。
- 2.使用同一个用于RX队列的CPU,性能大约是430kpps。但这很不稳定。如果NIC被数据包淹没了,性能可能会为0。
- 3.当接收端运行在处理RX队列的CPU的HT部分,性能大概是平时的一半,也就是200kpps。
- 4.当接收者在CPU和RX队列分别在不同的NUMA节点运行时,我们得到大致330kpps的数值。虽然这个数字不总是一致。
3.多重接收IP Multiple receive IPs
因为哈希算法在我们的NIC上受限,唯一的解决方法是:跨RX队列,把数据包分发到不同的IP地址。下面是如何发送数据包到不同的目的IP:
1
|
sender$ taskset -c 1,2 ./udpsender 192.168.254.1:4321 192.168.254.2:4321
|
使用ethtool确保数据包分配给不同的RX队列:
1
2
3
4
5
6
7
8
9
10
11
12
|
receiver$ watch
'sudo ethtool -S eth2 |grep rx'
rx-0.rx_packets: 8.0/s
rx-1.rx_packets: 0.0/s
rx-2.rx_packets: 0.0/s
rx-3.rx_packets: 355.2k/s
rx-4.rx_packets: 0.5/s
rx-5.rx_packets: 297.0k/s
rx-6.rx_packets: 0.0/s
rx-7.rx_packets: 0.5/s
rx-8.rx_packets: 0.0/s
rx-9.rx_packets: 0.0/s
rx-10.rx_packets: 0.0/s
|
接收部分:
1
2
3
4
|
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.609M pps 18.599MiB / 156.019Mb
0.657M pps 20.039MiB / 168.102Mb
0.649M pps 19.803MiB / 166.120Mb
|
万岁!两个核心全力处理RX队列,第三个运行应用,已达到了650Kpps!
将流量分发到3-4个RX队列就可以进一步增加这个数字,但应用会遇到另一个瓶颈。这次rx_nodesc_drop_cnt没有增长,对应的netstat“接收者错误”:
1
2
3
4
5
6
7
8
9
|
receiver$ watch
'netstat -s --udp'
Udp:
437.0k/s packets received
0.0/s packets to unknown port received.
386.9k/s packet receive errors
0.0/s packets sent
RcvbufErrors: 123.8k/s
SndbufErrors: 0
InCsumErrors: 0
|
上面这段话指出,虽然NIC能够传递数据包给内核,但内核不能够将数据包发送给应用。在我们的例子中,只成功发送了440kpps,其余的390kpps+123kpps被丢弃了,因为应用不足以接收他们。
4. 多线程接收 Receive from many threads
我们需要扩展接收端应用的能力。最初的、多线程的接收方法不会再有效了:
1
2
3
4
5
6
|
sender$ taskset -c 1,2 ./udpsender 192.168.254.1:4321 192.168.254.2:4321
receiver$ taskset -c 1,2 ./udpreceiver1 0.0.0.0:4321 2
0.495M pps 15.108MiB / 126.733Mb
0.480M pps 14.636MiB / 122.775Mb
0.461M pps 14.071MiB / 118.038Mb
0.486M pps 14.820MiB / 124.322Mb
|
接收性能相比单线程程序要低。是因为在UDP接收缓冲区(UDP receive buffer side)出现的锁竞争(lock contention)。因为所有的线程使用同一个socket描述符(socket descriptor),它们在从UDP接收缓冲区获得锁的步骤上花费了不相称的时间(disproportionate amount of time)。 这里详细描述了这个问题。
使用多线程从一个描述符接收数据并不理想。
5. SO_REUSEPORT
幸运的是,最近有一项成果增加到了Linux中:SO_REUSEPORT标志位。当在socket描述符上设置这个标志位时,Linux会允许多个进程绑定在同一个端口上。真实情况是,无论多少进程都将被允许绑定,且负载会被分担。
设置 SO_REUSEPORT 的每个进程都会有一个独立的socket描述符。因此他们得到了一个专属UDP接收缓存(dedicated UDP receive buffer)。这就避免了之前遇到的竞争问题。
1
2
3
4
|
receiver$ taskset -c 1,2,3,4 ./udpreceiver1 0.0.0.0:4321 4 1
1.114M pps 34.007MiB / 285.271Mb
1.147M pps 34.990MiB / 293.518Mb
1.126M pps 34.374MiB / 288.354Mb
|
这才像样!吞吐量现在不错了!
如果你继续研究,还会有更大的改进空间。即使我们开了4个接收线程,负载也没有被平均分配到上面。
2个线程接收了所有的数据,另外2个没有获得数据包。这应该是哈希冲突造成的,但这次问题出在SO_REUSEPORT 层。
结语 Final words
我又做了一些额外测试,完美的分配RX队列并将所有的接收线程都运行在一个NUMA节点上的话,可以达到1.4Mpps的性能。接收者运行在不同的NUMA节点上,即使性能略有下降,但也完成了1Mpps的目标。
总结一下,如果你想要完美的性能,你需要:
- ● 保证流量被均分到每一个RX 队列和SO_REUSEPORT进程上。实践中,只要有大量的连接(流)负载,通常它们是能均匀分布的。
- ● 你需要有足够的空闲CPU才能从内核中获取数据包。
- ● 为了使性能更棒,RX队列和接收进程应该在一个NUMA节点上。
-------------------好久不见的分割线-------------------
如果您发现这篇译文的任何问题,可随时与我们联系。
我们水平有限,但理想高远。我们旨在分享优质的内容。
我们也同样期待理想的您对这个世界的贡献。欢迎任何目的的联系。
我们的邮箱是:weikan@jointforce.com。
我们的QQ是:3272840549。
[转载请保留原文出处、译者和审校者。
可以不保留我们的链接]