服务器上架通电之后,别急着跑业务。花30分钟做一次网卡基准测试,能帮你确认硬件没有瓶颈、线缆没有衰减、驱动配置正确。本文给出一套完整的iperf/netperf测试流程,覆盖吞吐量、延迟、PPS三个维度,并用三款不同速率的网卡做实测对比。
新服务器出厂时网卡硬件没问题,但实际部署后性能可能打折扣。PCIe插槽带宽不足、光模块接触不良、Cat6a线缆超长、驱动版本过旧——这些问题不跑一次基准测试根本发现不了。
更关键的是,基准数据是你后续排查网络问题的参照物。如果上线后业务卡顿,你拿什么判断是网卡问题还是应用问题?答案就是手里那份"正常状态下应该跑多少"的基线数据。
网卡性能基准测试主要看三个数字:
吞吐量(Throughput):单位时间内传输的数据总量,单位 Gbps。这是最直观的指标,反映网卡的带宽上限。
延迟(Latency):一个数据包从发出到被接收的时间,单位微秒(us)。对数据库、交易系统这类延迟敏感型业务至关重要。
PPS(Packets Per Second):每秒处理的数据包数量。小包场景下(如金融行情推送、DNS查询),PPS 比吞吐量更能反映真实性能。
基准测试需要两台设备:一台跑 iperf Server,一台跑 iperf Client。两台机器通过被测网卡互联(直连或经过交换机均可)。
硬件准备清单:
关闭防火墙和 iptables 规则,关闭 CPU 节能模式(设为 performance),确认网卡驱动已加载且链路协商速率正确(ethtool eth0 查看 Speed 字段)。任何一项没做到位,测试结果都不可信。
iperf 是吞吐量测试的标准工具。以下是三种速率网卡的测试命令和预期结果。
TCP 吞吐量测试(大包):
# Server 端(对端机器)
iperf -s -i 1
# Client 端(被测机器)— 单流测试
iperf -c 192.168.1.2 -t 30 -i 5
# Client 端 — 多流并发(充分利用多队列)
iperf -c 192.168.1.2 -P 8 -t 30
UDP 吞吐量 + 丢包率测试:
# 以线速 90% 发送 UDP 流量,持续 30 秒
iperf -c 192.168.1.2 -u -b 22500M -t 30
预期吞吐量参考值:
| 网卡型号 | 速率 | 接口 | PCIe | TCP 实测预期 | PPS 预期(64B) |
|---|---|---|---|---|---|
| LRES1027PF-4SFP28 | 25G | 4×SFP28 | 4.0 x8 | 23.5-24.5 Gbps | ~30 Mpps |
| LREC9812BT | 10G | 2×RJ45 | 3.0 x4 | 9.2-9.6 Gbps | ~14 Mpps |
| LREC9714HT | 1G | 4×RJ45 | 2.1 x4 | 940-960 Mbps | ~1.4 Mpps |
TCP 吞吐量低于预期 10% 以上时,依次检查:PCIe 实际协商带宽(lspci -vvv 看 LnkSta)、网卡中断是否绑定到多核(/proc/interrupts)、TCP 窗口大小是否足够(sysctl net.core.rmem_max)。10G RJ45 方案对线缆质量敏感,Cat6 超过 55 米就可能降速。
吞吐量达标不代表网卡没问题。小包场景下,PPS 和延迟才是瓶颈所在。用 netperf 的 TCP_RR 和 UDP_RR 模式测:
# 延迟测试(TCP 请求-响应)
netperf -H 192.168.1.2 -t TCP_RR -l 30 -- -r 64,64
# PPS 测试(UDP 小包,64字节)
netperf -H 192.168.1.2 -t UDP_RR -l 30 -- -r 64,64
25G 光口方案(如 LRES1027PF-4SFP28)在小包延迟上明显优于 RJ45 电口方案,因为光模块的信号处理路径更短。10G RJ45 网卡(LREC9812BT)的 PHY 层编解码会引入额外几微秒延迟,这在多数业务场景中可以接受,但对延迟极度敏感的交易系统需要纳入考量。
适合数据中心核心业务、AI 训练集群、存储网络。四口 25G 提供 100Gbps 聚合带宽,支持 RDMA 和 DPDK,PCIe 4.0 x8 保证总线不成瓶颈。
适合已有 Cat6a 铜缆布线的企业机房升级万兆。免光模块、免光纤,插上现有网线即可跑满 10G,部署成本最低。
适合管理网、带外网络、中小规模虚拟化平台。四口千兆支持链路聚合,单卡即可提供 4Gbps 聚合带宽,功耗仅 4.5W。
误区一:只测 TCP 大包就下结论。 很多业务跑的是小包(数据库查询、RPC 调用),此时 PPS 才是真正瓶颈。一块 25G 网卡如果 PPS 只有 5Mpps,在小包场景下实际利用率可能不到 10%。
误区二:忽略 PCIe 带宽匹配。 把 PCIe 3.0 x4 的网卡插到 x1 插槽里,物理上能亮机,但带宽直接砍到 1/4。跑 iperf 发现只有 2Gbps 就以为是网卡坏了,其实是插槽没给够。用 lspci -vvv | grep LnkSta 确认实际协商的速率和宽度。
误区三:单次测试取结果。 网络测试受系统负载、中断调度、温度等影响,单次结果波动可达 5%-10%。正确做法是每组参数跑 5 轮,取中位数。
基准测试不是跑一次 iperf 就完事。吞吐量、延迟、PPS 三个维度都要覆盖,大包小包都要测,多轮取中位数。把结果存档,它就是你这台服务器网络性能的"体检报告"。
按这个顺序排查:确认 ethtool 显示的协商速率是否正确(比如标称 10G 但协商成了 1G);检查 PCIe 插槽实际带宽(lspci -vvv);确认对端设备端口速率匹配;排除线缆问题(换一根线重测)。多数情况是协商速率不对或 PCIe 插槽带宽不足。
对端至少需要一个 25G 端口。可以用另一台装 25G 网卡的服务器直连(DAC 铜缆 3 米内),也可以通过支持 25G 的交换机。如果对端只有 10G 口,测出来的上限就是 10G,无法验证 25G 性能。
iperf 单流测试时 CPU 占用 30%-50% 属于正常范围,尤其是 10G 以上速率。如果 CPU 打满但带宽没跑满,说明中断处理集中在单核上。用 irqbalance 或手动绑定中断到多核(/proc/irq/N/smp_affinity)可以解决。
iperf 侧重吞吐量测试,操作简单,适合快速验证带宽;netperf 支持 TCP_RR/UDP_RR 模式,能精确测量请求-响应延迟和 PPS,适合评估小包性能。建议两个都用:iperf 测大包吞吐,netperf 测小包延迟和 PPS。
建议记录:测试日期、网卡型号和固件版本、驱动版本、PCIe 插槽位置、线缆类型和长度、对端设备信息、每项测试的 5 轮结果。存成表格或 JSON,后续排查问题时直接对比即可。