load average不直接反映网络带宽，但网络饱和可通过驱动队列堆积、发送队列积压、软中断飙升及d状态进程卡在协议栈等路径间接推高load，需结合ethtool、ss、/proc/net/dev、/proc/interrupts、/proc/softirqs等交叉验证。
系统平均负载（Load Average）本身不直接反映网络带宽使用情况，它主要体现的是就绪态和不可中断态进程的平均数量，受CPU、磁盘I/O、内存换页甚至锁竞争等多方面影响。因此，**不能单靠load值高低判断网络带宽是否达到物理上限**。但当网络I/O成为系统瓶颈时，它可能通过特定路径间接推高负载，并伴随可验证的I/O特征。关键在于建立“网络带宽饱和 → 驱动层/协议栈阻塞 → 进程等待加剧 → load上升”的因果链，并用配套指标交叉验证。
看网络I/O是否持续占满设备队列
带宽打满时，网卡驱动常出现发送队列（tx queue）堆积或频繁丢包，这是最贴近物理层的信号：
- 执行 ethtool -S eth0 | grep -i "queue\|drop"，关注
tx_queue_*_packets和tx_aborted_errors、tx_carrier_errors；若发送队列长期非空且错误数增长，说明网卡已无法及时发出数据 - 用 ss -i 查看TCP连接的发送队列（
send-q列），大量连接显示非零值（如 >1MB），表明应用层数据压在内核协议栈发不出去，可能是网卡或中间链路带宽不足 - 检查 /proc/net/dev 中对应接口的每秒接收/发送字节数，与理论带宽（如1Gbps ≈ 125MB/s）对比；持续稳定接近该值且无明显波动，是带宽跑满的强提示
结合中断与软中断分布分析
高带宽吞吐会显著增加网卡硬中断（IRQ）和网络收包软中断（NET_RX、NET_TX）负载：
- 运行 cat /proc/interrupts | grep eth0，观察对应CPU上该网卡中断计数是否随流量线性飙升；若某CPU中断占比长期超60%，可能引发调度延迟
- 用 top -1 并按 1 显示各CPU，重点关注
%si（softirq）是否持续高于20%；再执行 cat /proc/softirqs | grep -E "(NET_RX|NET_TX)" 确认网络软中断次数是否异常高 - 此时若系统load值同步升高，且
top中大量进程状态为D（uninterruptible sleep），尤其集中在net_rx_action或tcp_transmit_skb调用栈中，说明网络协议栈处理已成瓶颈
排除其他I/O干扰，聚焦网络路径
避免把磁盘I/O或内存压力误判为网络问题：
- 用 iostat -x 1 检查
%util和await，确认磁盘未饱和；若磁盘响应时间长但网络流量低，load高大概率与存储有关 - 运行 vmstat 1，观察
bi（块设备输入）和bo（块设备输出）是否远高于网络收发量；若bi/bo数值大而in（中断次数）不高，则问题不在网络 - 检查 /sys/class/net/eth0/statistics/ 下的
rx_errors、tx_errors、rx_fifo_errors，FIFO错误增多常意味着驱动来不及处理包，是带宽逼近上限的早期迹象
验证链路实际吞吐与协商速率
物理带宽上限由最弱一环决定，需逐段确认：
- 用 ethtool eth0 查看当前协商速率（如
Speed: 1000Mb/s）和双工模式；若显示100Mb/s却预期千兆，可能是网线、交换机端口或网卡自协商失败 - 对端设备（交换机、对端服务器）同样执行 ethtool 或查看端口统计，确认双向链路速率一致；常见瓶颈是服务器到核心交换机之间仅有一条1G链路，而业务聚合流量早已超限
- 使用 iperf3 在两端直连测试：服务端
iperf3 -s，客户端iperf3 -c <server> -t 30 -P 4</server>；若实测带宽稳定在940MB/s左右（10Gbps网卡），说明链路正常；若仅达300MB/s且ethtool显示10G，则问题出在TCP窗口、拥塞控制或中间设备限速
