大带宽吞吐上不去，多数情况不是运营商给的带宽缩水，而是网卡协商、TCP参数、CPU软中断、磁盘I/O这四个环节里有一个卡住了，先别急着换套餐，按路径从头到尾排查更省钱。
大带宽服务器吞吐量上不去怎么回事？先查网卡协商和物理链路
很多人在北京机房买了1G独享端口,结果测速只有百兆出头，第一反应是运营商限速，但实际登录服务器一查，网卡可能只协商到100Mbps，大带宽服务器吞吐量上不去，物理层的问题往往最容易被忽略，也最容易验证。
千兆带宽下载速度只有百兆，第一站看协商速率
先看服务器网卡实际跑在什么速率,执行：
ethtool eth0 | grep Speed如果输出Speed: 100Mb/s，问题基本就明确了，千兆口没有协商到千兆，通常有四类原因：
- 网线规格不足,Cat5网线只支持百兆，Cat5e才能稳定跑千兆，Cat6适合万兆短距离。
- 光模块与端口不匹配,千兆电口模块插到万兆光口，可能直接协商不到千兆。
- 交换机端口被强制设为百兆,没有开启自动协商。
- 服务器网卡节能模式导致降速,以前Windows服务器上比较常见，Linux偶尔也会出现。
排查路径很简单：
- 换一根Cat5e或Cat6网线重新插拔。
- 用
ethtool -s eth0 speed 1000 duplex full autoneg on强制千兆并开启自动协商。 - 登录交换机查看端口状态,看有没有CRC错误或协商不一致。
如果两边都显示千兆,但实际下载速度还是百兆级别，再往下查。
万兆网卡吞吐量测试方法错了，公网测速说明不了问题
万兆网卡吞吐量测试如果放在公网上做,结果几乎没法看，公网测速受跨域路由、运营商互联带宽、对端服务器性能多重影响，尤其北京机房到南方省份晚高峰波动很大。
正确做法是在内网打流,找一台同VLAN或同接入交换机下的第二台机器当服务端，跑iperf3：
服务端：
iperf3 -s客户端：
iperf3 -c 192.168.1.10 -P 8 -t 60-P 8表示同时起8个并发线程，-t 60跑60秒，如果单线程只能跑2Gbps左右，多线程能跑到9Gbps以上，说明网络链路本身没问题，是应用层单线程处理不过来，如果多线程也卡在2Gbps，就要回头看PCIe插槽宽度、光模块类型和网卡驱动了。
内核参数和CPU软中断：最容易漏掉的两处
网卡协商正常、内网打流也正常，但实际业务还是跑不满带宽，问题经常藏在Linux内核参数和软中断处理里。
单线程下载跑不满千兆带宽，TCP缓冲区不够
默认TCP缓冲区针对的是低带宽高延迟场景,遇到千兆甚至万兆带宽时，缓冲区太小会直接限制吞吐，单线程下载尤其明显，因为TCP窗口大小等于带宽乘以往返时延，北京到上海延迟大约30ms，要跑满1Gbps，窗口至少需要3.75MB，默认tcp_rmem最大通常只有几MB，刚够用，一到万兆就完全不够。
检查当前参数：
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem推荐调整到更大的值,同时启用BBR拥塞控制：
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.ipv4.tcp_rmem='4096 87380 134217728'
sysctl -w net.ipv4.tcp_wmem='4096 65536 134217728'
sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -w net.core.default_qdisc=fq改完写入/etc/sysctl.conf让重启后生效，切到BBR后，一定概率下丢包场景的恢复速度会更好，不过行业共识认为BBR并非万能，遇到持续严重丢包还是得先解决链路。
软中断把单核CPU打满，网卡队列不绑核
万兆网卡每秒要处理大量数据包,如果所有中断都挤压在一个CPU核上，这个核的软中断占用会飙到100%，此时就算带宽没跑满，吞吐也被CPU拖住了，可以查看：
mpstat -P ALL 1注意%soft这一列，如果某个核长期90%以上，其他核很闲，基本就是中断不均衡。
先增加网卡队列：
ethtool -L eth0 combined 8然后查看中断号：
cat /proc/interrupts | grep eth0把每个队列的中断分别绑定到不同CPU核：
echo 0 > /proc/irq/126/smp_affinity_list
echo 1 > /proc/irq/127/smp_affinity_list也可以直接关闭irqbalance,手动绑核更可控，虚拟化场景下，virtio网卡同样需要配置多队列，否则吞吐也上不去。
内网大文件传输速度慢，别只怀疑网络
很多所谓“内网大文件传输速度慢”，测了半天iperf3发现网络能跑满，但实际用scp或rsync传文件就是慢，这时候瓶颈可能根本不在网络，而在磁盘。
磁盘顺序写只有几十MB/s，吞吐当然上不去
机械硬盘的顺序写速度通常只有80MB/s到160MB/s，单块SATA SSD能到500MB/s左右，NVMe SSD能到2000MB/s以上，如果服务器用的是几块机械盘做RAID，顺序写速度也就一两百MB/s，换算成带宽只有1Gbps到2Gbps，这种情况下万兆网络根本用不满。
先测磁盘顺序读写：
dd if=/dev/zero of=/tmp/testfile bs=1M count=10240 oflag=direct
dd if=/tmp/testfile of=/dev/null bs=1M count=10240 iflag=direct同时用iostat -x 5看%util和await，如果磁盘利用率接近100%，await很高，说明磁盘撑不住业务压力。
RAID卡缓存策略也会影响吞吐。write-back模式，吞吐会明显好于write-through，不过write-back在断电时有数据丢失风险，需要配合电池或超级电容，业内专家指出，相当一部分大带宽场景下的传输慢，其实是磁盘I/O被误判为网络问题，这在新上线的数据迁移和备份场景里特别常见。
丢包、MTU和中间设备：吞吐被悄悄打折
链路、内核、磁盘都正常，可吞吐还是差一截，接下来查丢包和MTU。
MTU分片和TCP重传，一个都不能忽略
MTU不匹配会直接导致IP分片或丢包,TCP一旦重传，有效吞吐断崖式下降，某跳链路支持9000字节巨型帧，但中间某个交换机端口MTU还是1500，大包就会被丢弃。
用ping测试MTU：
ping -M do -s 1472 192.168.1.1如果1472通了,再试8972测巨型帧。-M do表示禁止分片，通不过就说明MTU超过某段链路限制。
开启巨型帧需要全线支持：
- 服务器网卡MTU设为9000。
- 交换机端口MTU设为9000。
- 对端服务器和中间路由器全部一致。
任何一处不一致都会导致分片或丢包,万兆内网存储场景，开巨型帧能明显降低CPU开销、提升吞吐，但前提是全网配置一致。
防火墙、负载均衡和NAT会话数限制
企业大带宽专线前面经常有防火墙或路由器做NAT,这些设备的包转发率和会话表容量可能没有标注得那么高，大流量下载时，NAT会话数快速增加，一旦超过设备上限，后续连接直接被丢弃，表现就是速度忽高忽低、连接超时。
排查方法：
- 下载一个大文件,同时在防火墙或路由器上查看会话数、CPU占用。
- 检查链路两端交换机端口是否有CRC错误包增长。
- 用
tcpdump -i eth0 -s 0 -w trace.pcap抓包，分析是否存在大量TCP重传或Zero Window。
如果确认是中间设备扛不住,只能换更高吞吐的设备或减少经过设备数。
北京机房大带宽与云服务器吞吐对比：地域因素如何快速排除
北京机房物理服务器的公网带宽多数是独享或高比例共享,云服务器则经常是共享带宽或突发性能型实例，同样标注100Mbps，物理服务器可能稳定跑满，云服务器在业务高峰可能只有几十Mbps，地域因素有时候会放大差距，比如北京机房到上海电信晚上绕路，延迟增加导致单线程下载更慢。
对比时先做两个动作：
- 内网打流：确认链路本身能跑多快。
- 公网多线程下载：用
aria2c -x 16 -s 16这种多线程工具，对比不同线程数下的吞吐变化。
如果多线程能跑满,单线程跑不满，往往是时延和缓冲区问题，如果多线程也跑不满，再查线路和运营商互联。
大带宽吞吐优化常见问题快答
大带宽场景下吞吐上不去，怎么快速定位是网络还是磁盘瓶颈？
先用iperf3在内存态打流，排除磁盘参与，如果iperf3多线程能跑满带宽，说明网络正常，再去查磁盘I/O和业务配置，如果iperf3本身跑不满，就用ethtool查协商速率、mpstat查软中断、tcpdump查重传，按顺序排除。
千兆带宽下载速度只有百兆，需要检查哪些硬件？
按顺序检查：网卡协商速率、网线规格、交换机端口速率、光模块类型，如果都正常，再看下载工具是否单线程且未调TCP缓冲区，多数情况下，问题在网线或端口协商，换个Cat5e以上的线就能解决。
万兆网卡吞吐量测试只有2Gbps，正常吗？
单线程测试或未开巨型帧时,跑到2Gbps左右并不罕见，用iperf3 -P 8打多线程、调大TCP缓冲区、开巨型帧后再测，若仍然只有2Gbps，检查PCIe插槽是否只给了PCIe x4或x1通道，以及光模块是不是10G速率的，直接查看两端协商速率即可确认。