企业官网建设流程全解析

跑过服务器和网卡的人，基本都绕不开 iperf3 这个工具。最近手头一批机器用的网讯 WX1860AL4 四口千兆网卡，测试时发现明明规格上写着线速转发，实际带宽却始终跑不满，甚至出现断崖式掉速。折腾了两三天，换了系统、换了内核参数、甚至怀疑过交换机和网线，最后才把问题定位清楚。这里直接把排查过程整理出来，如果你也在用 WX1860AL4 或者类似的国产网卡，大概率能少走不少弯路。

先说结论：WX1860AL4 本身性能并不差，iperf3 测速不达标通常不是硬件体质问题，而是测试方法、驱动参数、中断处理、流表特征这几类因素叠加导致。下面拆开讲。

1. 先搞清楚 WX1860AL4 是什么档次的卡

1.1 芯片定位与硬件规格

WX1860AL4 是网讯（Net-Swift）面向服务器和高端桌面市场推出的一款四口千兆网卡，主控芯片内部集成四个 MAC 和四个 PHY，支持 PCIe 2.0 x4 接口。注意这个接口规格，理论上 PCIe 2.0 x4 的带宽是 2GB/s 左右（单向约 2GB/s，双向共享），而四个千兆口全双工同时跑满也才 4Gbps，也就是 500MB/s，所以接口本身不会成为瓶颈，真正的瓶颈往往在别处。

这款卡的卖点主要是国产化替代场景里常见的“自主可控”需求，所以金融、政企、运营商这类对供应链安全敏感的客户用得比较多。它的驱动在 Linux 内核里已经有原生支持，主线内核从 4.x 开始就包含了wx驱动，这也是当初选它的原因之一——省去了自己编译驱动的麻烦。

不过国产网卡有一个通病：硬件设计和国外成熟方案有一些差异，尤其体现在描述符管理、中断合并、流表缓存这些细节上。这些差异平时感觉不到，一旦用 iperf3 这种“打满带宽”的工具去压测，问题就会暴露。

1.2 iperf3 测速的核心逻辑与常见误区

iperf3 的工作原理其实很简单：客户端往服务端发包，服务端统计接收速率，然后反过来再做一轮。关键是它的默认行为会影响测试结果，很多人上来直接iperf3 -s和iperf3 -c <ip>就跑，这样测出来的数据参考价值很低。

iperf3 默认是单线程 TCP 流。单线程意味着只有一个 CPU 核在处理收包、校验、拷贝、协议栈处理这一整条链路。如果机器 CPU 主频不高，或者中断没有分散到多个核心，单线程很容易跑不满。这也是为什么很多“网卡性能不达标”的案例，最后都指向了 CPU 绑核和中断亲和性问题，而不是网卡本身。

另外 iperf3 的默认窗口大小和缓冲区设置也偏保守。默认 TCP 窗口在长肥网络（高带宽高延迟）下会限制吞吐，虽然千兆局域网延迟很低，但默认 socket buffer 仍然可能成为瓶颈。下面会给出具体参数。

还有一点容易被忽略：iperf3 的客户端和服务端版本要一致。iperf3 的协议在 3.0 之后有过调整，3.0 和 3.1 之间、3.1 和 3.9 之间都出现过兼容性问题，严重的时候握手直接失败，或者测出来的数字异常偏低。优先用发行版自带的版本，或者统一用源码编译的同一版本。

2. 测试环境搭建与基准方法

2.1 硬件连接与拓扑选择

在排查“性能不达标”之前，先把测试拓扑理顺。我当时用的是两台同配置的服务器，分别插了一张 WX1860AL4，通过六类网线直连，不经过交换机。

直连的好处是排除交换机转发、端口协商、广播风暴这些变量，让 iperf3 的测试结果只反映网卡和协议栈的真实水平。如果直连都跑不满，再考虑换交换机测试；如果直连能跑满，那你遇到的可能不是网卡问题，而是交换机端口或 VLAN 配置问题。

