net.core.netdev_max_backlog只管控网卡DMA区到内核软中断（NET_RX）处理前的per-CPU backlog队列丢包，即软中断处理不及导致的RcvbufErrors增长，不涉及硬件ring buffer或socket接收缓冲区。
net.core.netdev_max_backlog 到底管哪一段丢包
它只管“网卡 DMA 区 → 内核软中断（NET_RX）→ 协议栈”这一跳中间的积压队列，不是硬件 ring buffer，也不是 socket 接收缓冲区。当软中断处理不过来，包就会堆在这里；满了就直接 drop，rx_dropped 计数上涨，但 ethtool -S eth0 里看不到硬件错误。
- 典型信号是：
watch -n1 'cat /proc/net/snmp | grep -i rcvbuferrors'中RcvbufErrors持续增长（内核 5.10+ 准确） - 老内核可辅助看：
cat /proc/net/netstat | grep -A1 "TcpExt:" | grep ListenOverflows，但不等价，别全信 - 更准的交叉验证：
ethtool -S eth0 | grep rx_packets（网卡收了多少） vsnetstat -s | grep "segments received"（协议栈收了多少），差值突增 +top -1里%si> 60%，才说明真卡在这儿
调大之前必须确认软中断没被绑死在单核
如果所有网卡中断都打到 CPU 0，你把 netdev_max_backlog 设成 10 万也没用——那个核的 softirq 根本跑不过来，反而掩盖真实瓶颈。
- 先查 IRQ 分布：
cat /proc/interrupts | grep eth0，看各 CPU 行数字是否大致均匀 - 开 RSS（多队列分流）：
ethtool -L eth0 combined $N，其中$N一般是逻辑 CPU 总数 - 手动绑定 IRQ（可选）：
echo 1 > /proc/irq/<code>IRQ_NUM/smp_affinity_list，需配合grep eth0 /proc/interrupts找出对应 IRQ 编号 - 推荐用
irqbalance自动管理，或写 systemd service 在启动时固化
怎么设值、生效、验证是否真起作用
默认 1000 对千兆以下够用，10G+ 小包场景建议从 3000～6000 起步，别一上来就设 20000——值太大可能增加延迟，且无实际收益。
- 临时生效：
sysctl -w net.core.netdev_max_backlog=5000 - 永久生效：写入
/etc/sysctl.conf后运行sysctl -p - 验证已加载：
cat /proc/sys/net/core/netdev_max_backlog - 上线后盯住三件事：
RcvbufErrors是否停止增长、%si是否回落、端到端延迟是否稳定
别和 TCP 层 backlog 搞混
net.core.netdev_max_backlog 解决不了这些事，调它纯属白忙：
-
ListenOverflows：那是net.core.somaxconn或应用accept()太慢，属于全连接队列溢出 -
TCPBacklogDrop：那是 socket 级接收队列满，由net.core.rmem_max和应用读取速度决定 -
rx_missed或rx_over_errors：那是网卡 ring buffer 太小，得用ethtool -G eth0 rx 4096调，不是这个参数管的
