提升 CentOS 的 backlog 的正确做法
一 概念与上限
- backlog 通常指服务端 listen 套接字的全连接队列（accept 队列）与 SYN 半连接队列长度。全连接队列的实际上限由内核参数 net.core.somaxconn 与应用程序调用 listen(2) 时传入的 backlog 参数共同决定，最终生效值为二者中的较小者。半连接队列长度由 net.ipv4.tcp_max_syn_backlog 控制，同时受 net.ipv4.tcp_syncookies 开关影响（开启时可在高 SYN 压力下保护内核）。此外，若使用 Unix Domain Socket（SOCK_DGRAM），还受 net.unix.max_dgram_qlen 影响。提升前务必确认瓶颈是在队列而非应用处理能力。
二 系统级参数调整步骤
- 查看与临时调大
- 查看：cat /proc/sys/net/core/somaxconn；cat /proc/sys/net/ipv4/tcp_max_syn_backlog
- 临时生效（立即）：echo 4096 > /proc/sys/net/core/somaxconn；echo 8192 > /proc/sys/net/ipv4/tcp_max_syn_backlog
- 持久化配置（/etc/sysctl.conf 或 /etc/sysctl.d/99-backlog.conf）
- 建议值（按并发量分阶段，先 4096/8192，再 16384/16384，极高并发再 32768/32768）
- net.core.somaxconn = 16384
- net.ipv4.tcp_max_syn_backlog = 16384
- net.ipv4.tcp_syncookies = 1
- 可选：若使用 Unix DGRAM 通信（如某些进程间通信场景）
- net.unix.max_dgram_qlen = 20000
- 使配置生效：sysctl -p
- 重要提醒
- 仅调大内核队列并不能提高应用accept速度；若应用 accept 不及时，队列仍会满。应同时优化应用并发与 worker 数量。
三 应用层与资源配套
- 应用层
- 将服务端 listen(…, backlog) 设置为与 net.core.somaxconn 相匹配或略小的值（例如两者都设为 16384），避免“设大不生效”。
- 提升应用并发处理能力（多 worker/多进程/异步 I/O），确保能及时从全连接队列中 accept() 连接。
- 文件句柄与端口
- 提升进程可打开文件数（/etc/security/limits.conf）：如 * soft/hard nofile 65535，防止“too many open files”限制连接建立与 accept。
- 高并发对外连接场景，扩大本地端口范围：net.ipv4.ip_local_port_range = 1024 65535（减少端口耗尽导致的连接失败）。
四 验证与排障
- 队列与连接状态
- ss -lnt | grep :<端口> 查看 Recv-Q（当前排队连接数）与 Send-Q（listen 队列上限）
- netstat -napt | grep LISTEN 辅助查看监听与状态分布
- 丢包与压力迹象
- cat /proc/net/softnet_stat 观察是否有接收软中断丢包（第三列异常增长），必要时提升 net.core.netdev_budget 给软中断更多处理时间（如 300→600）。
- 使用 netstat -s 查看协议层统计（如 listen 队列溢出、重传等）以定位瓶颈位置。
五 安全与容量边界
- 队列并非越大越好：过大的 somaxconn 会占用更多内核内存，且在 syncookies=1 时，半连接队列的有效长度会被限制，超出的 SYN 将被丢弃或触发 cookie 验证，极端情况下反而影响体验。应结合实际并发、内存容量与业务 RTT综合评估，分阶段压测后再定最终值。