关键在于用ethtool -c查看参数后，结合业务负载动态调优rx-usecs/rx-frames，并通过/proc/interrupts验证中断下降幅度是否达40%以上，同时需协同扩展队列数、绑定cpu及启用rss。
直接用 ethtool -c eth0 查看中断聚合参数只是第一步，真正实现高吞吐下 CPU 中断平滑，关键在于理解参数含义、结合业务负载动态调整，并用 /proc/interrupts 验证效果。
看清当前聚合状态与核心参数含义
执行 ethtool -c eth0 后，重点关注以下几项：
- Adaptive RX/TX：是否启用自适应模式。on 表示网卡驱动会根据实时流量自动调节 rx-usecs 和 rx-frames，适合流量波动大的场景；off 则需手动固定值。
- rx-usecs：接收中断延迟微秒数。设为 0 表示禁用定时聚合；设为 30–100 是常见起点，值越大，延迟越高但中断越少。
- rx-frames：每触发一次中断前需累积的最小接收帧数。设为 1 表示“来一包就中断”，极易引发中断风暴；建议设为 16–64（尤其在千兆以上链路）。
- tx-usecs / tx-frames：发送方向同理，但通常影响小于接收侧，可先聚焦 RX。
按高吞吐场景分策略调优
不追求“最大吞吐”，而要避免软中断（si）持续占满 CPU 核心：
- 若业务对延迟不敏感（如后台文件同步），可加大 rx-usecs 至 150–300，rx-frames 设为 64，显著降低每秒中断次数。
- 若需兼顾吞吐与响应（如 Web 服务、数据库复制），推荐关闭 Adaptive RX，设 rx-usecs=50、rx-frames=32，平衡延迟与中断开销。
- 若观察到单核 softirq 持续 >80%，且 /proc/interrupts 显示某 IRQ 计数暴涨，说明该网卡队列未分散——此时应先用 ethtool -L eth0 combined N 增加队列数，再为每个队列单独调优 coalesce 参数。
必须验证：用 /proc/interrupts 看真实效果
仅看 ethtool 输出不能说明问题，必须实测中断下降幅度：
- 记录初始值：cat /proc/interrupts | grep eth0（注意找含 “IR-PCI-MSI” 或具体 IRQ 编号的行）
- 用 iperf3 或大包 ping 持续压测 20 秒
- 再次执行相同命令，对比同一 IRQ 行数值增长量
- 优化有效标志：相同流量下，中断增长减少 40% 以上；若变化微弱，说明参数未生效或网卡不支持该模式（如某些虚拟化 virtio 网卡不支持 rx-usecs）。
进阶：配合队列绑核与 RSS 避免单点瓶颈
中断聚合只是单点优化，高吞吐下还需协同处理：
- 先用 ethtool -l eth0 确认当前 RX 队列数，不足则用 ethtool -L eth0 combined 4 扩展（推荐设为物理 CPU 核数的 50%～80%）
- 用 cat /proc/interrupts | grep eth0 找出各 RX 队列对应 IRQ 号，再通过 echo 0-1 > /proc/irq/X/smp_affinity_list 将不同队列绑定到不同 CPU 核
- 启用 RSS 哈希（如 ethtool --config-ntuple eth0 rx-flow-hash tcp4 sdfn），确保同一 TCP 流始终落在同一队列，避免乱序重排开销
