如何通过调优服务器网卡队列数量修复丢包问题

丢包是令人头疼的网络问题。一个常被忽视的原因，是服务器网卡队列数量配置不当而导致丢包。本文将展示一套系统化的处理流程。你可以先运行基础测试，例如使用 ping 测量丢包率，使用 iperf 模拟流量。这能帮助你建立一个基准参考。接着，你需要检查硬件丢包计数器，并将其与队列数量进行对比，从而定位问题。然后，你要确定适合网卡调优的最佳队列数量，使其与 CPU 核心数和实际工作负载相匹配。之后再调整队列数量，并验证修复效果。如果丢包仍然存在，就继续调优操作系统网络栈和网卡设置，例如增大环形缓冲区大小以及配置 irq 亲和性。完成这些调整的核心工具是 ethtool。每一步都应包含验证动作。你要在进入下一步之前先完成验证。这种方法能够直接定位根因，并高效解决问题。

诊断由队列数量配置不当引起的丢包

在你修改任何设置之前，必须先证明问题的根源确实是队列数量。服务器网卡队列数量配置不当导致丢包时，通常会表现出明显症状。你的任务就是找出这些症状，并排除其他可能原因。

运行基础丢包测试

先从一个简单的连通性测试开始。在客户端机器上对服务器运行 ping。发送大量数据包，至少几千个，这样结果才有统计意义。观察丢包百分比。健康的链路在轻负载下应当显示零丢包。如果在空闲网络中仍持续出现丢包，通常就说明存在配置问题。

接下来，使用 iperf3 生成真实流量。在目标机器上运行服务端，在对端主机上运行客户端，并持续压测一段时间。观察报告中的丢包率和重传次数。如果丢包只在负载上升后出现，那么队列数量就很可能是关键嫌疑点。轻流量只会使用少量队列，而重流量会扩散到所有队列。队列数量与 CPU 核心数不匹配的问题，往往正是在这种情况下暴露出来。

请重复测试多次。如果每次运行都能观察到间歇性丢包，那么你就得到了一个可靠的模式。单次异常结果也许只是噪声。

使用 ethtool -S 检查丢包计数器

现在开始查看硬件本身。对你的网络接口运行 ethtool -S。该命令会输出驱动层级的所有计数器。你需要重点关注两个值：rx_dropped 和 tx_dropped。rx 表示网卡已经接收到了数据包，但未能成功交给内核；tx 表示网卡未能成功发送数据包。

先记录下这些数值。等待一小段时间后，再次运行该命令，并比较两次结果。如果计数器在空闲期间仍不断上升，就说明确实存在问题；如果在高负载下计数器仍保持不变，则说明这一项基本正常。

接着，把丢包情况与当前队列数量进行对比。使用 ethtool -l 查看队列数量。如果你发现队列很多，而 CPU 核心却很少，那么内核就无法及时处理所有队列。中断会堆积，数据包等待时间过长，最终被丢弃。下表展示了如何判断这种模式。

现象	可能原因
rx_dropped 持续上升，且队列数超过 CPU 核心数	队列过多，超出可用核心处理能力
tx_dropped 在高负载下上升	队列过小或环形缓冲区耗尽
两个计数器都保持不变，但仍存在丢包	需要检查网卡之外的问题，例如线缆和交换机

还有一个额外检查会很有帮助。运行 ethtool -S，并 grep 每队列的丢包字段。许多驱动会按队列报告丢包情况。如果丢包集中在少数几个队列上，就说明流量分布并不均衡。这通常指向 IRQ 亲和性问题，后文会继续处理。

到这里，你已经掌握了证据。如果丢包计数器持续上升，同时队列数量与 CPU 布局不匹配，那么基本可以确认诊断结果。接下来进入下一步，计算合适的队列数量。

确定网卡调优的最佳队列数量

让队列数量匹配 CPU 核心数

