真实队列溢出对应ip -s link show eth0输出中四列：RX dropped（内核处理不过来）、RX overruns（Ring Buffer硬件溢出）、TX dropped（发送队列或qdisc丢弃）、TX carrier（物理链路断连，非队列溢出）。
ip -s link 里哪几列代表真实队列溢出
直接看 ip -s link show dev eth0 输出中 RX 和 TX 下的四类字段，它们各自对应不同层级的溢出，不能混为一谈：
-
RX: dropped：内核网络子系统（NAPI、softirq）来不及处理，主动丢弃的包。常见于 CPU 软中断瓶颈、netdev backlog 满（net.core.netdev_max_backlog太小） -
RX: overruns：网卡 Ring Buffer 溢出，DMA 写入速度 > 内核取走速度，硬件层就丢了。这是最硬的“队列溢出”，必须调ethtool -G -
TX: dropped：内核发送队列（txqueuelen）满，或 qdisc 主动丢弃（如 fq_codel 队列满、tc rate limit 触发）。注意：tc 限速导致的丢包不计入此列 -
TX: carrier：物理链路反复断连（比如网线松动），每次 up/down 都会累加，不是队列问题，但容易被误判为“异常丢包”
为什么 netstat -s 的 “packet receive errors” 不算队列溢出
这个统计项在 netstat -s 输出里看着像丢包，但它实际是 IP 层及以下（含驱动、DMA、校验）所有错误的总和，比如 CRC 错、帧长非法、内存分配失败等。它不区分是否因 socket 缓冲区满而丢，更不反映 Ring Buffer 或 txqueuelen 溢出。
真正对应 socket 级接收缓冲区溢出的是 /proc/net/snmp 里的 Tcp: 行第 19 列：tcpRcvQDrop。执行 grep Tcp /proc/net/snmp | awk '{print $19}' 即可拿到累计值——只要这个数在涨，说明应用读得太慢或 rmem_default 设得太小。
ethtool -g 查到的 RX/TX 值高 ≠ 没溢出
ethtool -g eth0 显示的是当前 Ring Buffer 设置，但“设得大”不等于“没溢出”。关键要看 ip -s link 中 overruns 是否非零且持续增长：
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 如果
overruns > 0，说明即使 Ring Buffer 已设到硬件上限（如 8192），仍不够用，得查 CPU 软中断是否打满、RSS 队列是否未均衡、或是否被单核瓶颈卡住 - 某些虚拟网卡（如
virtio_net）不支持ethtool -g，输出No data available，此时overruns只能靠增大txqueuelen和调优 vhost/virtio 参数缓解 -
Pre-set maximums是硬件上限，硬设超限会报Operation not supported，别试
容器或虚拟机里看到 TX dropped 高，别急着改 guest
在 Docker 或 KVM 虚拟机里跑 ip -s link，如果发现 eth0 的 TX: dropped 明显上升，大概率不是容器/VM 里程序的问题，而是宿主机上桥接设备（如 br0、veth 对端、ovs 端口）的队列溢出。这时要切到宿主机，查对应 veth peer 或 bridge 接口的 ip -s link 输出。
特别注意：Kubernetes Pod 网络中，TX dropped 高往往指向 CNI 插件队列（如 calico 的 cali 接口）、或宿主机内核 qdisc 配置不合理（如默认 pfifo_fast 队列长度仅 1000），而非 Pod 内应用本身。
队列溢出不是单一数字，是三层（硬件 Ring Buffer、内核 txqueuelen、socket rmem）叠加作用的结果。盯错一列，调参就全偏了。