网线选择也有讲究。千兆网卡虽然用五类线也能协商到 1000M，但线材质量差会导致误码率升高，TCP 重传率上升，最终表现为吞吐量波动。建议用六类或超六类成品线，长度不要太长，我测试时用的是一米左右的短线。如果是长距离布线环境，还要检查水晶头压接质量和线序是否标准。

2.2 系统配置与驱动版本确认

系统层面，我当时用的是 Debian 12，内核版本 6.1 LTS。先确认驱动是否加载正常：

lspci -nn | grep -i ethernet dmesg | grep -i wx ethtool -i enp3s0

正常会看到类似driver: wx的输出，固件版本、总线信息都能从ethtool -i里读到。如果驱动没加载，检查内核配置里是否开启了CONFIG_WX，或者手动modprobe wx试试。

然后是队列和中断的初始状态：

ethtool -l enp3s0

WX1860AL4 支持多队列，默认可能只开了单队列。如果这里显示Combined只有 1，那性能一定上不去，因为所有包都挤在一个队列里，由同一个 CPU 核处理。后面会讲怎么调整。

还有个容易踩的坑：BIOS 里的 ASPM（电源管理）默认可能是开启的。网卡进入低功耗状态后，唤醒和恢复会引入延迟，影响小包转发和 TCP 吞吐。建议在 BIOS 里把 PCIe ASPM 设为禁用，或者通过内核参数pcie_aspm=off关闭。

2.3 基准测试命令与预期指标

测试前先把服务器时间同步好，关闭防火墙，或者放行 5201 端口：

systemctl stop nftables # 或者针对 5201 端口放行

服务端启动：

iperf3 -s -p 5201 -i 1

客户端测试 TCP：

iperf3 -c <server-ip> -p 5201 -t 60 -i 1 -P 4 -w 1M

这里-P 4表示同时开 4 个 TCP 流，-w 1M把 socket 缓冲区设为 1MB。千兆网卡的合理预期是单流能跑 900Mbps 以上，多流能到 940Mbps 左右（刨去 TCP/IP 头开销后的上限）。

如果单流只有 500~700Mbps，多流能到 900Mbps，基本可以判定是单核或中断问题；如果多流也上不去，那就要往驱动参数、硬件链路、PCIe 带宽分配这些方向查。

UDP 测试也要做一轮，因为 UDP 能更直接地反映网卡的收包能力：

iperf3 -c <server-ip> -p 5201 -u -b 1000M -t 60 -i 1

UDP 测试要看两个指标：接收带宽和丢包率。如果带宽达标但丢包率很高，说明网卡中断处理不过来，或者 CPU 没有及时把包从环形缓冲区取走，是典型的“CPU 瓶颈”信号。

3. 影响性能的五个核心原因

3.1 驱动参数未优化：队列与中断合并是关键

WX1860AL4 的wx驱动默认行为偏保守，尤其在中断合并（coalescing）和队列数量上。先说队列。

使用ethtool -l查看组合队列数：

ethtool -l enp3s0

如果最大支持 8 队列但当前只开了 1，就需要手动提升：

ethtool -L enp3s0 combined 8

这个命令要把网卡先 down 再 up 才能生效，所以最好放在脚本里执行，或者写入 systemd service 保证开机自动配置。

队列数量提升后，还要把中断绑定到不同的 CPU 核心上。查看中断号：

cat /proc/interrupts | grep enp3s0

然后用irqbalance自动分配，或者手动写/proc/irq/<irq>/smp_affinity。手动绑定的典型做法是把 8 个队列的中断分别绑到 0~7 号 CPU 上，注意不要绑定到 CPU0，因为 CPU0 要处理时钟中断和系统管理中断，负担已经很重。

中断合并参数也很关键。ethtool -c enp3s0可以看到当前配置，重点看rx-usecs和tx-usecs。默认值如果过大，网卡会攒一批包再触发中断，增加延迟；如果过小，中断频率太高，CPU 空转率上升，吞吐反而下降。

我测试后觉得比较合适的组合是：

ethtool -C enp3s0 rx-usecs 15 tx-usecs 15

这个值在延迟和吞吐之间比较平衡。如果是纯带宽测试，可以适当加大到 30~50，吞吐能再高一点；如果是延迟敏感的应用，建议改小到 8 左右。