网卡调优的第一条原则很简单：队列数量要与负责处理网络中断的 CPU 核心数匹配。每个队列都需要自己的中断向量。如果你创建的队列多于核心数量，内核就无法及时处理所有队列。数据包会排队等待，缓冲区会被填满，最终导致丢包。一个较好的起点，是每个物理核心对应一个队列。对于多核服务器，建议先按“每个物理核心一个队列”开始。你可以通过 ethtool -l 查看当前设置。这个命令会显示预设最大值以及当前激活的数量。

你还必须考虑超线程。逻辑核心会共享物理执行单元。按逻辑核心数分配队列，往往会引入争用。因此应优先从每个物理核心一个队列开始，然后再测试。如果 CPU 占用率保持较低，且丢包消失，那么你基本就找到了一个较好的平衡点。如果丢包仍然存在，有时并不是需要更多队列，反而可能需要更少。减少队列数量可以降低中断向量消耗，在高负载系统中甚至能够缓解中断丢包。

结合工作负载与队列分布来判断

你的工作负载类型会影响理想的队列分布方式。高吞吐型负载，例如大规模传输、AI 训练或存储流量，通常更适合更多队列以及更激进的中断合并。合并会让每次中断处理更多数据包，从而提升吞吐。相反，延迟敏感型负载，例如交易系统或实时交互流量，则需要相反的策略。关闭自适应合并，并尽量减少批处理，可以降低中断延迟。

下表展示了不同工作负载类型与合并策略及示例设置之间的对应关系。

工作负载类型	合并策略	示例 ethtool 设置
高吞吐型	启用自适应合并，或设置较高的手动值	`ethtool -C ens1f0 adaptive-rx on adaptive-tx on`
延迟敏感型	关闭自适应合并，并尽量减少批处理	`ethtool -C ens1f0 adaptive-rx off adaptive-tx off`

较大的队列有助于繁忙系统维持高吞吐，但也会带来更高延迟。若队列分布偏向吞吐优化，交互类数据包可能会排在大流量数据后面等待处理。如果你更想优化延迟而不是吞吐，可以关闭 TSO、GSO、UFO 和 GRO。除非系统正在处理极高的数据速率，否则你通常不会看到明显的 CPU 影响或吞吐下降。若你希望对排队字节数设定一个硬上限，可以将新值写入 limit_max 文件。

调整队列数量并验证修复效果

使用 ethtool -L 修改队列数量

你已经确定了目标值，现在可以开始应用。ethtool 工具能够在无需重启的情况下修改活动队列数量。使用 -L 参数并配合 combined 选项，即可同时设置接收和发送队列。

使用 ethtool -L 将网卡的发送与接收组合队列设置为 8
$ sudo ethtool -L eth0 combined 8

例如，对于一台 16 核服务器，你可以运行 ethtool -L ens1f0 combined 16 来设置最大值。修改后一定要用 ethtool -l 再次确认。这个命令会显示当前活动队列数。如果结果与你的目标一致，说明修改已生效。如果驱动拒绝该请求，就需要检查预设最大值。有些适配器会将 combined 的数量限制在固定范围内。

一次只修改这一个变量。此时先不要去调整环形缓冲区或中断合并参数。单变量变更能让测试结果更加清晰。

监控并重新测试丢包情况

修改完成后，立即重新检查丢包计数器。运行 ethtool -S，观察 rx_dropped 或 tx_dropped 是否继续上升。若计数器保持不变，则说明修复有效。你也可以通过 /proc/net/softnet_stat 查看内核层面的丢包情况。该文件中的第 2 列表示丢弃的数据包数量，第 3 列表示 time_squeeze，意味着 CPU 过于繁忙，无法及时处理流量。实时观察这些计数器，有助于捕捉新的丢包问题。

接下来，用 iperf3 进行吞吐测试。先启动服务端，再运行单流客户端测试，然后再用并行流压满链路。将结果与最初的基准进行比较。如果吞吐保持稳定且丢包消失，说明这次调整成功了。服务器网卡队列数量配置不当导致的丢包问题，通常会在这里体现出明显改善。

延迟同样重要。你可以先用 ping 做一个基础检查。如果想看更详细的时延分布，可以运行 sockperf ping-pong。这个测试能够发现 ping 可能遗漏的延迟抖动问题。

