ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Linux 网卡丢包率高如何使用 ethtool 和 netstat 排查

Linux 网卡丢包率高如何使用 ethtool 和 netstat 排查 先别急着下调丢包率得确认丢的是哪一层的包。很多人看到 sar 或 ifconfig 里 drop 增长第一反应就是换网卡、开多队列但有时候这些计数增长是正常的比如多播过滤掉不需要的包或者业务流量本身就有大量 UDP。排查前先想清楚是接收还是发送丢包是物理层错误还是队列溢出这决定了你该看 ethtool 还是 netstat。先看接口统计再决定下一步判断丢包不能只看网卡中断计数。在确认丢包率前先要明确是哪一层丢包。使用ip -s link查看接口统计关注rx_dropped和tx_dropped。同时结合ethtool -S输出特别是rx_crc_errors、rx_length_errors等错误计数。如果这些数值持续增长说明物理层或驱动层存在问题但仍需确认是否由突发负载或环回溢出引起。这个步骤的意义在于把问题分层。如果rx_crc_errors增长那大概率是网线、光模块或对端设备的问题换驱动或调 ring buffer 意义不大。如果只是rx_dropped增长而错误计数为零说明包是收到了但没来得及处理这时才值得去调队列参数。你可以先抓两次ip -s link输出间隔十几秒对比计数变化确认增长趋势再决定要不要继续往下查。用 ethtool -S 看驱动层的细节ethtool -S 是排查网卡丢包的首选工具。执行ethtool -S eth0后重点查看rx_dropped、rx_missed、rx_fifo_errors等。rx_missed表示因接收队列满而丢弃的包常见于环回缓冲区过小或中断合并导致处理不及时。当rx_missed或rx_fifo_errors非零时优先考虑调整 ring buffer 大小即ethtool -G eth0 rx 4096但需注意驱动支持且修改后若未持久化重启会恢复。这些计数器在 Intel 和 Mellanox 网卡上命名不一定相同比如有的叫rx_missed_errors有的叫rx_no_buffers。先看你的驱动版本和型号再对照字段含义。调整 ring buffer 时建议先调大看效果比如从默认值翻倍观察丢包计数是否停止增长。如果调整后效果不明显可以再看看中断合并参数因为有时候是中断合并让包在硬件缓冲区里积压太久触发溢出。修改 ring buffer 后要确认驱动是否支持动态调整有些驱动要求先 down 接口再改。另外ethtool -G 改的是运行时配置重启后失效需要写入配置文件或使用 systemd 服务来持久化。netstat -i 和 etxt 的区别netstat -i 提供接口级别的汇总能快速比较输入输出的错误和丢弃。netstat -s 将协议层的统计展开例如 TCP 的重传和丢失但这块信息粒度较粗难以定位网卡问题。推荐先用 netstat -i 定位到接口再用 ethtool -S 深入细节。另外netstat -i 中的 RX-ERR 和 TX-ERR 反映由驱动上报的错误而 RX-DRP 和 TX-DRP 表示驱动丢弃的包两者含义不同需要区分。实际操作中我习惯先跑netstat -i看哪块接口有异常如果 RX-ERR 或 RX-DRP 不断增长再用 ethtool 查具体原因。netstat -s 里也有 IP 层和 TCP 层的丢包统计但那些计数受路由、防火墙、socket 缓冲区等因素影响不能直接归咎于网卡。例如TCP 的ListenDrops增长是因为 accept 队列满这跟网卡无关需要改的是应用或内核的 somaxconn 参数。中断合并参数需要小心调整排查丢包时容易忽略中断合并的影响。ethtool -c 可以查看当前中断合并参数。如果 rx-usecs 设置过大网卡会积累一批包再触发中断在负载波动时可能溢出缓冲区。可以考虑适当减小 rx-usecs 或 rx-frames但代价是增加 CPU 开销。修改前先确认驱动支持并使用 ethtool -c 查看当前值修改后观察丢包计数是否回落。中断合并是为了减少 CPU 中断次数而设计的但业务流量是突发型的在短时间涌入大量包时合并机制会延迟处理导致缓冲区不够用。如果你的业务是高频小包比如 DNS 或游戏服务器适当减小 rx-usecs 通常能改善如果是大流量持续传输反而会增大 CPU 开销。调整时可以从默认值的一半开始观察 CPU 使用率和丢包计数找到平衡点。先排除正常丢包再看驱动日志某些丢包计数增长并不代表网络故障。例如接口启用多播过滤时未被需要的多播包会在硬件层被丢弃rx_dropped 会增长但这是正常现象。另外网络命名空间或 iptables 规则也可能导致包被丢弃但这不属于网卡层。因此在判断丢包问题时先审查业务环境必要时用 tcpdump 抓包确认是否有其实发的流量。除了计数器dmesg 也应该看一眼。同时使用 dmesg 检查内核日志可能发现 NIC 的警告或错误。例如“eth0: link up”或“r8169: link down”等事件但有些驱动仅在严重故障时上报如缓冲区溢出会打印“eth0: dropped packet”消息。若 dmesg 频繁出现类似记录说明驱动层已有明显异常此时调整参数作用有限应考虑更新驱动或更换网卡。有一个小问题需要注意如果你在虚拟机或容器里排查看到的网卡统计可能是宿主机虚拟交换机的统计不是物理网卡的真实情况。这种情况下ethtool 输出的字段和含义未必完整需要结合宿主机的监控来判断。最后丢包率不是一个固定数值能定义的同一台机器在不同 load 下的表现完全不同。建议先收集一段时间的基线数据比如用 sar -n DEV 或 ifstat再结合业务流量变化来判断。改任何参数前记录当前配置方便回滚。
返回列表