3.2 中断处理与 CPU 亲和性设置不当

队列数量调上去了，中断也分散了，但 CPU 亲和性如果设置不对，照样跑不满。这里有一个很多人忽略的细节：iperf3 客户端进程本身也要绑核。

我实测过一种情况：网卡中断分散到了 CPU2~CPU9，但 iperf3 进程被调度到了 CPU0，结果收包中断在 CPU2 处理，应用进程在 CPU0，两个核之间频繁进行 cache line 同步，性能损失非常大。

解决方法是用taskset把 iperf3 绑到处理网卡中断的同一个 CPU 核或同簇（比如同一个 LLC）的核上：

taskset -c 2 iperf3 -s taskset -c 2 iperf3 -c <server-ip> -t 60

这样中断和应用进程在同一核上，数据路径最短。不过要注意，iperf3 的收发模型里，真正耗 CPU 的是协议栈处理，所以把进程绑到接收队列对应的核上效果最明显。

服务端测试多流时，可以用-A参数，让 iperf3 自动把多个流分配到不同核：

iperf3 -c <server-ip> -P 8 -A 0,1,2,3,4,5,6,7

当然前提是 CPU 有这么多物理核或超线程可用。多流情况下，每个流绑定不同核，能避免所有流争抢同一个核导致的自锁。

3.3 中断合并参数与吞吐延迟平衡

关于中断合并，上面已经提了基本设置，这里补充一个细节：ethtool -C还有一些更细的参数，比如rx-frames（攒够多少个帧再中断）和adaptive-rx（自适应中断合并）。默认情况下自适应中断合并可能是关闭的，手动开启后网卡会根据流量动态调整中断频率：

ethtool -C enp3s0 adaptive-rx on adaptive-tx on

我在 WX1860AL4 上试过开启 adaptive 模式，单流 TCP 吞吐有小幅提升，但延迟抖动变大了。如果跑的是视频传输这种大包长流，问题不大；如果是金融交易这种低延迟场景，还是关闭 adaptive，手动固定参数更可控。

另外一个隐蔽问题是 GRO（Generic Receive Offload）和 LRO（Large Receive Offload）的状态。用ethtool -k enp3s0查看：

ethtool -k enp3s0 | grep -E "generic-receive-offload|large-receive-offload"

GRO 默认开启是好事，能合并小包减少中断次数。但某些国产网卡的驱动对 GRO 支持不完善，开启后反而出现丢包或吞吐下降。你可以用ethtool -K enp3s0 gro off临时关闭对比测试。如果关闭后吞吐明显提升，说明驱动对 GRO 的实现还有问题，这种情况最好保持关闭，同时去驱动社区反馈 bug。

3.4 TCP 协议栈与系统参数瓶颈

iperf3 测速跑不满，很多时候锅不在网卡，而在系统默认的 TCP 参数。千兆网卡考验的是整条数据通路，socket 缓冲区任何一个环节卡住，吞吐就上不去。

如果客户端iperf3 -c加了-w 1M但服务端没有同步调整，两端 socket 缓冲不一致，实际吞吐会被低的一端限制。更稳妥的做法是在两端同时设置系统级参数：

sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_max=16777216 sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216" sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

这里把最大接收/发送缓冲区都提到 16MB，TCP 自动协商窗口的上下限也放宽。对于千兆网络，16MB 可能有点奢侈，但至少不会成为瓶颈。

还有一个参数容易被忽略：net.core.netdev_max_backlog。它控制网卡驱动把包递给内核协议栈之前，队列里能积压多少包。突发流量下如果这个值太小，驱动只能丢包。默认值通常是 1000，建议调大：

sysctl -w net.core.netdev_max_backlog=5000

如果是 UDP 测试丢包，这个参数尤其有效。

最后，tcp_congestion_control在局域网高带宽环境也有影响。默认的 cubic 在低延迟高带宽下已经够用，但也可以试试 bbr：

sysctl -w net.ipv4.tcp_congestion_control=bbr

