服务器与大带宽专家 · 持牌IDC/CDN/ISP服务商
简米科技官网JIANMI TECH
资讯 2026-08-25 更新于 2026-08-25 简米科技 2,520 字 6 分钟阅读

iperf如何做大带宽服务器吞吐压测,方法有哪些?

导读大带宽服务器的吞吐压测,最可靠的办法就是用iperf工具做一对一打流测试,服务端部署在目标机器上,客户端持续灌入流量,测出的数值才是这台服务器的真实转发上限,很多人在百度找"iperf3测带宽命令"却忽略参数细节,导致压测结果虚高或偏低,本文直接给出可落地的操作和排查思路,iperf3测带宽命令怎么用才对吞吐压……

大带宽服务器的吞吐压测,最可靠的办法就是用iperf工具做一对一打流测试,服务端部署在目标机器上,客户端持续灌入流量,测出的数值才是这台服务器的真实转发上限。很多人在百度找"iperf3测带宽命令"却忽略参数细节,导致压测结果虚高或偏低,本文直接给出可落地的操作和排查思路。

iperf3测带宽命令怎么用才对

吞吐压测的前提是分清角色,被压测的机器跑服务端,发起压测的机器跑客户端,装好工具后,先执行一条最简单的命令验证链路通不通,再逐步加参数逼近极限。

服务端启动监听,默认5201端口:

iperf3 -s

客户端发起基础测试,持续30秒:

iperf3 -c 192.168.1.100 -t 30

这里有个新手常犯的失误,单线程测不到大带宽上限,百兆以内带宽单线程够用,千兆或万兆环境必须加并发数,用-P参数指定多连接并行:

iperf3 -c 192.168.1.100 -t 60 -P 8

多流并发下,TCP窗口和协议栈分配会拉高吞吐,多数情况下8个并发已经能压出网卡的九成性能,如果还想压得更狠,把并发提升到16到32个,同时观察服务端CPU是否被打满。

服务器带宽测试工具哪个真实,iperf和speedtest的差别

提到测带宽,很多人第一反应是speedtest网页版,但那个工具测的是“本机到测速节点的公网链路质量”,并不是云服务器的实际转发能力,业内专家指出,speedtest类工具走的是HTTP下载路径,经过中间CDN或运营商缓存后,结果经常虚高。

iperf如何做大带宽服务器吞吐压测,方法有哪些?

iperf走的是TCP裸流,客户端和服务端直接建立长连接,不经过任何缓存层,测出的值就是网卡、驱动、协议栈配合下的真实吞吐。验收服务器性能用iperf,查家里宽带够不够用speedtest,两者场景不冲突。

iperf吞吐量上不去原因排查清单

压测时最容易遇到的问题是,带宽标称1000M,实际打流只有300M,先别急着怀疑服务器商家,按下面的清单逐项排查。

单核CPU瓶颈导致吞吐上不去

iperf本身是单进程设计,如果网卡中断全部落在同一个CPU核心上,处理能力就成了天花板。观察服务端CPU占用率,如果单核跑满而其余核心空闲,属于典型的中断不均衡。

解决办法是开启网卡多队列,并设置RPS(Receive Packet Steering)让中断分布到多个核心,在/etc/sysctl.conf中加入:

net.core.rps_sock_flow_entries = 32768

再配合rps_cpus绑定具体CPU掩码,重启后重新压测,往往能把吞吐拉到接近线速。

TCP窗口默认值限制了大带宽场景

Linux默认TCP接收窗口对高带宽高延迟链路不够宽,特别是跨地域压测时,窗口成为吞吐瓶颈的概率最大,调大缓冲区,客户端加入-w参数:

iperf3 -c 192.168.1.100 -t 60 -P 8 -w 2M

iperf如何做大带宽服务器吞吐压测,方法有哪些?

同时调整服务端系统参数:

net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432

行业共识认为,多数云主机默认参数偏向节省内存而非榨干带宽,手动调高后效果立竿见影。

物理链路和网卡协商状态排查

自建机房压测时,确认网卡实际协商速率不是百兆,用ethtool eth0查看Speed字段,如果显示100Mb/s而交换机端口支持千兆,多半是网线或交换机端口配置问题,虚拟化平台上的云主机还要额外确认母机网卡没有被其他虚拟机抢占

大带宽服务器压测场景下的精细化调优

双机对测还是单机自测?场景决定方案

大带宽服务器租用测速时,很多商家提供内部测试IP,建议直接用两台同网段机器互打,公网压测受跨运营商路由影响,中间任何一跳拥塞都会拉低最终结果,内网打流才能体现服务器本身性能上限

如果你做的是视频推流或文件分发业务,建议加一条UDP测试,查看丢包率:

iperf3 -c 192.168.1.100 -u -b 800M -t 30

UDP模式可以指定目标带宽,测出的Jitter(抖动)和Lost(丢包)两个指标对实时业务极具参考价值。

压测时间不得低于60秒避免冷启动干扰

TCP慢启动机制会导致前几秒吞吐偏低,TCP拥塞控制算法需要时间把窗口撑大。

iperf如何做大带宽服务器吞吐压测,方法有哪些?

压测时长建议120秒以上,取后半段数据的平均值,命令里加上-i 10让结果每10秒打印一次:

iperf3 -c 192.168.1.100 -t 120 -i 10 -P 8

观察最后三行输出,如果吞吐数值趋于平稳说明已到上限,如果还在上升说明尚未压满。

iperf3版本差异和参数兼容性注意事项

iperf3和iperf2不兼容,两代工具用的端口协议不同,客户端版本必须和服务端保持一致,CentOS自带源里的iperf3版本较老,建议从官方仓库编译安装最新版,Debian/Ubuntu用户直接apt install iperf3即可,Windows用户推荐使用iperf3的预编译二进制文件,配合PowerShell终端运行。

Q&A:iperf压测高频问题汇总

iperf压测时为什么CPU先到100%而带宽没跑满?

iperf的收发过程涉及用户态与内核态频繁切换,加上中断处理消耗CPU资源,此时说明机器计算能力弱于网络转发能力,需要升级CPU规格,或者用DPDK等用户态协议栈绕过内核瓶颈,云主机场景下建议直接选择更高主频的实例规格,本地测试则可以尝试taskset将iperf进程绑定到空闲核心。

iperf测出的结果远高于带宽标称值,正常吗?

相当一部分商家按出网带宽计费,入网带宽往往远大于出网带宽,如果从公网压测入网方向,测出几倍于标称值的吞吐是正常现象,需要区分测试方向,用服务端收到的TCP吞吐数值作为基准,向商家确认计费口径是单向还是双向。

分享本文
本文为 简米科技官网 原创,已由运维技术专家审核。转载请注明来源:原文链接
售前咨询 服务热线 售后 邮箱