Go 高并发百万连接压测报告与调优终局：epoll 唤醒、文件描述符与内存模型黄金法则

在网络编程与高并发服务领域，“单机支撑百万并发连接（1 Million Connections / C1000K）”常常被作为衡量语言运行时与架构设计水平的试金石。

很多开发者在本地跑几个 Goroutine 处理几百个并发时一切顺利，但当真正面对生产环境下数十万台 IoT 设备长连接、海量客户端 WebSocket 握手时，往往会遭遇一系列底层系统墙：

• too many open files错误直接导致服务拒绝所有新连接；
• 单个连接即便不发数据，几万个 Goroutine 也会吃光几十 GB 内存，引发系统 OOM 崩溃；
• Linux 内核 TCP 半连接队列溢出，握手丢包严重，客户端出现海量连接超时。

在 9 月份的底层网络压测攻坚中，我们团队在单台 8C16G 的普通云服务器上，成功完成了100 万并发长连接的稳定性压测与调优。

今天是 9 月 30 日收官之日，我把这次百万连接实测报告、Linux 内核调优参数、Gonetpoll底层机制与内存优化黄金法则彻底公开。

一、百万连接压测拓扑与物理资源瓶颈

要在一台 8C16G 的服务器上维持 100 万个 TCP 长连接，我们首先要算清物理资源的“硬账”：

graph TD ClientCluster[压测发包机集群 (5台 4C8G 模拟客户端)] -->|百万 TCP 握手| TargetServer[压测目标机 (8C16G Linux)] subgraph 目标机三大物理资源硬约束 TargetServer --> R1[1. 文件描述符 (FD) 限制: 必须 > 1,000,000] TargetServer --> R2[2. Linux 内核 TCP 缓冲区: 单连接读写缓冲区极限瘦身] TargetServer --> R3[3. Go 运行时内存: 避免为每个连接分配读写协程] end

1. 文件描述符（File Descriptor）账本

Linux 下一切皆文件，每个 TCP 连接占用 1 个 FD。
系统默认的nofile上限通常只有 1024 或 65535。如果不调整内核参数，系统在连接数达到 6 万时就会彻底瘫痪。

2. Linux 内核 TCP 内存账本

Linux 默认的 TCP 接收/发送缓冲区（tcp_rmem/tcp_wmem）初始通常在 4KB ~ 128KB 动态调整。
如果 100 万个连接每个占用 16KB 缓冲区：
$$1,000,000 \times 16\text{ KB} = 16\text{ GB 内核内存}$$
服务器物理内存将直接被内核态吃光，根本没有内存留给用户态进程！

3. Go 协程栈内存账本

传统的 Go 网络模型是One Goroutine Per Connection（每个连接 1 个读协程 + 1 个写协程）。
Go 协程初始栈大小为2KB，如果 100 万个连接启动 200 万个协程：
$$2,000,000 \times 2\text{ KB} \approx 4\text{ GB 堆栈内存}$$
一旦协程调用较深触发栈扩容（4KB/8KB），内存将瞬间失控。

二、Linux 内核级调优参数实战配置

在压测机与服务端，必须提前在/etc/sysctl.conf中注入以下参数并执行sysctl -p生效：

# 1. 突破系统最大文件句柄与进程限制 fs.file-max = 2097152 fs.nr_open = 2097152 # 2. 优化 TCP 全连接与半连接队列 net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 # 3. 极限压榨 TCP 读写缓冲区（针对海量空闲长连接场景） # 最小值、默认值、最大值全部压缩 net.ipv4.tcp_rmem = 1024 2048 4096 net.ipv4.tcp_wmem = 1024 2048 4096 # 4. 开启 TIME_WAIT 快速回收与复用 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 15 # 5. 客户端本地可用端口范围扩展 (压测发包机必备) net.ipv4.ip_local_port_range = 1024 65535

同时在/etc/security/limits.conf中修改软硬限制：

* soft nofile 1048576 * hard nofile 1048576

三、Go 架构演进：从原生 Netpoll 到 Reactor 异步事件驱动

为了突破 200 万协程的内存死锁，我们在百万连接场景下放弃了原生的“一连接一协程”模型，引入了基于 Linuxepoll的Reactor 多路复用非阻塞网络库（如 gnet / netpoll）：

graph TD Epoll[Linux epoll_wait 核心事件监听] --> MainReactor[主 Reactor 负责 Accept 握手] MainReactor --> SubReactors[多个子 Reactor 轮询 (绑定特定 CPU 核心)] SubReactors -->|仅当有数据到达时| WorkerPool[共享协程工作池 (几百个协程处理真实计算)] WorkerPool --> ProcessBusiness[执行业务编排]

核心收益：

• 百万连接仅需几百个 Goroutine：100 万个空闲连接在没有数据收发时，只在 epoll 中注册事件，不创建任何独立的 Go 协程；
• 内存开销从原生的 8GB 骤降至1.8GB，单机即可稳稳承载。

四、网卡多队列（RSS）与软中断 CPU 亲和性绑定

在压测连接数达到 50 万时，我们发现单台机器的CPU 0使用率飙升到 100%（大部分消耗在si软中断上），而其他 7 个 CPU 核心几乎处于闲置状态。
这是由于默认情况下网卡中断全部被路由到了第一个 CPU 核心上。

优化方案：

1. 开启网卡硬件多队列（Receive Side Scaling, RSS）；
2. 启动irqbalance服务，或手动将网卡中断号绑定到不同的 CPU 核心掩码上（/proc/irq/<irq_num>/smp_affinity）；
3. 调整后软中断均匀分散在所有 8 个核心上，网卡处理能力瞬间翻倍。

五、百万连接压测实测数据全景

我们在单台 8C16G 虚拟机上维持 100 万并发长连接，并以 5,000 QPS 的频率持续广播心跳包，进行了 2 小时的连续压测：

总结：高并发网络编程的 3 条底层法则

1. 先调内核，再写代码：操作系统内核是承载高并发的地基，FD 上限和 TCP 缓冲区大小是无法逾越的物理红线。
2. 海量长连接坚决抛弃“一连接一协程”：在海量空闲连接（如 IoT、消息推送）场景下，Reactor 异步事件驱动是降本增效的终极答案。
3. 敬畏内存分配：在网络包编解码中，全面推行sync.Pool字节切片复用，彻底消灭 GC 压力，系统才能在百万并发下波澜不惊。