注意 bbr 需要内核支持（4.9+），而且它是基于延迟探测的算法，在某些交换机缓冲较小的情况下，表现反而可能不如 cubic。建议两种都测一下，以实际数据为准。

3.5 PCIe 带宽分配与多卡共用冲突

WX1860AL4 是 PCIe 2.0 x4 接口，四个千兆口共享这一个 x4 链路。如果同一台机器还插了其它 PCIe 设备（比如 NVMe SSD、另一张网卡），PCIe 通道的分配可能会把 x4 降级为 x2 甚至 x1。

先确认实际链路状态：

lspci -vvv | grep -A10 -i ethernet

重点看LnkCap和LnkSta两行。LnkSta显示的是当前协商速率和宽度，如果是2.5GT/s, Width x1，说明链路降级了，千兆四口全双工总带宽接近上限，性能不达标很正常。

导致降级的原因通常是 PCIe 通道资源不足，常见于多 GPU、多 NVMe 的机器，或者主板 PCIe 槽位分配策略不合理。解决方法是把网卡换到 CPU 直出的 PCIe 槽位（一般是最靠近 CPU 的 x16 长槽），避开走芯片组（PCH）的槽位。芯片组提供的 PCIe 通道共享带宽，多个设备同时读写时容易出现瓶颈。

另外，BIOS 里如果有PCIe Link Speed选项，把它设为Gen2或Auto，不要强制Gen1。某些主板的省电策略会自动降速，需要关掉 ASPM 的同时确认链路速度。

4. 实测数据与问题定位实录

4.1 不同参数组合下的吞吐对比

我把自己测试过程中记录的一组数据放出来，方便对比。

测试条件：两台 Debian 12 服务器，直连六类网线，服务端 192.168.10.1，客户端 192.168.10.2。

第一轮，默认参数：

# 服务端 iperf3 -s # 客户端 iperf3 -c 192.168.10.1 -t 30

结果：单流 512Mbps，多流（-P 8）743Mbps。很明显不达标，千兆网卡哪怕单流也应该在 900Mbps 左右。

第二轮，调队列和中断：

ethtool -L enp3s0 combined 8 # 中断绑定到 CPU2~CPU9 # 客户端 iperf3 绑定 CPU2 taskset -c 2 iperf3 -c 192.168.10.1 -t 30

结果：单流 903Mbps，多流 941Mbps。性能一下子正常了。这说明了什么问题？默认单队列模式下，网卡所有包都压在一个核上，单核处理能力撑不起千兆线速。

第三轮，加 TCP 缓冲优化：

sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_max=16777216 iperf3 -c 192.168.10.1 -t 30 -w 2M

结果：单流 936Mbps，多流几乎 948Mbps，已经非常接近千兆上限。单流的提升主要来自更大的 socket buffer 和窗口协商，TCP 长流在有限缓冲区下会频繁出现窗口满停止发送，加大缓冲能有效降低这种空等时间。

第四轮，UDP 测试：

iperf3 -c 192.168.10.1 -u -b 1000M -t 30

结果：接收带宽 995Mbps，丢包率 0.012%。把netdev_max_backlog调到 5000 之后，丢包率降到 0.001% 以下。说明 UDP 大包流水线是通畅的，网卡接收侧没有问题。

4.2 症状分类：从现象反推原因

不同“不达标”的表现，指向的原因不一样。我整理了常见的三种症状：

如果单流慢、多流快，优先排查 CPU 单核瓶颈、中断集中、iperf3 进程未绑核。这是最常见的情况，基本 80% 的问题都在这一层。

如果单流和多流都慢，但 CPU 占用率不高，优先排查 PCIe 链路降级、驱动队列数受限、网线协商速率。很可能是链路层就没达到千兆。

如果带宽波动大、忽高忽低，优先排查网线或水晶头接触不良、交换机端口协商问题、电源管理导致链路过节能。这类问题最闹心，因为不是稳定的慢，而是间歇性的掉速，建议用ethtool -S看网卡统计里的 CRC 错误和重传计数，有异常直接换线。

另外还有一种情况：如果测试时发现系统软中断 CPU 占用（top里si字段）很高，说明收包中断已经把某个核打满了。这时候即使多流测试，如果流数少于队列数，也只会有一两个核在忙，其它核闲着。

