linux高并发瓶颈源于内核参数未对齐真实负载：ulimit -n需在systemd服务中显式配置；tcp_tw_reuse依赖tcp_timestamps且仅适用于客户端；somaxconn须与应用backlog及tcp_max_syn_backlog匹配；tcp_rmem/wmem应按场景调优，避免过大导致资源争抢。
Linux 默认参数在万级并发下会迅速成为瓶颈，不是应用写得不够好，而是内核网络栈、文件描述符、内存缓冲区这些底层资源没对齐真实负载。
为什么 ulimit -n 65535 还是报 “too many open files”
常见错误现象：应用启动后不久就抛出 EMFILE 错误，lsof -p $PID | wc -l 显示打开数远低于 ulimit -n 值。
- 进程可能被 systemd 重置了限制：检查
/etc/systemd/system.conf中的DefaultLimitNOFILE，或服务单元文件里是否显式写了LimitNOFILE=1024 - 应用自身调用
setrlimit(RLIMIT_NOFILE, ...)覆盖了系统设置（如某些 Go runtime 或 Node.js 启动逻辑） -
ulimit -n只影响当前 shell 及子进程，systemd 服务默认不继承，必须在 service 文件中加LimitNOFILE=65535并systemctl daemon-reload - 用户级
/etc/security/limits.conf生效需重新登录，且仅对 PAM 登录会话有效，对systemctl start启动的服务无效
net.ipv4.tcp_tw_reuse 不生效的三个硬性条件
启用 tcp_tw_reuse = 1 后仍看到大量 TIME_WAIT 占满端口，大概率卡在以下任一环节：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
tcp_timestamps = 0：这是tcp_tw_reuse的强制前提，缺一不可；可通过sysctl net.ipv4.tcp_timestamps验证 - 服务端角色误用：该参数只对“主动发起连接”的客户端有效（比如反向代理、微服务调用方），服务端监听连接时不会复用 TIME_WAIT 端口
- NAT 环境下启用了
tcp_tw_recycle = 1：该参数在 4.12+ 内核已被移除，且在任何含 NAT 的路径（包括云厂商 SLB、家庭路由器）中都会导致连接失败，必须设为0
net.core.somaxconn 和应用 backlog 不匹配的后果
现象是 netstat -s | grep "listen overflows" 持续增长，新连接建立超时或被丢弃，但 ss -ltn 显示 Recv-Q 未满。
- 应用调用
listen(sockfd, 128)，而net.core.somaxconn = 128：内核会截断为 128，但实际全连接队列上限是min(backlog, somaxconn) - 正确做法是两者都设高：应用层
listen(..., 4096)+sysctl -w net.core.somaxconn=65535，避免队列溢出丢包 - 若使用 Nginx，需同步配置
listen 80 backlog=65535；若用 Gonet.Listen，Go 1.11+ 默认取somaxconn，但仍建议显式传入较大值 -
net.ipv4.tcp_max_syn_backlog必须 ≥somaxconn，否则半连接队列先满，SYN 包直接被丢弃
tcp_rmem / tcp_wmem 设置过大反而降低吞吐
把 tcp_rmem 最大值设成 64MB 后，小包延迟飙升、CPU sys% 上涨，这不是“越大越好”的问题，而是缓冲区策略错配。
- 三元组格式
"4096 65536 8388608"中的 middle 值是内核动态调整的基准，设太高会导致单连接长期霸占大量内存，挤占其他连接 buffer - 高并发短连接场景（如 API 网关），应压低 middle 值（如
32768），避免缓冲区滞留小包；长连接大流场景（如文件传输）才适合提高 -
net.ipv4.tcp_mem必须按物理内存比例设：32GB 内存建议"9437184 12582912 18874368"（单位是 page），设错会触发全局 TCP 内存回收，导致批量丢包 - 不要忽略
net.core.rmem_max和net.core.wmem_max，它们是 socket-levelsetsockopt(SO_RCVBUF)的硬上限，必须 ≥tcp_rmem最大值
真正卡住高并发的，往往不是某个参数调得不够高，而是多个参数之间存在隐含依赖——比如开了 tcp_tw_reuse 却忘了开 tcp_timestamps，或者调大了 somaxconn 却没同步改 tcp_max_syn_backlog。每次修改后，务必用 ss -s、netstat -s 和业务连接成功率交叉验证，而不是只看单个数字变大了就认为生效了。
