Wor*_*ker 41 networking linux ubuntu kernel sysctl
我正在尝试通过“具有大量连接和小数据包高流量的千兆网络”来提高我的 TCP 吞吐量。我的服务器操作系统是 Ubuntu 11.10 Server 64bit。
大约有 50.000 个（并且还在不断增加）客户端通过 TCP 套接字（都在同一个端口上）连接到我的服务器。
我 95% 的数据包大小为 1-150 字节（TCP 标头和有效负载）。其余 5% 从 150 到 4096+ 字节不等。
使用下面的配置，我的服务器可以处理高达 30 Mbps（全双工）的流量。
您能否建议最佳实践以根据我的需要调整操作系统？
我的/etc/sysctl.cong看起来像这样：
kernel.pid_max = 1000000
net.ipv4.ip_local_port_range = 2500 65000
fs.file-max = 1000000
#
net.core.netdev_max_backlog=3000
net.ipv4.tcp_sack=0
#
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.somaxconn = 2048
#
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
#
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_mem = 50576 64768 98152
#
net.core.wmem_default = 65536
net.core.rmem_default = 65536
net.ipv4.tcp_window_scaling=1
#
net.ipv4.tcp_mem= 98304 131072 196608
#
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_rfc1337 = 1
net.ipv4.ip_forward = 0
net.ipv4.tcp_congestion_control=cubic
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
#
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_max_orphans = 8192
这是我的限制：
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 193045
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1000000
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 1000000
[添加]
我的网卡如下：
$ dmesg | grep Broad
[ 2.473081] Broadcom NetXtreme II 5771x 10Gigabit Ethernet Driver bnx2x 1.62.12-0 (2011/03/20)
[ 2.477808] bnx2x 0000:02:00.0: eth0: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem fb000000, IRQ 28, node addr d8:d3:85:bd:23:08
[ 2.482556] bnx2x 0000:02:00.1: eth1: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem fa000000, IRQ 40, node addr d8:d3:85:bd:23:0c
[添加 2]
ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off
[添加 3]
sudo ethtool -S eth0|grep -vw 0
NIC statistics:
[1]: rx_bytes: 17521104292
[1]: rx_ucast_packets: 118326392
[1]: tx_bytes: 35351475694
[1]: tx_ucast_packets: 191723897
[2]: rx_bytes: 16569945203
[2]: rx_ucast_packets: 114055437
[2]: tx_bytes: 36748975961
[2]: tx_ucast_packets: 194800859
[3]: rx_bytes: 16222309010
[3]: rx_ucast_packets: 109397802
[3]: tx_bytes: 36034786682
[3]: tx_ucast_packets: 198238209
[4]: rx_bytes: 14884911384
[4]: rx_ucast_packets: 104081414
[4]: rx_discards: 5828
[4]: rx_csum_offload_errors: 1
[4]: tx_bytes: 35663361789
[4]: tx_ucast_packets: 194024824
[5]: rx_bytes: 16465075461
[5]: rx_ucast_packets: 110637200
[5]: tx_bytes: 43720432434
[5]: tx_ucast_packets: 202041894
[6]: rx_bytes: 16788706505
[6]: rx_ucast_packets: 113123182
[6]: tx_bytes: 38443961940
[6]: tx_ucast_packets: 202415075
[7]: rx_bytes: 16287423304
[7]: rx_ucast_packets: 110369475
[7]: rx_csum_offload_errors: 1
[7]: tx_bytes: 35104168638
[7]: tx_ucast_packets: 184905201
[8]: rx_bytes: 12689721791
[8]: rx_ucast_packets: 87616037
[8]: rx_discards: 2638
[8]: tx_bytes: 36133395431
[8]: tx_ucast_packets: 196547264
[9]: rx_bytes: 15007548011
[9]: rx_ucast_packets: 98183525
[9]: rx_csum_offload_errors: 1
[9]: tx_bytes: 34871314517
[9]: tx_ucast_packets: 188532637
[9]: tx_mcast_packets: 12
[10]: rx_bytes: 12112044826
[10]: rx_ucast_packets: 84335465
[10]: rx_discards: 2494
[10]: tx_bytes: 36562151913
[10]: tx_ucast_packets: 195658548
[11]: rx_bytes: 12873153712
[11]: rx_ucast_packets: 89305791
[11]: rx_discards: 2990
[11]: tx_bytes: 36348541675
[11]: tx_ucast_packets: 194155226
[12]: rx_bytes: 12768100958
[12]: rx_ucast_packets: 89350917
[12]: rx_discards: 2667
[12]: tx_bytes: 35730240389
[12]: tx_ucast_packets: 192254480
[13]: rx_bytes: 14533227468
[13]: rx_ucast_packets: 98139795
[13]: tx_bytes: 35954232494
[13]: tx_ucast_packets: 194573612
[13]: tx_bcast_packets: 2
[14]: rx_bytes: 13258647069
[14]: rx_ucast_packets: 92856762
[14]: rx_discards: 3509
[14]: rx_csum_offload_errors: 1
[14]: tx_bytes: 35663586641
[14]: tx_ucast_packets: 189661305
rx_bytes: 226125043936
rx_ucast_packets: 1536428109
rx_bcast_packets: 351
rx_discards: 20126
rx_filtered_packets: 8694
rx_csum_offload_errors: 11
tx_bytes: 548442367057
tx_ucast_packets: 2915571846
tx_mcast_packets: 12
tx_bcast_packets: 2
tx_64_byte_packets: 35417154
tx_65_to_127_byte_packets: 2006984660
tx_128_to_255_byte_packets: 373733514
tx_256_to_511_byte_packets: 378121090
tx_512_to_1023_byte_packets: 77643490
tx_1024_to_1522_byte_packets: 43669214
tx_pause_frames: 228
关于 SACK 的一些信息：何时关闭 TCP SACK？
Nil*_*ils 21
问题可能是您的网卡中断次数过多。如果带宽不是问题，那么频率就是问题：
打开网卡上的发送/接收缓冲区
ethtool -g eth0
将显示当前设置（256 或 512 个条目）。您可能可以将这些提高到 1024、2048 或 3172。更多可能没有意义。这只是一个环形缓冲区，只有在服务器无法足够快地处理传入数据包时才会填满。
如果缓冲区开始填满，流量控制是告诉路由器或交换机放慢速度的另一种方法：
在服务器和它所连接的交换机/路由器端口上打开进/出流控制。
ethtool -a eth0
大概会显示：
Pause parameters for eth0:
Autonegotiate: on
RX: on
TX: on
检查 /var/log/messages 以获取 eth0 的当前设置。检查类似的东西：
eth0：链路以 1000 Mbps 速度运行，全双工，流量控制 tx 和 rx
如果您没有看到 tx 和 rx，您的网络管理员必须调整交换机/路由器上的值。在 Cisco 上，这是接收/传输流控制。
注意：更改这些值将使您的链接在很短的时间内（少于 1 秒）关闭和打开。
如果所有这些都没有帮助 - 您还可以将网卡的速度降低到 100 MBit（在交换机/路由器端口上做同样的事情）
ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
但是在您的情况下，我会说 - 提高 NIC 环形缓冲区中的接收缓冲区。
以下可能不是最终答案，但肯定会提出一些想法
尝试将这些添加到 sysctl.conf
## tcp selective acknowledgements.
net.ipv4.tcp_sack = 1
##enable window scaling
net.ipv4.tcp_window_scaling = 1
##
net.ipv4.tcp_no_metrics_save = 1
而选择性 tcp ack 有利于在高带宽网络的情况下获得最佳性能。但要注意其他缺点。此处描述了窗口缩放的好处。至于第三个sysctl选项：默认情况下，TCP在连接关闭时将各种连接度量保存在路由缓存中，以便近期建立的连接可以使用这些来设置初始条件。通常，这会提高整体性能，但有时可能会导致性能下降。如果设置，TCP 将不会在关闭连接时缓存指标。
检查
ethtool -k ethX
查看是否启用了卸载。今天的大多数以太网 NIC 都支持TCP 校验和卸载和大段卸载，显然Broadcom也支持它。
尝试使用工具
powertop
当网络空闲和达到网络饱和时。这肯定会表明 NIC 中断是否是罪魁祸首。设备轮询是对这种情况的一种回答。FreeBsd 在 ifconfig 中支持轮询开关，但 linux 没有这样的选项。请参阅此以启用轮询。据说 BroadCom 还支持投票，这对您来说是个好消息。
由于您提到您的流量主要由小数据包组成，因此巨型数据包调整可能不会为您解决问题。但是，嘿，还是试试吧！