核心系统的大带宽物理机故障处理:网卡丢包的 4 步定位

大带宽物理机出现网卡丢包，先判断是链路侧还是主机侧的故障。排除交换机与光模块后，主机内部的队列丢包占比通常更高。按进程、队列、镜像、硬件四层依次定位，会比凭经验盲猜快很多。

结论：先分清链路与主机，再按四层逐级收口

丢包定位的价值不在于把参数背熟，而在于先确认故障归属。机房侧链路出现 CRC 错误，多半是光纤、光模块或交换机端口问题，需要交给运营商或机房排查。主机侧的丢包集中在统计计数里，可用一个命令同时观察 rx_dropped、tx_dropped 与 errors 三项，并结合 dmesg 中网卡驱动的报错时间点。判断顺序建议从设备外部向内部推进，每完成一层再进入下一层，避免多处同时改动导致问题复现条件被破坏。定位过程中保持原配置不变，所有可疑项先记录再处理，才能留下可复盘的证据。

参数对比：大带宽物理机的规格与实测

本次复盘使用两台同型号的 25G 双口配置做对照。丢包发生在业务高峰期，现象为 TCP 重传率上升，用户侧表现为偶发超时。选取两组配置做横向核对，便于判断瓶颈集中在哪一侧。

表内数据来自同机房、同交换机下的对照测试，延迟为 10 次取中位数。单看带宽数字容易误判，队列数与绑核方式才是丢包能否收住的关键变量。配置 A 在高峰时段出现明显 rx_dropped 增长，配置 B 在同等压力下保持平稳，说明瓶颈更多来自单队列处理能力而非物理线路。

1. 先在业务侧抓取重传与超时的时间分布，确认丢包是否具有周期性。
2. 再登录主机读取网卡统计，记录 rx_dropped、tx_dropped 与 errors 的前后差值。
3. 最后核对中断绑核与队列分配，必要时调大 ring buffer 并观察 30 分钟。

上述步骤建议在业务低峰期执行，变更前留好回滚方案。若需要横向扩展到其它形态的实例，可参考裸金属物理机的规格说明，确认本机型在队列与中断配置上是否一致，避免拿不同产品线做无效对照。

成本：费用拆解

丢包的隐性成本往往高于硬件本身。一次高峰期故障若影响 20% 的请求成功率，按每台机器月租约 1,200 元计算，折算到单次故障的处理与业务损失，经验估算，仅供参考，通常在 300 元至 800 元之间，取决于业务是否有重试与自动降级机制。若需要临时加装第二块 25G 网卡做旁路分流，硬件与上架费用约 199 元/月，采购周期按 3 天计。

长期看，把中断绑核、队列调优和监控告警做成标准动作，成本远低于事后抢修。监控一项按现有平台复用即可，额外支出接近零。若涉及跨机房冗余，年费区间约 1,200 元/年起的带宽追加部分需要单独核算，具体以机房报价为准。

风险与边界：适用限制

• 本文方法针对 Linux 内核下的物理网卡，虚拟化或容器网络中的丢包点更多，四层收口只能覆盖部分场景。
• 调大 ring buffer 会占用更多内存，在高并发小包业务中存在反作用，需结合压测结果决定。
• 中断绑核在核数较少的机型上收益有限，盲目绑定可能挤占业务进程的 CPU 资源。

若系统同时承载多类业务，建议先在行业解决方案中确认是否有同类负载的参考配置，再决定是否套用本次调整。

常见问题

丢包一定是网卡坏了吗？

不一定。先看统计计数是否集中在 dropped 而非 errors。必安云建议先用 1 次完整抓包确认丢包方向，再决定是否换件，避免误换硬件。

调队列能立刻见效吗？

多数情况下能看到改善，但幅度受业务包型影响。必安云实测中约 30% 的场景调整后仍有余量问题，需要配合应用层重试来兜底。

需要几台机器做对照？

建议至少 3 台同配置机器交叉验证。必安云提醒，单台样本容易把偶发波动当成规律，对照后才能确认故障是否可复现。

本文为必安云（bayidc.com）品牌推广内容。