负载均衡接入后cpu满载丢包，本质是软中断（如ksoftirqd）霸占cpu导致收包不及，与网络或后端状态无关；需通过top -h、/proc/interrupts、ethtool -s定位网卡中断集中和丢包证据，并优化irqbalance、ring buffer、rps或多队列网卡。
负载均衡接入后出现CPU满载并伴随丢包，不是配置没生效，而是转发链路在系统层面已“堵死”。核心问题是：负载均衡器自身算力耗尽，连接收、分发数据包都来不及，自然会丢弃新到的包——这和后端服务是否健康、网络线路是否通畅无关。
看懂CPU满载的真实含义
CPU满载不等于“程序卡了”，而是内核软中断（尤其是网卡收包中断）长期霸占CPU时间。典型表现是top里ksoftirqd进程持续100%，而用户态进程（如nginx、haproxy）占用很低。此时即使带宽充足、后端全绿、健康检查通过，也会稳定丢包。
- 软中断过高常见于短连接高频场景（如HTTP API暴增、游戏心跳包密集）
- 虚拟机环境尤其敏感：单个vCPU被中断独占后，其他核无法分担收包任务
- 注意区分：CPU使用率高 ≠ 负载高；load average飙升但%wa（IO等待）也高，说明可能是磁盘或网卡buffer溢出引发的连锁反应
快速确认是否为软中断瓶颈
别急着重启或扩容，先用三步验证：
- 运行top -H，按Shift+P排序，观察是否大量ksoftirqd/*线程占满CPU
- 执行cat /proc/interrupts | grep eth，看网卡中断是否集中绑定在某1-2个CPU核上
- 用ethtool -S eth0 | grep -i "drop\|overrun"查rx_over_errors或rx_missed_errors是否持续增长——这是网卡因CPU处理不过来而直接丢包的铁证
针对性调优动作
问题定位清楚后，优化要从硬件调度层入手，不是简单加核：
- 启用并校准irqbalance服务，确保网卡中断分散到多个CPU；若已开，检查/proc/irq/*/smp_affinity_list是否真有分布
- 增大网卡ring buffer：ethtool -G eth0 rx 4096 tx 4096（需驱动支持），缓解突发流量冲击
- 物理机建议启用RPS（Receive Packet Steering）：echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus（十六进制掩码设多核）
- 虚拟机环境优先换用virtio-net多队列网卡，并在宿主机侧开启vhost-net加速
警惕“高配假象”陷阱
很多用户租用16核BGP高防服务器，却仍满载丢包——根本原因常是业务未适配。比如：
- 后端服务返回大JSON，负载均衡做SSL卸载+gzip压缩，CPU全耗在加解密和压缩上
- 健康检查路径配成/healthz，但后端每次响应都要查数据库，导致LB频繁重试加重负担
- 日志级别设为debug，海量access_log写磁盘触发IO等待，间接拖垮软中断处理
