最有效手段是用ethtool -C调rx-usecs和rx-frames，但须据负载与延迟容忍度设值；生效值看ethtool -c输出中current hardware settings，rx-usecs:0且rx-frames:0表示聚合关闭，Adaptive RX开启时需先关闭再手动设置。
直接结论：用 ethtool -C 调整 rx-usecs 和 rx-frames 是最有效、最可控的手段，但必须结合网卡实际负载和延迟容忍度来设值，硬套“50μs”或“32包”反而容易丢包。
怎么看当前中断聚合参数是否生效
别猜，先确认硬件到底支持什么、现在跑的是什么：
-
ethtool -c eth0输出里current hardware settings下的rx-usecs和rx-frames才是真实生效值；pre-set max coalescing parameters只是驱动允许的最大范围，不等于当前配置 - 如果
rx-usecs: 0且rx-frames: 0，说明聚合完全关闭——每个包都触发中断，CPU软中断（si）必然飙升 -
Adaptive RX: on表示网卡在自动调节，此时手动设的rx-usecs可能被覆盖，需先关掉自适应再调
怎么设 rx-usecs 和 rx-frames 才不翻车
这两个参数不是独立起作用的，是“先满足任一条件就触发中断”：
-
rx-usecs 100+rx-frames 16：只要等满 100μs，或收到 16 个包，就发一次中断 - 高吞吐场景（如文件传输、CDN回源）优先抬高
rx-usecs（比如 300–500），压低中断频次；但超过 1000μs 后，延迟可能突破 500μs，对时延敏感业务（Redis、gRPC）不可接受 - 小包密集场景（如高频 API、Kafka 消息）更适合压低
rx-usecs（如 30–50），靠rx-frames控制聚合量，避免单次中断处理过多包导致 softirq 延迟堆积 - 部分网卡（如 igb）对
rx-usecs的合法值有硬限制：只接受 0、1、3 或 10–8191，填 7 或 99 会静默失败，需用ethtool -c再查一遍确认
为什么改了参数但 top 里 si 还是高
中断聚合只是软中断优化的一环，CPU 持续吃紧往往还有其他瓶颈：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 网卡中断没绑到专用 CPU 核：
cat /proc/interrupts | grep eth0看中断是否集中在某一个 CPU 上，如果是，用echo 1 > /proc/irq/把它分散到空闲核/smp_affinity - NAPI weight 太小：
cat /proc/sys/net/core/dev_weight默认是 64，高吞吐下建议提到 256 或 512，否则单次 softirq 处理不完积压包，反复触发 - RSS 队列数不足：
ethtool -l eth0查看当前 RX 队列数，若只有 1，再多核也白搭；配合ethtool -L eth0 rx 8开多队列，并确保中断已按队列绑定到不同 CPU - 驱动不支持聚合：老型号网卡（如 e1000）或某些虚拟化网卡（virtio-net）可能忽略
rx-usecs设置，ethtool -i eth0看driver版本，ixgbe、i40e、mlx5 支持最完整
怎么让设置重启后不丢失
ethtool -C 是运行时修改，系统重启即失效。别往 /etc/rc.local 塞命令，那个在 systemd 下已不可靠：
- 写成 systemd service：新建
/etc/systemd/system/ethtool-coalesce@.service，ExecStart=/sbin/ethtool -C %i rx-usecs 300 rx-frames 32，然后systemctl enable ethtool-coalesce@eth0 - 或者用 udev rule：在
/etc/udev/rules.d/99-ethtool-coalesce.rules里加ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth0", RUN+="/sbin/ethtool -C %k rx-usecs 300 rx-frames 32" - 注意：必须等网卡初始化完成后再执行，udev rule 更稳妥；service 方式要加
After=network-pre.target防止抢在网卡加载前运行
真正难的不是设哪个数字，而是理解你收的是大包还是小包、延迟能不能忍、CPU 是被中断打爆还是被协议栈拖垮——rx-usecs 调得再准，如果 RSS 队列没开、中断没绑核、NAPI weight 还卡在 64，CPU 该飙还是飙。