4.3 UDP 打流与双向测试的隐藏问题

热词里有“iperf3使用udp打流”，这里专门说一下 UDP 测试的坑。

UDP 测试比 TCP 更“诚实”，因为它没有拥塞控制，发送端会按-b指定的速率硬发。如果-b设置太高（比如千兆网卡设 1000M），服务端处理不过来就会丢包，这是正常现象。关键是看丢包率能不能通过调优降下来。

我遇到过一种情况：UDP 大包（1470 字节）测试能跑满，但小包（64 字节）测试丢包率极高。这是因为小包处理需要的每包 CPU 开销更大，网卡中断次数成倍增加，CPU 处理不过来。64 字节小包在千兆下理论 PPS（每秒包数）是 148.8 万，如果单核 CPU 处理能力只有 60 万 PPS，那就必然丢包。

这种场景下，除了多队列和中断分担，还可以考虑开启网卡的 RSS（Receive Side Scaling）哈希功能，让不同流的包分散到不同队列：

ethtool -N enp3s0 rx-flow-hash tcp4 sdfn

sdfn表示对源 IP、目的 IP、源端口、目的端口做哈希，这样不同 TCP 流的包能被分发到多个队列，避免单队列拥塞。

双向测试也值得做。iperf3 默认只测单方向流量，用-d或--bidir参数可以同时做双向测试：

iperf3 -c 192.168.10.1 -t 30 -d

双向测试能暴露出全双工下的性能问题。有些网卡驱动在大流量双向时，因为收发路径共享中断或 DMA 资源，双向吞吐会明显劣化。WX1860AL4 在双向测试下表现还可以，收和发能同时跑到 940Mbps 左右。

5. 驱动与固件的兼容性深挖

5.1 内核自带 wx 驱动 vs 官方驱动选择

WX1860AL4 在内核中有原生驱动wx，这一点很方便，但原生驱动不一定是最优的。在某些老版本内核里，wx驱动的多队列支持不完善，或者中断合并参数实现有 bug，会导致性能异常。

如果你用的是较老的内核（比如 5.10 之前的），建议先升级内核到 5.15 或更高版本再测。如果项目环境不能随便换内核（比如生产服务器有红帽认证），可以去网讯官方下载适配当前内核版本的驱动包手动编译。

手动编译驱动的步骤大致是：

tar xzf wx_driver.tar.gz cd wx_driver/src make make install modprobe -r wx modprobe wx

注意编译前需要安装linux-headers-$(uname -r)和gcc、make工具。编译过程中如果报unable to locate kernel source，说明 headers 没装好，用发行版包管理器安装即可。

官方驱动的优势在于针对自家芯片做了特殊优化，比如更激进的中断合并策略、更好的多队列均衡算法。但缺点是升级内核后可能需要重新编译，且不像内核原生驱动那样跟随主线维护。生产环境我建议先试内核原生驱动，确有问题再切官方驱动，并且做好对比测试记录。

5.2 固件版本对性能的影响

网卡的固件（Firmware）负责底层 MAC/PHY 的初始化、流表管理、异常处理等。多数情况下固件不需要更新，但如果你的网卡是从渠道商手里买的早期批次，固件可能存在已知问题。

查看固件版本：

ethtool -i enp3s0

输出里的firmware-version字段就是当前固件版本。如果发现驱动日志里有异常（dmesg | grep -i wx），比如频繁报tx timeout、link down，先排查固件版本是否过旧。

固件更新一般通过官方提供的工具完成，具体操作步骤每个型号有差异，这里不展开。要提醒的是：固件更新有风险，不要在业务高峰期操作，更新前备份当前固件，并且在测试环境验证后再上生产。网卡固件不像主板 BIOS 那样频繁更新，也不像驱动那样可以随时回滚，一旦刷坏，可能只能返厂。

5.3 KVM/虚拟机直通场景下的额外坑

热词里有很多关于虚拟机的词条，这里单独说下 WX1860AL4 在 KVM 和 Proxmox VE 环境下的表现。

