跑过服务器和网卡的人基本都绕不开 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 enp3s0WX1860AL4 支持多队列默认可能只开了单队列。如果这里显示Combined只有 1那性能一定上不去因为所有包都挤在一个队列里由同一个 CPU 核处理。后面会讲怎么调整。还有个容易踩的坑BIOS 里的 ASPM电源管理默认可能是开启的。网卡进入低功耗状态后唤醒和恢复会引入延迟影响小包转发和 TCP 吞吐。建议在 BIOS 里把 PCIe ASPM 设为禁用或者通过内核参数pcie_aspmoff关闭。2.3 基准测试命令与预期指标测试前先把服务器时间同步好关闭防火墙或者放行 5201 端口systemctl stop nftables # 或者针对 5201 端口放行服务端启动iperf3 -s -p 5201 -i 1客户端测试 TCPiperf3 -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 1UDP 测试要看两个指标接收带宽和丢包率。如果带宽达标但丢包率很高说明网卡中断处理不过来或者 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手动固定参数更可控。另外一个隐蔽问题是 GROGeneric Receive Offload和 LROLarge Receive Offload的状态。用ethtool -k enp3s0查看ethtool -k enp3s0 | grep -E generic-receive-offload|large-receive-offloadGRO 默认开启是好事能合并小包减少中断次数。但某些国产网卡的驱动对 GRO 支持不完善开启后反而出现丢包或吞吐下降。你可以用ethtool -K enp3s0 gro off临时关闭对比测试。如果关闭后吞吐明显提升说明驱动对 GRO 的实现还有问题这种情况最好保持关闭同时去驱动社区反馈 bug。3.4 TCP 协议栈与系统参数瓶颈iperf3 测速跑不满很多时候锅不在网卡而在系统默认的 TCP 参数。千兆网卡考验的是整条数据通路socket 缓冲区任何一个环节卡住吞吐就上不去。如果客户端iperf3 -c加了-w 1M但服务端没有同步调整两端 socket 缓冲不一致实际吞吐会被低的一端限制。更稳妥的做法是在两端同时设置系统级参数sysctl -w net.core.rmem_max16777216 sysctl -w net.core.wmem_max16777216 sysctl -w net.ipv4.tcp_rmem4096 87380 16777216 sysctl -w net.ipv4.tcp_wmem4096 65536 16777216这里把最大接收/发送缓冲区都提到 16MBTCP 自动协商窗口的上下限也放宽。对于千兆网络16MB 可能有点奢侈但至少不会成为瓶颈。还有一个参数容易被忽略net.core.netdev_max_backlog。它控制网卡驱动把包递给内核协议栈之前队列里能积压多少包。突发流量下如果这个值太小驱动只能丢包。默认值通常是 1000建议调大sysctl -w net.core.netdev_max_backlog5000如果是 UDP 测试丢包这个参数尤其有效。最后tcp_congestion_control在局域网高带宽环境也有影响。默认的 cubic 在低延迟高带宽下已经够用但也可以试试 bbrsysctl -w net.ipv4.tcp_congestion_controlbbr注意 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 8743Mbps。很明显不达标千兆网卡哪怕单流也应该在 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_max16777216 sysctl -w net.core.wmem_max16777216 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那就必然丢包。这种场景下除了多队列和中断分担还可以考虑开启网卡的 RSSReceive Side Scaling哈希功能让不同流的包分散到不同队列ethtool -N enp3s0 rx-flow-hash tcp4 sdfnsdfn表示对源 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_iommuonIntel 平台或amd_iommuonAMD 平台然后更新 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 36.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] DescriptionWX1860AL4 NIC Tuning Afternetwork.target [Service] Typeoneshot ExecStart/usr/local/bin/wx_tune.sh RemainAfterExityes [Install] WantedBymulti-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 1470TCP_RR 测的是每秒钟能处理多少个请求-响应事务这个指标对 Web 服务器、数据库这类业务更有参考意义。WX1860AL4 在测试中单核 TCP_RR 大约能到 3~4 万事务每秒多队列分散后能到 10 万以上。如果这个数值异常低说明网卡的单包处理能力有问题单纯调大缓冲区解决不了。7. 常见问题速查与避坑清单7.1 一张表解决 90% 的排查我把这次排查过程中遇到的所有问题和对应的解决方法汇总成一个表格方便遇到同类问题直接查现象可能原因快速验证解决办法单流慢、多流快单核软中断瓶颈mpstat -P ALL 1看软中断集中在单核多队列 中断绑定 iperf3 绑核单流多流都慢PCIe 链路降级lspci -vvv查看 LnkSta换插槽、关 ASPM、固定 Gen2带宽波动大网线或接口接触不良ethtool -S看 CRC 错误更换网线、重压水晶头、改短距离丢包率高netdev_max_backlog过小sysctl net.core.netdev_max_backlog调大到 5000 或更大UDP 小包丢包单核 PPS 处理能力不足sar -n DEV 1看 pps 与 CPU多队列 RSS 哈希 中断分散双向性能差收发路径共享资源iperf3-d测试确认驱动版本、检查 PCIe 仲裁虚拟机直通跑不满IOMMU 未开启dmesggrep -i iommu重启后配置丢失未持久化调优脚本重启后ethtool -l确认写 systemd 单元并固定接口名固件过旧导致异常早期批次固件 bugethtool -i对照版本官方工具刷固件先备份两端 iperf3 版本不一致协议不兼容iperf3 --version确认统一版本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 4LACP不要用 mode 0balance-rr。mode 0 在多队列场景下容易乱序反而降低性能。WX1860AL4 四个口同时做 bond配合交换机链路聚合能实现单台机器 4Gbps 的汇聚带宽但这要求交换机和网卡都支持 LACP。第四如果你要用 DPDK 或者 VPP 这类用户态协议栈WX1860AL4 需要确认驱动是否支持。我在 VPP 环境里试过这张卡需要手动绑定 igb_uio 驱动并设置大页内存步骤比 Intel 网卡繁琐一些但能用。VPP 环境下的吞吐表现主要取决于编译时的--enable-dpdk选项和驱动匹配情况建议先用 DPDK 自带的 testpmd 工具验证硬件转发能力再叠加协议栈功能。第五也是最重要的一点不要把 iperf3 的测速结果当作唯一标准。iperf3 压测和真实业务负载差距很大真实业务里还有连接建立、内存拷贝、协议开销、应用层逻辑。如果业务表现正常即使 iperf3 测速没到 940Mbps也不需要过度焦虑。如果你用 iperf3 都打不满那业务层大概率会遇到瓶颈这时候才需要按照上面的流程逐步排查。