背景：近期AI词元（token）推理服务在IDC侧集中上线，单台服务器长连接数从几千飙到几万，小包占比高、突发流量密。问题往往不在带宽总量，而在网络软件栈没跟上。以下5条按“先软后硬、先易后难”排序。
1. 先查中断亲和性与RPS/RFS。AI词元请求多是小包+高并发，默认单核收包容易成瓶颈。用ethtool -S看每队列丢包，开启RPS把软中断分散到多核，RFS配合应用线程。可执行命令：echo ffff > /sys/class/net/eth0/queues/rx-0/rps_cpus，再观察/proc/softirqs是否均衡。
2. 调TCP backlog与TIME_WAIT复用。词元服务器短连接多，net.core.somaxconn和tcp_max_syn_backlog建议提到65535；开启tcp_tw_reuse=1，并缩短tcp_fin_timeout。注意：tcp_tw_recycle在NAT环境务必关闭，近期已有IDC因此出现随机断连。
3. 检查网卡多队列与XPS。若网卡只开了1个RX队列，再强的CPU也白搭。用ethtool -l确认，结合ethtool -L调到CPU核心数。XPS把发送绑到同NUMA节点，能显著降低跨片延迟，对词元流式返回尤其明显。
4. 给网络软件让出CPU。DPDK/OVS或eBPF程序若与推理进程抢核，带宽利用率会假高。用isolcpus隔离出转发核，或给irqbalance加黑名单。本周有案例：仅隔离2个核，词元P99延迟降了18%。
5. 上eBPF做实时带宽画像。别等监控告警。用tcplife、nstat或自写eBPF统计每个词元服务的重传与RTT，按cgroup限流。可执行建议：先跑bpftrace -e 'kprobe:tcp_retransmit_skb { @[comm]=count(); }'，找出重传最高的进程再针对性调。
本周避坑：某IDC盲目升级万兆网卡，却未开多队列，带宽只提升7%。先软后硬，顺序别反。
0 留言