如果用了 PCIe 直通（PCI Passthrough）把网卡直接分配给虚拟机，性能理论上可以接近物理机。但直通前要确认 IOMMU 是否开启：

dmesg | grep -i iommu

如果没开，需要在 GRUB 内核参数里加intel_iommu=on（Intel 平台）或amd_iommu=on（AMD 平台），然后更新 grub 重启。

直通后虚拟机内同样需要做队列和中断优化，虚拟 CPU 的 vCPU 绑定也要考虑。我在 Proxmox VE 上测试时，直通后单流 TCP 从 500Mbps 提升到 900Mbps，关键在于把 virtio 网卡中断和 vCPU 绑到同一物理核。

如果不用直通，用 virtio 虚拟网卡，性能会受影响，但因为走的是 virtio 准虚拟化路径，实际表现也不差。千兆场景下 virtio 单流能跑 850~900Mbps，多流跑满 940Mbps，对大多数业务足够。但是要注意 Proxmox VE 默认的防火墙和流量整形（tcqdisc）可能会限制带宽，测速前先把虚拟机网卡的防火墙关掉。

6. 系统与工具链的细节补充

6.1 iperf3 版本与使用注意事项

前面提过 iperf3 版本不一致会导致兼容问题，这里再详细说说。

iperf3 3.0 到 3.1 之间，协议头部结构有过调整，3.1 到 3.9 之间也有小的兼容性变化。如果你用apt install iperf3装的版本和服务端源码编译的版本不一致，可能出现连不上、测速异常、甚至直接报protocol error。

最稳妥的办法是两端都用发行版源里同一版本。Debian 12 默认的 iperf3 是 3.9 版本，只要两端系统一致，问题不大。如果必须跨版本，可以加--forceflush参数规避部分兼容问题，但这不是万能的。

另一个细节：iperf3 的-R参数表示反向测试，即服务端向客户端发包。这个模式能测出双向链路中不对称的问题。如果-R测出来的带宽明显低于正向，说明一端网卡的发送路径或另一端接收路径存在问题。

还有--omit参数，可以跳过测试开始时的前几秒数据。Wi-Fi 或复杂网络环境下，前几秒可能有慢启动和带宽探测的过程，测得的平均值会被拉低。用它来省略前 3~5 秒：

iperf3 -c 192.168.10.1 -t 30 --omit 3

6.2 查看中断与队列分布的工具组合

排查网络性能问题时，除了 iperf3 自身输出，还需要一组辅助工具，形成完整的观测体系。我最常用的组合是mpstat、top、ethtool -S、sar -n DEV。

mpstat -P ALL 1能看到每个 CPU 核的软中断占用。如果某个核的softirq占用超过 50%，基本可以判定收包中断集中在这个核上。

ethtool -S enp3s0输出的统计项非常丰富，重点看rx_packets、tx_packets、rx_dropped、tx_dropped、rx_errors、tx_errors。如果rx_dropped持续增长，说明缓冲区不够或 CPU 处理不过来。

top里按1可以看到每个核的使用率，注意看si（软中断）和us（用户态）两列。如果si高而us低，是网卡中断处理瓶颈；如果us高而si低，可能是应用层协议栈处理瓶颈（比如 iperf3 单线程计算校验和）。

这些工具的组合逻辑是：先确认整体链路是哪里 HOT，再针对 HOT 点做调整。不要一上来就调参数，容易越调越乱。

6.3 网卡开机自启与持久化配置

队列数、中断合并这些配置重启后会恢复默认，所以要把调优写入持久化配置。

最简单的方案是用 systemd service：

[Unit] Description=WX1860AL4 NIC Tuning After=network.target [Service] Type=oneshot ExecStart=/usr/local/bin/wx_tune.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target

脚本内容：

#!/bin/bash ETH= enp3s0 ethtool -L $ETH combined 8 ethtool -C $ETH rx-usecs 15 tx-usecs 15 ethtool -C $ETH adaptive-rx on adaptive-tx on ethtool -K $ETH gro on

保存后：

chmod +x /usr/local/bin/wx_tune.sh systemctl daemon-reload systemctl enable wx_tune.service systemctl start wx_tune.service

