3. 网络性能度量指标

做网络排查这么多年，我见过太多团队只盯着吞吐量看。一上来就问“带宽跑满了没”，好像只要带宽没用完，网络就没问题。其实，真正的瓶颈往往藏在你看不见的地方。 今天我把五个最关键的度量指标掰开揉碎了讲。你搞懂它们，才算入了千兆以太网调优的门。

吞吐量（Throughput）—— 实际能传多少

吞吐量，说白了就是单位时间内真正从A到B传过去的数据量。单位常用Mbps或Gbps。注意了，这不是你网卡标称的1Gbps，而是排除协议开销、丢包重传之后剩下的净数据。

我在项目中遇到过一位运维兄弟，拿着iPerf一测，吞吐只有800Mbps，立刻骂运营商缩水。我一查，TCP窗口设得太小了，加上服务器网卡TSO没开，白白浪费了近200Mbps的潜力。

延迟（Latency）—— 数据走一趟要多久

延迟就是字节从发送端到接收端所用的时间，单位毫秒。很多应用对延迟非常敏感，比如VoIP、金融交易。千兆以太网里，延迟主要来自交换机的转发时延、光纤传播时延和主机协议栈处理时延。

我记得有一次排查一个远程桌面卡顿的问题。带宽利用率才20%，但用户就是感觉操作不跟手。一测RTT 150ms，原来跨了三个跳，中间有一台老式交换机缓存太小，造成了队列延迟。换成低端口的直连链路，延迟降到5ms，问题秒解。

丢包率（Packet Loss）—— 丢了多少个包

丢包率是丢失的数据包占发送总数的百分比。千兆网络里，丢包哪怕只有0.1%，TCP吞吐量可能腰斩。因为TCP检测到丢包会启动拥塞控制，窗口瞬间减半。

你想想看，你跑着大文件传输，链路丢包率0.5%，实际吞吐可能从950Mbps掉到400Mbps。这时候查丢包原因，多半是出口队列溢出、光模块光衰过大，或者网卡CRC错误。

带宽利用率（Bandwidth Utilization）—— 链路用了多少

带宽利用率 = 当前传输速率 / 链路最大速率。很多人看到利用率只有30%就觉得“还很宽松”。但你要知道，利用率只是平均值，网络拥塞发生在微秒级的突发瞬间。你抓个15秒的平均利用率只有20%，可中间有5毫秒的尖峰直接把交换机缓存打满了，延迟和丢包就跟着来了。

我建议你在统计利用率时，同时关注峰值和分布。用sflow或netflow采样，或者直接看交换机的队列丢弃计数器。利用率高不可怕，可怕的是利用率不高但队列还在丢包——那是微突发。

PPS（Packets Per Second）—— 每秒你能处理多少个包

这个指标很多新手会忽略。你想想看，千兆以太网在64字节小包下，理论PPS约1.488Mpps。但主流CPU软转发能跑个几百kpps就不错了。带宽没用完，PPS先爆了，也是常见瓶颈。

我记得有一次帮一个视频监控平台调优。摄像头只发512字节的小包，带宽利用率才400Mbps（40%），但服务器CPU软中断已经到了80%。一查，网卡中断合并没开，每包都产生中断。我建议开启RSS（接收端缩放）和中断合并，PPS从80万骤降到12万次中断/秒，CPU利用率降到15%，吞吐反而因为CPU不再被中断淹没而升到了接近线速。

PPS的衡量工具可以用 sar -n DEV 1 或 ethtool -S eth0 | grep rx_packets。如果你看到rx_packets/rx_dropped比例异常，基本可以判定是PPS瓶颈。

五个指标必须联合使用

看了上面的SVG图，你应该明白了：这五个指标互相影响、缺一不可。我个人的排查路数是这样的：

1. 先看带宽利用率， 如果接近满载，优先扩容或分流。
2. 丢包如果 >0.1%，查队列、查光模块、查网卡错误。
3. 丢包和延迟都正常，但吞吐上不去， 测PPS。小包场景PPS爆了，优化CPU亲和性和网卡卸载。
4. 偶尔看一眼统计窗口的微突发。 我习惯用sflow的1秒粒度去抓峰值，如果峰值超过了链路容量，那就是微突发造成丢包，需要做流量整形。

好了，五个指标的概念、测量方式和协同使用，咱们都过了。下回你再做网络排查，希望你能跳出“跑满带宽就是好”的惯性，从吞吐、延迟、丢包、利用率、PPS这五个维度去诊断。这才是专业工程师的做法。