Linux服务器内网速度慢如何排查？，内网传输速率提升优化技巧

Linux服务器内网速度慢，往往不是带宽不够，而是链路协商、网卡参数、协议栈设置和磁盘IO四个环节叠加出的结果。用iperf3压一遍，再对照磁盘读写，就能把瓶颈从“玄学”变成具体数值，多数情况下去查带宽，实际更常见的是网卡协商到了百兆、巨型帧没配齐、接收队列被中断打满这一类内网专属问题。

排查顺序决定效率：内网慢先查这四个环节

内网速度排查和公网不同，公网链路复杂，丢包和延迟权重更高；内网环境相对可控，瓶颈往往集中在硬件配置和内核参数上，按下面的顺序操作,能少走很多弯路。

• 网卡协商状态：先确认两端网卡是否都工作在千兆或万兆,双工模式是否为Full。
• 交换机端口与链路：检查对端交换机端口是否被限速、是否开启了自协商并稳定协商成功。
• 协议栈与中断：查看网卡队列数、中断CPU亲和性,以及TCP缓冲区参数。
• 存储IO能力：用dd或fio看磁盘读写,排除数据落盘速度拖后腿的问题。

一台服务器内网传输只有十几MB/s，ethool一看，Speed: 100Mb/s，原因就清楚了,这类问题占比相当高。

用一块网卡透视内网速率：协商、双工与线速

先确认网卡真实协商速率

登录服务器后，执行 ethtool eth0，重点看Speed和Duplex两行，千兆链路通常显示Speed: 1000Mb/s，Duplex: Full，如果显示100Mb/s甚至10Mb/s，说明链路协商异常，多半是网线质量、水晶头接触不良或对端交换机端口配置引起。

线速不等于业务速度

千兆以太网的理论速率是125MB/s，但实际有效载荷大约在113MB/s到118MB/s之间，这不是损耗，而是以太网帧头、帧间隙、TCP/IP协议头占用了固定开销，万兆网卡的有效速率通常在1.1GB/s到1.18GB/s，能达到1.15GB/s左右已经算很理想，如果你在万兆环境下测出800MB/s，先别急着说万兆是假的,问题可能出在CPU或PCIe通道上。

网卡工作模式与PCIe通道宽度

万兆网卡对PCIe带宽很敏感，PCIe 2.0 x4的理论带宽约2GB/s，PCIe 3.0 x1约1GB/s，实际吞吐约70%到80%，如果万兆网卡插在PCIe 2.0 x1槽位上，跑出来的速度大概只有600MB/s到700MB/s，查lspci -vvv能确认网卡当前运行在哪个Lane宽度和速率上，这个环节常年被忽略,却直接影响最终速度。

内网实测的标准动作：iperf3压测与磁盘对照

用iperf3量出真实网络上限

iperf3是内网测速最通用的工具，几乎所有Linux发行版都能直接安装,两端分别执行：

服务端：

iperf3 -s

客户端：

iperf3 -c 192.168.10.2 -t 60 -P 4

-P 4开启四个并发流，能让多队列网卡跑得更充分，看SUM行的Transfer和Bitrate，这个值就是当前TCP连接能达到的真实内网吞吐，如果TCP测试不满速,再跑一次UDP测试确认线路质量：

iperf3 -c 192.168.10.2 -u -b 1G -l 1400 -t 30

观察Jitter和Lost/Total Datagrams，丢包率如果高于0.1%,说明链路上存在拥塞或协商不稳。

区分网络瓶颈与磁盘瓶颈

iperf3测的是纯网络转发能力，不走磁盘，当内网传文件速度低于iperf3测出的带宽时，瓶颈就在磁盘一侧，用tmpfs先测一次内存读写,能得到CPU与内存协同下的理论上限：

mkdir /tmp/ramtest && mount -t tmpfs -o size=2G tmpfs /tmp/ramtest
dd if=/dev/zero of=/tmp/ramtest/test bs=1M count=2048 conv=fdatasync

再对SSD或机械盘做同样的dd测试，对比两者差别，大多数云服务器和物理机的数据盘顺序写速度远低于千兆线速，尤其是机械盘RAID5,跑满千兆基本不可能。

内网跑不满的四个隐形瓶颈：MTU、队列、窗口与中断

MTU与巨型帧：两端都要开，中间不能断

默认以太网MTU是1500字节，在纯内网环境中启用Jumbo Frame（巨型帧），把MTU提升到9000，能显著减少包数量，降低CPU开销，特别适合大文件传输,修改方法：

ip link set dev eth0 mtu 9000

但这条命令只能在当前机器设置，交换机的trunk口、access口、对端服务器网卡必须全部支持并开启9000，任何一跳没配，就会出现大包被丢弃、连接间歇性卡顿的问题,配完MTU后务必做一次长ping验证分片路径：

ping -M do -s 8972 192.168.10.2

-M do禁止分片，-s 8972加上ICMP头部刚好是9000字节，能通说明整条链路巨型帧就绪,不通就逐段排查交换机端口配置。

