ss -i 比 netstat 更适合排查 TCP 性能瓶颈，因其通过 inet_diag 接口获取实时、详细的连接级指标（如 pacing rate、reordering、RACK、cc 字段），而 netstat 依赖过时的 /proc/net/* 接口，缺乏关键信息；且 ss -i 需 root 权限才可见全量指标。
为什么 ss -i 比 netstat 更适合排查 TCP 性能瓶颈
因为 netstat 读取的是过时的 /proc/net/* 接口，无法暴露现代 TCP 栈的关键指标（如 pacing rate、reordering、RACK 状态），而 ss -i 直接调用内核的 inet_diag 接口，能拿到真实、实时的连接级 TCP 信息。
- 排查重传激增时，
ss -i输出里的retrans和reordering字段比netstat的模糊统计更有指向性 -
ss -ti src :8080可快速筛选特定端口的连接并查看其拥塞控制状态（cc字段） - 注意：
ss -i需要 root 权限才能看到所有连接的详细指标，普通用户只能看到本进程相关连接 - 某些老内核（ss -i 不支持 RACK 或 BBRv2 的字段，此时需搭配
cat /proc/net/tcp手动查 sk_wmem_queued 等字段
调整 net.ipv4.tcp_slow_start_after_idle 前必须确认业务流量模式
这个参数默认为 1，意味着 TCP 连接空闲后会重置拥塞窗口（cwnd）为 1 MSS，对短连接密集型服务（如 HTTP/1.1 API）是合理的；但对长连接、流式数据传输（如 gRPC 流、实时日志推送），它反而引发反复慢启动，浪费带宽。
- 检查是否真有影响：用
ss -i观察活跃连接的cwnd是否频繁从 10 MSS 掉回 1–2 MSS - 临时关闭：
sysctl -w net.ipv4.tcp_slow_start_after_idle=0，观察 RTT 波动和吞吐变化 - 线上慎改：Kubernetes Pod 网络命名空间里修改该值，只影响当前命名空间，但若使用 hostNetwork，则影响整个节点
- 替代方案：对关键服务启用
TCP_CONGESTIONsocket 选项（如设为bbr），BRR 本身对空闲恢复更友好，比全局关掉 slow start 更精准
ethtool -C 调优中断合并时，rx-usecs 和 rx-frames 的取舍逻辑
网卡中断合并（Interrupt Coalescing）本质是在延迟与 CPU 开销之间做权衡。单纯调大 rx-usecs（微秒级延迟阈值）会导致小包堆积，增加 P99 延迟；只压低 rx-frames（包数阈值）又会让高吞吐场景下中断过于频繁。
- 典型 Web 服务（HTTP 小包多）：优先设
rx-frames 64，rx-usecs 50，避免小包延迟毛刺 - 大数据传输（如 Spark shuffle）：设
rx-usecs 100，rx-frames 128，牺牲一点首包延迟换吞吐稳定 - 务必验证：
watch -n1 'grep eth0 /proc/interrupts'看每秒中断次数是否下降 30% 以上，同时ping -c100 -q gateway | tail -1的 max 延迟不能突增 >2ms - 某些 Mellanox CX-5/CX-6 卡需配合
ethtool --set-priv-flags关闭adaptive_rx，否则-C设置会被动态覆盖
为什么 net.core.somaxconn 设太高反而导致新连接失败
当 net.core.somaxconn 远超应用层 listen() 的 backlog 参数时，内核会按 min(应用 backlog, somaxconn) 截断队列长度，但队列溢出日志（netstat -s | grep -i "listen overflows"）仍会归因于 somaxconn 不足，误导排查方向。
- 先查应用实际 listen backlog：
lsof -i :8080 | grep LISTEN后看对应进程的listen()调用栈（需 debuginfo），或直接看应用代码里socket.listen(128)这类硬编码 - 线上建议：把
net.core.somaxconn设为应用 backlog 的 2 倍（如应用设 512，内核设 1024），留缓冲但不冗余 - 云环境特别注意：AWS ENA 驱动在
net.core.somaxconn > 65535时可能触发驱动 bug，表现为随机 accept() EAGAIN，降回 32768 更稳 - 容器场景：Docker/K8s 默认不继承宿主机 sysctl，必须显式用
--sysctl net.core.somaxconn=32768或 PodSecurityPolicy 注入
事情说清了就结束