注意开机自启脚本的执行时机。network.target之后网络设备已经存在，但如果网卡名在重启后变化（比如从enp3s0变成enp4s0），脚本会失效。使用固定接口名的方法是在/etc/systemd/network或 udev 规则中绑定 PCI 地址和接口名。热词里有“linux网卡开机自启”，很多人以为只要systemctl enable就行，实际上如果不绑定接口名，换了 PCIe 槽位或内核版本，接口名漂移会让你所有的配置都白写。

6.4 使用 netperf 做补充验证

iperf3 测 TCP 吞吐很直观，但它偏重“尽力而为”的流式传输，对网卡的一些深层次问题（比如每包延迟、最大连接数、双向小包能力）覆盖不够。如果需要更全面的评估，可以用 netperf 做补充。

netperf 的测试模式更多：

# TCP_STREAM 模式，类似 iperf3 的 TCP 测试 netperf -H 192.168.10.1 -l 60 -t TCP_STREAM # TCP_RR 模式，测请求-响应延迟，每个事务包含一次请求一次响应 netperf -H 192.168.10.1 -l 60 -t TCP_RR -- -r 64,64 # UDP_STREAM 模式，测 UDP 发送速率 netperf -H 192.168.10.1 -l 60 -t UDP_STREAM -- -m 1470

TCP_RR 测的是每秒钟能处理多少个请求-响应事务，这个指标对 Web 服务器、数据库这类业务更有参考意义。WX1860AL4 在测试中，单核 TCP_RR 大约能到 3~4 万事务每秒，多队列分散后能到 10 万以上。如果这个数值异常低，说明网卡的单包处理能力有问题，单纯调大缓冲区解决不了。

7. 常见问题速查与避坑清单

7.1 一张表解决 90% 的排查

我把这次排查过程中遇到的所有问题和对应的解决方法汇总成一个表格，方便遇到同类问题直接查：

7.2 实测中遇到的三个典型问题

第一个问题是队列数调整后不生效。ethtool -L combined 8执行后提示成功，但ethtool -l显示仍然是 1。原因是网卡处于 up 状态时驱动不允许动态调整队列数，需要先ip link set enp3s0 down，调完再 up。手册里写得很清楚，但实际操作时容易忘。

第二个问题是中断绑定后出现中断风暴。手动写smp_affinity时候把多个中断绑到了同一个核，结果这个核直接打满，吞吐反而下降。后来把 8 个队列的中断均匀分配到 8 个核上，问题解决。绑定时注意不要覆盖 CPU0，并且要查看smp_affinity_list的值确认实际生效的 CPU 集合。

第三个问题是 iperf3 服务端和客户端的防火墙干扰。测试机装有 nftables 规则，虽然放行了 5201 端口，但规则里限制了并发连接数，导致多流测试时某些流直接被 drop。排查时用nft list ruleset查看规则，直接停掉防火墙再测，数据立刻正常。如果生产环境不能停防火墙，建议单独建一个测试 VLAN 并在这条链路上放行所有流量。

7.3 查完卡本身，还要查这些周边

网卡性能不达标，有时候是网卡旁边的“配件”出了问题。我在测试过程中就遇到过由于 PCIe 槽位供电不足导致的降速问题，这块单独提一下。

有些主板的 PCIe x4 插槽走的是 PCH 通道，供电能力有限，插四口网卡这一类的“电能小钢炮”时可能出现供电不稳。现象是网络频繁断连，dmesg里报link down但网线插拔后又能恢复。解决方法是换到 CPU 直出的槽位，或者换一个更大功率的电源。

散热也是一个隐形因素。WX1860AL4 四口满载时发热不小，放在密闭机箱里如果风道不畅，温度过高会触发网卡的过热保护，表现为速率自动降级。用sensors查看板载温度，如果连续满载时温度超过 80 度，要考虑加装主动散热。

还有一个容易被忽略的点：交换机端口协商。如果测试时经过了交换机，注意检查交换机端口是否强制设置了百兆或者自协商失败。有些老交换机端口默认是百兆，网卡虽然支持千兆，但协商结果是百兆，测出来的速率自然只有 90Mbps 左右。

