go视频转发卡顿主因是linux内核napi轮询预算不足，需协同调优netdev_budget_usecs（建议10000μs）、netdev_budget（配多队列设600）、netdev_max_backlog（设为ring buffer的2–3倍）及网卡ring buffer（如4096），并强制rss绑核实现负载均衡。
Go 视频转发服务在高码率、多路并发场景下卡顿、丢帧、延迟飙升，大概率不是 Go 代码或业务逻辑的问题，而是 Linux 内核网络收包路径被堵住了——关键堵点就在 NAPI 轮询预算上。
netdev_budget_usecs 设置过小导致轮询提前退出
Go 程序靠 epoll + read() 从 socket 拿数据，但前提是内核已把网卡数据搬进协议栈。如果 netdev_budget_usecs 太小（默认仅 2000 µs），NAPI 在软中断里刚跑几毫秒就强制退出，大量包还卡在网卡 Ring Buffer 或 softnet_data->input_pkt_queue 里，应用层自然读不到新包，缓冲区“饿死”，视频就卡。
- 万兆网卡 + 多路 4K 流场景下，默认值明显不够，实测建议从
5000起步，逐步加到10000（即 10ms） - 验证是否有效：持续观察
/proc/net/softnet_stat第 1 列（processed）与第 2 列（dropped）比值；若dropped持续上升，说明预算仍不足 - 临时调：
sudo sysctl -w net.core.netdev_budget_usecs=10000 - 持久化：写入
/etc/sysctl.d/99-napi.conf，内容为net.core.netdev_budget_usecs = 10000 - 注意：
netdev_budget_usecs不是越大越好；超过 20ms 可能挤压 timer、block 等其他 softirq，引发调度抖动
netdev_budget 与网卡多队列协同失效
Go 进程若只绑一个 CPU（如 taskset -c 3 ./video-forwarder），而网卡开了 16 队列却没做 RSS 均衡，结果大部分包全打到某几个 CPU 的 softnet_data 上，这些核的 NAPI 负载远高于其他核。此时光调大 netdev_budget（默认 300）只会加剧单核软中断饱和，甚至触发 skb_drops。
- 先确认队列分布：
cat /proc/interrupts | grep eth0，看各 CPU 上rx中断是否均衡 - 确保网卡启用多队列：
ethtool -l eth0，再用ethtool -L eth0 combined N设为与逻辑 CPU 核数一致（如 20 核设 20 队列） - 配合 RSS 绑核：用
echo 3 > /proc/irq/<irq_num>/smp_affinity_list</irq_num>把每个队列中断绑定到不同 CPU -
netdev_budget建议同步调至600，但必须和多队列 + 绑核一起生效，否则无效甚至有害
netdev_max_backlog 和 Ring Buffer 必须同步扩容
netdev_max_backlog 是内核软中断处理前的中间队列长度，它和网卡 Ring Buffer 共同构成“两级缓冲”。若 Ring Buffer 已满（ethtool -g eth0 查当前值，常见默认仅 512），包在进内核前就被网卡丢弃；若 netdev_max_backlog 太小（默认常为 3000），包过了 Ring Buffer 却卡在 input_pkt_queue 里，照样被 softnet_data 丢掉。
- 先扩 Ring Buffer：
ethtool -G eth0 rx 4096 tx 4096（上限查ethtool -g eth0） - 再调
netdev_max_backlog：建议设为 Ring Buffer RX 值的 2–3 倍，例如sudo sysctl -w net.core.netdev_max_backlog=12288 - 这两个值不匹配时，调高任一者都难见效；尤其在突发流量下，
netstat -s | grep "packet receive errors"若出现overrun或drop，基本就是这里没对齐
真正卡住 Go 视频流的，往往不是单个参数，而是 netdev_budget_usecs、netdev_budget、netdev_max_backlog 和网卡 Ring Buffer 四者之间的时间与容量错配——漏掉任意一环，优化都会打折扣。最易忽略的是 RSS 绑核未做，导致所有调优只压在一个 CPU 上白忙活。
