直接调内核参数不能自动提升并发能力，关键在于匹配业务类型、补全资源限制、打通内核到应用的链路；默认配置保守通用，高并发下常卡在连接排队、端口耗尽、内存回收慢、文件句柄不足等环节，需按Web/API网关、数据库、Java中间件等业务特征差异化调优，并同步调大somaxconn、tcp_max_syn_backlog、netdev_max_backlog三队列及file-max和用户级nofile限制，启用tcp_tw_reuse加速TIME_WAIT复用，配合vm.swappiness、dirty_ratio等内存IO参数协同优化。
直接调内核参数不能自动提升并发能力，关键在于匹配业务类型、补全资源限制、打通内核到应用的链路。默认配置是通用保守值，高并发场景下常卡在连接排队、端口耗尽、内存回收慢、文件句柄不够这些环节。
先确认业务类型再下手
不同服务瓶颈不同，乱调反而拖垮系统：
- Web/API网关类：重点在TCP连接队列、TIME_WAIT复用、本地端口范围
- 数据库（MySQL/PostgreSQL）：侧重内存脏页比例、swappiness、文件描述符和inotify限制
- Kafka/ES等Java中间件：需增大pid_max、threads-max，同时配好JVM堆外内存与GC策略
- 文件分发或静态资源服务：必须启用sendfile零拷贝路径，并确保源文件在ext4/xfs上、目标socket已建立
网络连接承载力要三队列齐调
连接不是“建了就算成功”，得能排队、不丢包、不被截断：
- net.core.somaxconn = 65535：全连接队列上限，必须 ≥ 应用listen()设置的backlog（如Nginx里写的backlog=65535）
- net.ipv4.tcp_max_syn_backlog = 65535：SYN半连接队列，防短连接洪峰打爆
- net.core.netdev_max_backlog = 65535：网卡软中断收包队列，万兆网卡+高入向流量时必调，否则包直接丢
- 配套改fs.file-max = 2097152，并在/etc/security/limits.conf里放开用户级限制：
* soft nofile 1048576
* hard nofile 1048576
让TIME_WAIT不堵路
短连接密集型服务（比如HTTP API）最怕端口耗尽：
- net.ipv4.tcp_tw_reuse = 1：仅对客户端connect()出站有效，允许快速复用TIME_WAIT端口
- net.ipv4.tcp_fin_timeout = 15：缩短FIN-WAIT-2超时，加快连接释放
- net.ipv4.tcp_max_tw_buckets = 200000：放宽TIME_WAIT总数硬限，避免内核强制回收引发RST
内存与IO配合调度才稳
并发上来后，内存压力和IO延迟会放大问题：
- vm.swappiness = 10：降低换出倾向，防止数据库进程被OOM killer误杀
- vm.dirty_ratio = 20 与 vm.dirty_background_ratio = 10：控制脏页回写节奏，避免突发IO打满带宽
- fs.inotify.max_user_watches = 524288：防止监听文件变更时报“Too many open files”
- 对SSD或虚拟机环境，把I/O调度器切为noop：
echo noop > /sys/block/sdX/queue/scheduler
