sar -n DEV 不直接输出利用率百分比，仅提供 rxkB/s、txkB/s 字节速率，需结合网卡理论带宽（如 1Gbps=122070 KB/s）换算：利用率 ≈ (rxkB/s + txkB/s) × 8 × 1024 ÷ 理论带宽 × 100%。
sar -n DEV 本身不直接输出“利用率百分比”，它只提供原始字节速率（rxkB/s、txkB/s），必须结合网卡理论带宽手动换算才能得到真实利用率。
为什么 sar -n DEV 的 rxkB/s 不等于网卡利用率
网卡标称带宽（如 1Gbps）是比特率，而 sar -n DEV 输出的 rxkB/s 和 txkB/s 是千字节每秒。两者单位不同，不能直接对比：
- 1 Gbps = 1000 Mbps = 1000 × 10⁶ bps ≈ 125,000 KB/s（因 1 Byte = 8 bits，1000×10⁶ ÷ 8 ÷ 1024 ≈ 122,070 KB/s）
- 若
sar -n DEV 1 1显示eth0的rxkB/s为 61035，则实际接收带宽 ≈ 61035 × 8 × 1024 ≈ 500 Mbps，即约 50% 利用率 - 忽略单位换算直接说“rxkB/s 达到 120000 就爆了”是典型误判——这已超千兆网卡理论上限，现实中不可能出现
如何用 sar -n DEV 快速估算实时利用率
执行命令后，需三步完成估算：
- 运行
ethtool eth0（替换为你的网卡名），确认Speed:值（如1000Mb/s），这是分母基准 - 运行
sar -n DEV 1 1 | grep eth0，取最新一行的rxkB/s和txkB/s值 - 按公式计算：利用率 ≈ (
rxkB/s+txkB/s) × 8 × 1024 ÷ 理论带宽（bps）× 100%
例如：网卡 Speed=1000Mb/s，sar 输出 rxkB/s=30000、txkB/s=20000 → (50000 × 8 × 1024) ÷ 1000000000 ≈ 41%
常见误读与采样陷阱
很多人看到 sar -n DEV 1 5 的输出就下结论，但以下情况会导致结果失真：
- 采样间隔太短（如
0.1）：内核计数器更新有延迟，rxkB/s可能为 0 或突增，不具代表性 - 未排除 loopback 流量：本地进程间通信（如 127.0.0.1）也计入
lo接口，但它不走物理网卡 - 多队列网卡（RSS）下，单个
rxkB/s值反映的是聚合流量，无法体现某 CPU 队列是否打满 - 使用
-f /var/log/sysstat/saXX查历史数据时，若 sysstat 服务未启用（ENABLED="false"），文件为空或只有部分字段
更直观的替代方案：什么时候别硬套 sar
当需要快速判断“此刻是不是被打满了”，sar -n DEV 不是第一选择：
- 查瞬时峰值：用
iftop -i eth0 -B，顶部第二行直接显示当前 RX/TX 总速率（Byte 单位），配合ethtool结果心算更快 - 查进程级来源：用
nethogs eth0，避免流量被聚合掩盖，比如发现某个 Java 进程占了 95% tx - 查长期趋势：用
vnstat -l，它基于内核计数器轮询，无抓包开销，且内置了按日/月的带宽占比统计
真正要用好 sar -n DEV，得接受它是个“事后归因工具”——你不是靠它报警，而是靠它验证“刚才那波延迟，是不是真由网络引起”。单位换算这一步，跳不过，也错不得。