最后，还要留意副作用。监控 /proc/interrupts，观察中断速率如何变化。这个文件能帮助你验证每个接收队列是否映射到了合适的 CPU。不过，仅靠这个指标并不能可靠反映实际数据量，因为很多驱动在与 NAPI 子系统协同时会关闭网卡中断，而中断合并也会影响这些数字。为了获得更完整的视图，也请同时检查 /proc/softirqs。如果你发现 CPU 占用升高，或者出现新的延迟尖峰，就意味着需要重新评估队列数量。有时减少队列可以降低中断向量消耗，缓解中断压力。如果在完成这些检查后仍有丢包，就进入下一节做更深入的调优。

调优操作系统网络栈与网卡设置

如果在调整队列数量后丢包依然存在，就需要进一步深入调优。通常还剩两个问题：环形缓冲区过小，以及中断处理不均衡。把这两点修正后，往往就能解决问题。

增大环形缓冲区以减少丢包

环形缓冲区是在网络接口与内核之间起临时存储作用的区域。当突发流量超过缓冲容量时，网卡就会丢弃数据包。增大缓冲区大小，可以降低这种风险。

先检查当前的 nic ring buffer 设置。使用 ethtool -g 查看数值。该命令会显示每个队列对应的 rx 和 tx 环形缓冲区大小。若当前值较小，就说明还有扩展空间。

使用 -G 参数增大环形缓冲区。例如运行 sudo ethtool -G eth0 rx 4096 tx 4096。尽可能把接收与发送缓冲区都设置到较大的值，最大可到 4096。再用 ethtool -g 确认新的 ring buffer 大小。更大的 ring buffer 能在突发流量下为系统争取更多处理时间，从而在不改变队列数的前提下减少丢包。不过，更大的缓冲区也会增加延迟。对于延迟敏感型负载，建议测试较为适中的数值。

配置 IRQ 亲和性以实现负载均衡

即使队列数量正确、nic ring buffer size 也设置得当，如果中断分布不均衡，仍然可能造成丢包。每个接收队列都会产生一个中断请求。当多个 IRQ 集中落在同一个核心上时，该核心会过载，而其他核心却处于空闲状态。配置 irq affinity 的目的，就是把负载均匀分散开来。

先检查中断分布。运行 cat /proc/interrupts | grep ethX，查看哪些核心正在处理网络中断。再结合 top 观察 CPU 使用情况。若发现分布明显不均，就说明问题存在。

你可以通过 irqbalance --debug 调试 IRQ 分布。如果自动均衡未启用，就需要手动为每个队列设置 CPU 核心亲和性。将核心掩码写入 /sys/class/net/ethX/queues/rx-0/rps_cpus。例如，要把队列 0 分配给 CPU 核心 0，可以向该文件写入数值 1。你可以先通过 lscpu | grep '^CPU(s):' 列出可用核心，以确定正确的掩码。

均衡的 irq affinity 能降低单核心压力，防止丢包不断积累。配合合适的 nic ring buffers 后，你的 nic settings 将能够更高效地处理流量。如果问题仍未解决，可以进一步减少队列数量。更少的队列可以降低中断向量消耗，从而减轻 IRQ 丢包。你还可以在网络接口上配置 QoS，优先保障关键流量。

此外，还可以在操作系统层面调整 Linux 内核的接收与发送缓冲区。使用 sysctl 修改 net.core.rmem_max 和 net.core.wmem_max。把它们设置得更高，可以更好地容纳突发流量，从而承接那些已经通过网卡、但超过内核处理能力的数据包。

现在你已经拥有一套四步处理流程。第一步，用丢包计数器诊断问题。第二步，根据硬件选择最佳队列数量。第三步，使用 ethtool 应用修改。第四步，在必要时继续调优操作系统网络栈。每次只改动一个变量，验证每一次结果，并记录所有设置。服务器网卡队列数量配置不当导致丢包，是一个很常见的问题，但它完全可以被修复。不妨今天就花几分钟检查一下你的服务器队列数量，这也许能帮你省下数小时的网络排障时间。