网卡中断绑定需先通过grep 网卡名 /proc/interrupts获取IRQ编号，再用cat /proc/irq/X/smp_affinity_list和effective_affinity确认实际绑定状态，同时必须停用irqbalance、启用多队列并校验CPU未被isolcpus隔离。
直接看 /proc/irq/*/smp_affinity_list，别信 top 或 mpstat 的单核高负载表象——它们只告诉你“谁累”，不告诉你“谁被绑在谁身上”。
怎么快速定位网卡对应的 IRQ 编号
网卡中断号不是猜出来的，得从 /proc/interrupts 里捞：
- 先用
nmcli device status或ip -br link show确认真实网卡名（比如enp1s0f0或ens33） - 再执行
grep -i "enp1s0f0" /proc/interrupts（把名字替换成你的），输出类似：42: 1234567 0 0 0 890123 0 0 0 IR-PCI-MSI 32768-edge enp1s0f0-rx-0
第一列42就是 IRQ 编号；末尾带-rx-或-tx-的，说明已启用多队列，每个后缀对应一个独立 IRQ - 如果
grep没结果，试试驱动名：ethtool -i enp1s0f0 | grep driver得到i40e或mlx5_core，再grep i40e /proc/interrupts
怎么确认当前 IRQ 绑定到了哪些 CPU
拿到 IRQ 编号（比如 42）后，必须立刻查两个文件，缺一不可：
-
cat /proc/irq/42/smp_affinity_list：显示你“写进去”的亲和性，输出是十进制 CPU 编号列表，例如0,2,4,6表示允许跑在这 4 个核上；如果只输出0，就是硬绑死在 CPU 0，单核瓶颈的直接证据 -
cat /proc/irq/42/effective_affinity：显示内核“实际执行”的绑定；若它和smp_affinity_list不一致，大概率是irqbalance在后台偷偷覆盖了你的设置 - 顺手检查
systemctl is-active irqbalance，如果是active，必须先sudo systemctl stop irqbalance再操作
为什么改了 smp_affinity_list 却没生效
常见失效原因不是权限或路径错，而是以下三点被忽略：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 目标 CPU 被内核隔离了：运行
cat /proc/cmdline，若含isolcpus=1,2，就别往 CPU 1 或 2 上写；否则写入会静默失败或触发警告 - 误用了
smp_affinity（十六进制掩码）：x86 是 64 位，ARM 可能更宽，掩码长度错一位就全绑到 CPU 0；smp_affinity_list是人眼可读的十进制列表，安全得多 - 驱动不响应
smp_affinity_list：某些驱动（如mlx5_core）只认smp_affinity，但写之前必须确认位宽；更稳妥的做法是先试smp_affinity_list，失败再查驱动文档
网卡没开多队列时，看中断绑定意义不大
如果 ethtool -l enp1s0f0 显示 Combined: 1，说明硬件只开了 1 个接收队列——你再怎么调 smp_affinity_list，也只有一个 IRQ 号可绑，所有包还是压在同一个中断上下文里。
此时真正该做的不是调绑定，而是：
- 先启用多队列：
sudo ethtool -l enp1s0f0 combined 4（设为 CPU 核数一半或匹配 NUMA 节点） - 再确认网卡支持 RPS：
ls /sys/class/net/enp1s0f0/queues/rx-*，有多个rx-*目录才说明队列已激活 - 最后才是对每个
rx-0、rx-1对应的 IRQ 分别绑定不同 CPU
中断绑定不是万能开关，它是多队列 + NUMA 对齐 + irqbalance 停用三者协同的结果；漏掉任意一环，看到的都只是假象。
