直接看网卡包量分布可快速定位nginx中断处理瓶颈，重点查rss是否生效、各rx队列中断是否均衡，结合rps/rfs优化软中断分发，并调优tcp缓冲区与nginx连接处理策略，最终通过mpstat和ss验证多核负载均衡与连接状态改善。
直接看网卡包量分布，能快速定位Nginx中断处理的瓶颈点。不是所有高并发都压在CPU上，很多性能问题其实卡在网卡收包不均、软中断集中、或RSS（Receive Side Scaling）未对齐导致的单核过载。
查清当前网卡包量是否均衡
先确认真实分布，避免凭经验误判：
- 用 cat /proc/net/dev 看各网卡总收发包量，确认流量是否集中在某张卡上
- 用 cat /proc/irq/*/cpulist | grep eth0 查每个RX队列绑定的CPU核，再结合 watch -n1 'cat /proc/interrupts | grep eth0' 观察各IRQ中断计数增长是否悬殊
- 重点看 eth0-TxRx-0 到 eth0-TxRx-N 这类条目——如果其中1~2个核的中断次数是其他核的5倍以上，说明RSS未生效或队列数不足
调整RSS与RPS/RFS让包分散到多核
RSS是网卡硬件层面的分流，RPS/RFS是内核软件层兜底。两者配合才能真正释放多核能力：
- 启用RSS：确认网卡支持且已开启，例如 ethtool -K eth0 rx on 和 ethtool -L eth0 combined 8（设为8队列，匹配CPU核心数）
- 开启RPS（接收端软件分流）：写入 echo fff > /sys/class/net/eth0/queues/rx-0/rps_cpus（十六进制掩码对应CPU位图），使单队列中断后由多个CPU轮询处理软中断
- 开启RFS（接收流导向）：设置 net.core.rps_sock_flow_entries=32768，并按队列配置 /sys/class/net/eth0/queues/rx-0/rps_flow_cnt，让同一TCP流尽量被同一CPU处理，提升cache命中率
Nginx侧配合减少软中断压力
即使网卡分包均匀，Nginx若频繁触发小包处理或上下文切换，仍会拖慢整体响应。关键做三件事：
- 调大 net.ipv4.tcp_rmem 和 net.ipv4.tcp_wmem，避免因缓冲区小导致频繁中断收包；推荐设为 "4096 65536 8388608"
- Nginx配置中启用 tcp_nodelay off（默认on），对长连接减少小包发送频次；搭配 tcp_nopush on，让Nginx在发送前尽量攒够一个满MSS的数据块
- 限制单个worker进程处理的活跃连接数，避免软中断+epoll事件混杂导致延迟抖动：通过 worker_connections 16384 + multi_accept on 控制批量收包节奏
验证优化效果是否落地
改完不能只看QPS，要盯住底层信号：
- 用 mpstat -P ALL 1 观察各CPU的 %soft 是否从单核90%+降到多核均衡在30%以下
- 用 ss -s 检查 total: sockets 和 timewait 数量变化，若timewait激增，说明连接释放变慢，需回头调 net.ipv4.tcp_fin_timeout 或 net.ipv4.tcp_tw_reuse
- 压测时抓包比对：tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0' -c 100，看SYN/FIN是否仍扎堆在少数连接上
