socket缓冲区溢出是内核静默丢包的明确信号，表现为recv()返回成功但帧实际丢失，/proc/net/can/stat中rx_queue_overrun计数器递增；根因包括应用读取滞后、内核默认256帧缓冲区过小（5mbps下8ms即溢出）、软中断处理不及（/proc/net/softnet_stat第二列增长）及网卡ring buffer满（rx_fifo_errors上升）。
Socket 缓冲区溢出不是“数据写不进去了”这么简单，而是内核开始静默丢包的明确信号。它往往不报错、不触发 errno，应用层 recv() 仍返回成功，但实际帧已消失——这种“幽灵丢包”正是性能瓶颈最隐蔽的源头。
接收缓冲区满：应用读取跟不上收包节奏
当应用调用 recv() 的频率或吞吐量低于网卡收包速率，接收缓冲区（sk_receive_queue）就会持续堆积。一旦填满，新到的 skb 就被内核直接丢弃，/proc/net/can/stat 中 rx_queue_overrun 计数器上涨，就是铁证。
- 检查当前接收队列使用情况：ss -tmi | grep -E "(recv|rmem)"，关注 rb（已用字节数）是否长期接近 rmem_max
- 确认应用是否阻塞式调用 recv()：未设 O_NONBLOCK 时，recv() 可能等待数毫秒，而 CAN FD 在 5 Mbps 下每 8ms 就能塞满默认 256 帧缓冲区
- GUI 类应用尤其危险：QApplication::processEvents() 若耗时 >5ms，就足以让缓冲区失守
内核接收队列太小：默认值撑不住高吞吐场景
SocketCAN 默认 per-socket 接收队列长度仅 256 帧，每帧占用约 384 字节 skb 开销，总容量不足 100 KB。在 CAN FD 5 Mbps 场景下，理论峰值达 3.2 万帧/秒，缓冲区 8ms 就溢出。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 临时提升上限（需 root）：sudo sysctl -w net.core.rmem_max=4194304（4 MB）
- 配合调整 socket 级接收缓冲区：setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &val, sizeof(val))，注意该值不能超过 rmem_max
- 对 CAN FD 应用，建议初始设为 1024~2048 帧，并结合实测 PPS 调整
软中断处理不过来：NET_RX 成了隐形堵点
即使网卡 DMA 把包送进内存，若软中断（NET_RX_SOFTIRQ）处理不及时，skb 会滞留在 softnet backlog 队列中，最终因队列满而丢弃。/proc/net/softnet_stat 第二列持续增长即为此类丢包。
- 监控单核软中断负载：mpstat -P ALL 1，观察 si% 是否长期 >50%
- 检查当前 netdev_budget 值：cat /proc/sys/net/core/netdev_budget，默认 300，可适当调高（如 600），但需避免单次处理过久影响调度
- 启用 RPS（Receive Packet Steering）将软中断分散到多核：echo f > /sys/class/net/can0/queues/rx-0/rps_cpus（十六进制掩码）
硬件与驱动层溢出：缓冲区上游已告急
若内核层还没来得及处理，网卡自身 FIFO 或 Ring Buffer 就先满了，也会导致丢包。此时 /proc/net/dev 中 rx_fifo_errors 或 rx_missed_errors 持续上升。
- 查看网卡统计：ethtool -S can0 | grep -E "(fifo|missed|drop)"
- 增大网卡 Ring Buffer（若驱动支持）：ethtool -G can0 rx 4096
- 确认驱动是否启用 NAPI：cat /proc/interrupts | grep can0，中断类型含 “NAPI” 表示已启用，否则可能轮询开销过大
