Linux 内核调优复盘：单机百万连接场景下的协议栈瓶颈击穿记录-北京尧图网络

Linux 内核调优复盘单机百万连接场景下的协议栈瓶颈击穿记录一、40 万连接的瓶颈不是硬件不够是内核在“帮忙”丢包消息推送服务在一次架构升级后面临了一个关键挑战需要维持 100 万级别的长连接推送能力。初期在 4C16G 的云主机上压测连接数在到达 38 万左右后新连接建立开始出现间歇性超时ss -s显示大量连接处于 SYN_RECV 状态。这不是硬件瓶颈——CPU 利用率约 60%内存消耗不到 8GB。问题出在 Linux 内核协议栈的默认配置是为通用场景设计的面对长连接数量级挑战时需要逐层调整。全连接队列溢出、文件描述符限制、TCP 内存配置不足、端口范围受限等多个因素共同构成了连接数的天花板。二、文件描述符与连接队列两个最触手可及的天花板文件描述符限制是最先被撞到的墙。Linux 默认为单个进程设置 1024 个软限制soft limit远不足以承载百万连接。调整需要同时修改系统级和进程级# 系统级/etc/sysctl.conf fs.file-max 2000000 # 系统全局最大文件描述符数 fs.nr_open 2000000 # 单个进程可打开的最大文件描述符数 # 进程级/etc/security/limits.conf # soft 和 hard 都需要设置且 hard soft * soft nofile 2000000 * hard nofile 2000000全连接队列backlog的大小决定了在服务端accept()之前能缓冲多少个已握手但未处理的连接。默认值 128 在低并发场景足够但面对海量长连接时会成为显著的瓶颈点# /etc/sysctl.conf # 全连接队列最大长度 —— 影响 accept 之前的连接缓冲能力 net.core.somaxconn 65535 # 半连接队列SYN_RECV 状态最大长度 —— SYN Flood 攻击时可适当降低 net.ipv4.tcp_max_syn_backlog 8192 # 启用 SYN Cookie半连接队列满时不丢弃 SYN而是回复加密 Cookie net.ipv4.tcp_syncookies 1 # 同时连接数中处于 TIME_WAIT 状态的最大数量 # TIME_WAIT 是四次挥手的正常状态过多会占用端口资源 net.ipv4.tcp_max_tw_buckets 2000000应用侧也需要同步调整listen()的 backlog 参数// Go 服务端 listen 配置 —— backlog 参数需与 somaxconn 对齐 import golang.org/x/sys/unix func listenWithBacklog(addr string, backlog int) (net.Listener, error) { lc : net.ListenConfig{ Control: func(network, address string, c syscall.RawConn) error { return c.Control(func(fd uintptr) { // 绕过 Go 默认的 backlog 限制直接设置 socket 选项 unix.SetsockoptInt(int(fd), unix.SOL_SOCKET, unix.SO_REUSEPORT, 1) // 启用端口复用配合多进程负载均衡 }) }, } return lc.Listen(context.Background(), tcp, addr) }三、TCP 协议栈的深层调优连接建立之后TCP 协议栈的配置决定了数据传输的效率# TCP 内存配置 # tcp_mem 的三元组low / pressure / high单位页4KB/页 # low: TCP 栈开始限制内存使用 # pressure: 进入内存压力模式减少发送窗口 # high: 硬上限超过后直接丢包 net.ipv4.tcp_mem 786432 1048576 26777216 # 单个连接接收/发送缓冲区的最小、默认、最大值 net.ipv4.tcp_rmem 4096 87380 16777216 net.ipv4.tcp_wmem 4096 65536 16777216 # 连接性能 # 开启 TCP Fast Open —— 在 SYN 包中携带数据减少一次 RTT net.ipv4.tcp_fastopen 3 # 3 同时启用客户端和服务端 # 启用 TCP 窗口缩放Window Scaling—— 支持大于 64KB 的 TCP 窗口 net.ipv4.tcp_window_scaling 1 # 快速回收 TIME_WAIT 连接需谨慎可能与 NAT 环境冲突 net.ipv4.tcp_tw_reuse 1 # KeepAlive 调优 —— 长连接场景的核心 net.ipv4.tcp_keepalive_time 600 # 空闲 600 秒后开始探测 net.ipv4.tcp_keepalive_intvl 30 # 探测间隔 30 秒 net.ipv4.tcp_keepalive_probes 3 # 3 次探测失败即判定断开四、端口范围与 epoll 事件的收尾工作长连接场景下作为客户端发起连接时会消耗本地端口。默认端口范围 32768~60999 约 28000 个端口建立 100 万连接时频繁被耗尽# 扩大临时端口范围 —— 从 28000 扩大到 54000 net.ipv4.ip_local_port_range 1024 65000epoll 层面每个事件占用的内存很小但在百万连接下总量可观# 增加 epoll 可监控的最大文件描述符数 fs.epoll.max_user_watches 2000000最终压测结果4C16G 云主机指标优化前优化后最大并发连接38 万110 万连接超时率6.2%0.01%新连接建立 P99850ms12msCPU 利用率稳定60%72%内存消耗7.8 GB11.2 GB五、总结Linux 内核参数调优在长连接场景中的优先级排序先改 ulimitnofile限制是所有后续优化的前提建议设为 200 万再调连接队列somaxconn和tcp_max_syn_backlog决定连接建立的成功率默认值在百万级长连接下严重不足TCP 内存和 KeepAlive 是稳定性的保障tcp_mem不给够会导致内部丢包KeepAlive 配置则直接影响连接清理效率端口范围和 epoll 是最后的边际优化它们在百万级连接下才能体现出价值但不调会卡在 99% 的最后一公里。禁用场景tcp_tw_reuse在 NAT 环境下可能导致连接混乱建议仅在内网可控环境启用。SYN Cookie 虽然增强了抗攻击能力但在极端高并发下会增加 CPU 开销每次 SYN 需要额外计算对于已验证的内网流量可关闭。

Linux 内核调优复盘：单机百万连接场景下的协议栈瓶颈击穿记录

相关推荐

7B 模型量化降本全复盘：FP32 到 INT4 的精度-成本博弈

企业AI知识库的多行业技术实现：数据架构、检索策略与安全设计的差异化实践

企业AI知识库：八大行业落地架构与数据安全深度解析

更多资讯

Arduino IDE跨平台安装与故障排查全指南

微表情识别模型fer-1.h5端到端部署与实时优化

Greenfield 0.5.4：Minecraft城市操作系统深度解析

论文降重与改写避坑指南：如何识别不可靠的文本处理服务

蜘蛛表格：多维表字段关联技术解析与应用实践

Spring Boot 2.x 日志配置与集成 Logback 日志框架，SQL日志记录方式汇总

今日更新

基于高阶循环谱的MPSK载波频率估计与MATLAB实现

MiniPdf方：.NET开源Office转PDF的高效解决方案

Solon AI v3.10：Java全栈智能体开发框架解析

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？