游戏卡顿白皮书 › L6 服务器网卡
网卡中断集中在单个核心 Single-queue NIC / no RSS
原因 ID nic-irq · 主责 运维团队·系统运维
在含图示和实验的完整版中打开此卡片 →
网卡把数据包到达中断只发给一个 CPU 核心时，这个核心就会成为瓶颈。
起因 只有一个接收队列，或者把负载分散到多个核心的 RSS 没有开启 → 结果 单个核心跑满 100%，来不及取出数据包 → 画面表现 人多时全服出现丢包和延迟（瞬移、操作延迟）
- 症状
- 瞬移, 拉回, 操作延迟
- 因素
- 丢包, 延迟
- 谁会遇到
- 全服
- 何时出现
- 人多的时候
- 负责方
- 主责 运维团队·系统运维
- 运维团队要做的事
- 配置 RSS（由网卡分散）、RPS（由内核分散）；把中断分散到多个核心；让 UDP 连端口一起参与队列划分（ethtool -N 的 rx-flow-hash udp4 sdfn）；把处理中断的核心与游戏 tick 线程所在核心分开；监控各核心的 %soft。
- 数值参考
- 单个核心经内核协议栈能处理的量，视包大小和配置而定，大约每秒几十万个包。在各核心的使用率中，接收处理所占的比例（mpstat 的 %soft）只集中在一个核心上，就是这种情况。
- 监控图上
- 触顶后走平 · 各核心 %soft、每秒接收包数
- 查看位置
- 用 mpstat -P ALL 1 看各核心的 %soft（软中断处理占比），用 /proc/interrupts 看网卡各队列的中断分到了哪个核心，用 ethtool -l 看队列数，用 ethtool -S 看各队列的包数（名称因驱动而异）
- 确认依据
- 只有一个核心的 %soft 贴近 100%，其余核心空闲，中断和数据包集中在一个队列。从那时起每秒接收包数再也涨不上去
- 排除依据
- %soft 均匀分布在多个核心上，则不是这个原因。CPU 空闲却有丢包，看“超出云 PPS 上限”或“环形缓冲区不足”
- 确认手段
- 运维工具即可确认（无需游戏代码）
- 深入了解
- 即使有多个队列，如果大部分流量像网关、代理那样来自少数几个地址，也会集中到一个队列。对 UDP，有些网卡默认只按地址划分队列，要改成连端口一起计算才能分散均匀。
出处
- Scaling in the Linux Networking Stack Linux kernel
RSS（网卡分散到多个接收队列）、RPS（内核分散）；每个队列使用独立中断并分配到多个核心的配置；接收中断处理成为瓶颈时推荐 RSS - How to receive a million packets per second Cloudflare
实测：单个接收队列只交给一个核心时，该核心在每秒约 35 万~43 万个包时到顶；网卡只按 IP 地址对 UDP 做哈希、流量集中到一个队列的案例 - ethtool(8) — Linux manual page ethtool
用 ethtool -N rx-flow-hash udp4 把端口（f、n）也加入 UDP 哈希的选项 - mpstat(1) — Linux manual page sysstat
%soft：CPU 用于处理软中断的时间占比，加 -P ALL 按核心显示
相关原因
同一层：L6 服务器网卡
其他层中同样导致“瞬移”的原因
查看含图示和实验的原卡片