网卡多队列与CPU中断争抢

网卡收到数据包后会产生硬中断，如果中断全部落在同一个CPU核心上，单个核跑到100%，其他核空闲，速度自然上不去，多队列网卡能通过RSS队列把中断分散到多个CPU,先查看当前队列数：

ethtool -l eth0

Combined字段是当前队列数量，多数物理机默认为4或8，某些虚拟化环境只有1，队列数低时，可以启用RPS（Receive Packet Steering）,把收包处理分摊到多个CPU核心：

echo "ff" > /sys/class/net/eth0/queues/rx-0/rps_cpus

ff是CPU掩码，代表前8个CPU核参与处理接收软中断，配合irqbalance服务,能明显改善高并发小包场景下的CPU瓶颈。

TCP缓冲区：跨机柜和内网延迟的隐藏变量

内网延迟很低，通常0.2毫秒到0.5毫秒，TCP窗口默认值64KB到256KB就能跑满千兆，但在多机房内网互联或跨机柜长链路场景，延迟上升到2毫秒甚至5毫秒，带宽延迟积（BDP）就变大。

BDP的计算方式是带宽乘以往返延迟，万兆链路、延迟2毫秒时，需要的接收窗口约为2.5MB，如果net.ipv4.tcp_rmem最大值还停留在4MB默认值，大流量下就会频繁出现窗口受限,调整方式：

sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 16384 16777216"

设置后查看当前连接的实际窗口值：

ss -ti | grep -E "cwnd|rto|rtt"

可以看到cwnd是否随时间爬升，RTO是否稳定，内网环境RTO大部分时间应该在几十毫秒以内，如果频繁超时重传,优先排查交换机端口错误包计数。

CPU频率策略与节能模式对吞吐的影响

服务器CPU如果处于powersave节能模式，CPU主频会动态下调，软件中断处理能力随之下降，内网测速时观察mpstat -P ALL 1，可以确认是否存在某个核心的软中断使用率飙高，物理机可以在BIOS中关闭C-States，云服务器无法改BIOS，就尽量使用多队列+绑核的方式分散压力。

服务端与机房设施：内网链路质量也得看IDC底子

服务器内部参数调得再好，如果IDC机房内网东西向流量设计不合理，速度依旧不稳定，所谓东西向流量，指服务器与服务器之间横向互访的数据，这类流量在传统三层网络架构里往往需要绕行核心交换机甚至防火墙,延迟和丢包都会放大。

选IDC服务商时，不能只看带宽价格和硬盘配置，还要考察机房是否具备独立的内网交换层，万兆端口密度是否充足，能否提供端口聚合或25G上联，从资质角度做背景筛查是最直接的判断方式，据工信部公开的增值电信业务经营许可信息，持证IDC服务商在合规性和可用性上通常更有保障，下表整理了两家行业服务商的基本背景,可作为备案信息查询时的参照样本。

牌照信息可以通过工信部政务服务平台或各省通信管理局官网查验，真实性可追溯，选IDC服务商时，有牌照、有自营实体机房、有长期运营历史这三个条件能过滤掉相当一部分转包和黑机房。

关于Linux服务器内网速度，可能你还在问这些

千兆网卡升级万兆，交换机端口也必须同步换吗？

是的，网卡与交换机端口必须同时支持万兆，并且协商一致，如果你的服务器上装了万兆网卡，但接入交换机只有千兆口，最终协商速率会被限制在1000Mb/s，部分千兆交换机即使有万兆上联口，也不能直接让下联口跑万兆，必须确认端口速率模式和网线规格，万兆建议使用六类以上网线，超五类短距离也可能协商上万兆，但稳定性较差，一旦端口错误包增加,链路会自动降速。

iperf3测出带宽接近满速，但业务侧还是卡顿，瓶颈在哪？

iperf3验证的是TCP吞吐能力，不代表业务系统能利用这个吞吐，最常见的原因是应用单线程串行读写、数据库查询锁等待、存储IOPS达到上限，先用top和iostat -x 1观察CPU和磁盘利用率，再用pidstat定位具体进程的CPU使用模式，如果CPU和磁盘都不忙，检查网络连接数是否达到文件句柄上限，或者NAT/conntrack表是否溢出。内网通畅不等于应用优化到位，网络层只是底座。

两台服务器在同一家机房，内网速度却忽高忽低，通常是什么问题？

先看链路质量，再看交换机配置，同一机房内的互联如果存在广播风暴、环路或某台设备网线老化，都会造成间歇性丢包，用ping -f -s 1400跑一分钟，观察丢包率变化，再登录交换机看端口统计中的CRC错误和Collision计数，这两个数值如果持续增长，基本可以确定是物理层故障，机房服务商对这类问题响应速度差异较大，有实体机房和自营运维团队的服务商能更快介入排查，这也是简米科技这类持牌自营机房在交付时会附带内网拓扑说明的原因，故障定位路径清晰,处理效率更高。