8. 最后的排查路线与长期建议

8.1 从零到一的标准排查步骤

把这次的经验整理成一套固定流程，下次遇到任何网卡性能问题都可以照着走：

第一步，确认硬件链路。lspci -vvv检查 PCIe 状态、ethtool enp3s0查看协商速率、ethtool -S检查错误计数。确保物理层没问题，再用 iperf3。

第二步，单 TCP 流测速记录基准。iperf3 -c <server> -t 30得到单流数据。如果单流是 500Mbps 以下，问题比较明显；如果是 700~800Mbps，更可能是参数优化不足。

第三步，多流测速判断瓶颈方向。iperf3 -c <server> -P 8 -t 30，如果多流达到 900Mbps 以上，优先优化中断和线程绑定；如果多流仍上不去，查驱动队列、PCIe链路、网线。

第四步，调整内核参数和驱动参数。按正文里列的顺序逐项调整，每调一项跑一轮测试，记录前后对比。不要一次性把所有参数全改完，否则出了问题你都不知道是哪个参数引起的。

第五步，验证持久化。通过 systemd 或网络配置文件把调优参数固化，重启后复测确认。

这套流程的核心思路是“先确认硬件无故障，再谈参数优化”。硬件有问题时，参数怎么调都没用，反而浪费时间。

8.2 建立网卡性能基准档案

长期维护服务器的人应该养成的习惯：给每台机器的每张网卡建立性能基准档案。

档案内容包含：

• 网卡型号、固件版本、驱动版本、内核版本
• 正常情况下的单流、多流、UDP 吞吐基线
• 中断分布和队列配置截图
• 每次变更（升级内核、换驱动、改 BIOS）前后的对比数据

这样以后出了问题，可以先拿当前数据和基线对照，判断是突然劣化还是渐进劣化。如果是突然劣化，优先查最近的变更；如果是渐进劣化，优先查硬件老化、固件状态和散热。

这个习惯帮我节省了大量排查时间。有一次某台机器的网卡吞吐从 940Mbps 跌到 600Mbps，对照档案发现前一天升级过内核，回滚内核后数据恢复，问题定位只花了十分钟。

8.3 针对 WX1860AL4 的长期使用建议

最后说说长期使用 WX1860AL4 的几点体会。

第一，驱动随内核升级。用主线内核的wx驱动比用官方旧驱动更省心，但升级内核前一定先看更新日志，确认没有破坏性的驱动变更。

第二，四口千兆意味着这台机器可能充当软路由、边界防火墙或内网汇聚的角色。这类场景不但要跑满带宽，还要处理大量小包（比如 DNS 流量、视频流媒体信令），所以多队列和中断绑定的优化不是“可选项”，而是“必选项”。

第三，多网口负载均衡（bonding）如果要做，最好用 mode 4（LACP），不要用 mode 0（balance-rr）。mode 0 在多队列场景下容易乱序，反而降低性能。WX1860AL4 四个口同时做 bond，配合交换机链路聚合，能实现单台机器 4Gbps 的汇聚带宽，但这要求交换机和网卡都支持 LACP。

第四，如果你要用 DPDK 或者 VPP 这类用户态协议栈，WX1860AL4 需要确认驱动是否支持。我在 VPP 环境里试过这张卡，需要手动绑定 igb_uio 驱动并设置大页内存，步骤比 Intel 网卡繁琐一些，但能用。VPP 环境下的吞吐表现主要取决于编译时的--enable-dpdk选项和驱动匹配情况，建议先用 DPDK 自带的 testpmd 工具验证硬件转发能力，再叠加协议栈功能。

第五，也是最重要的一点：不要把 iperf3 的测速结果当作唯一标准。iperf3 压测和真实业务负载差距很大，真实业务里还有连接建立、内存拷贝、协议开销、应用层逻辑。如果业务表现正常，即使 iperf3 测速没到 940Mbps，也不需要过度焦虑。如果你用 iperf3 都打不满，那业务层大概率会遇到瓶颈，这时候才需要按照上面的流程逐步排查。