Ubuntu 中 backlog 对硬件资源占用的影响
一 概念与工作原理
- backlog 是监听套接字在调用 listen() 时指定的队列上限，用于控制已完成三次握手、等待进程 accept() 的连接数量（即全连接队列）。在 Linux 2.2+ 中采用“双队列”模型：半连接队列（SYN 队列）与全连接队列（accept 队列）；应用传入的 backlog 受系统上限 net.core.somaxconn 约束，最终取值为 min(应用 backlog, somaxconn)。队列满时，新连接可能被丢弃或复位，具体行为由 net.ipv4.tcp_abort_on_overflow 决定。队列使用情况可用 ss -tnlp 观察（Recv-Q 为当前排队数，Send-Q 为队列上限）。
二 对 CPU 与内存的实际占用
- 内存占用
- backlog 队列中的每一项本质上是一个处于 ESTABLISHED 状态但尚未被应用接受的连接控制块（TCB）及相关内核数据结构。队列越大，占用的 内核内存 越多；若队列长期积压，整体内存压力随之上升。需要注意的是，队列内存只是系统总内存的一部分，但它与积压规模呈正相关。
- CPU 占用
- backlog 本身不会直接“吃掉”大量 CPU；真正的 CPU 压力通常来自应用 accept()/处理 速度不足或连接风暴导致的频繁软中断与协议栈处理。当队列长期接近上限时，常见现象是 CPU 软中断升高、上下文切换增加、应用线程争用加剧，进而表现为 延迟上升 与吞吐下降。
三 过载时的行为
- 当全连接队列满时：
- 若 tcp_abort_on_overflow=0（默认），服务器会丢弃客户端的 ACK，客户端可能长时间重试，连接建立时延显著增大。
- 若 tcp_abort_on_overflow=1，服务器向客户端发送 RST，客户端出现 “connection reset by peer”。
- 可通过 netstat -s | grep -i listen 观察全连接队列溢出计数是否持续递增，以判断是否存在积压问题。
四 如何设置与监控以控制资源占用
- 设置原则
- 目标是在突发流量下既不频繁溢出，也不因队列过大而浪费内存。经验上可将 backlog 设为服务可承受的 每秒请求数（QPS）的约 1–1.5 倍，并结合压测校准；同时受 somaxconn 与应用配置共同约束。
- 关键参数与查看
- 系统级上限：net.core.somaxconn（常见默认 128/4096，视内核与发行版而定）
- 半连接上限：net.ipv4.tcp_max_syn_backlog
- 溢出行为：net.ipv4.tcp_abort_on_overflow
- 查看队列：ss -lnt | grep :端口（Recv-Q 当前排队，Send-Q 队列上限）
- 溢出诊断：netstat -s | grep -i “listen queue” 或 grep “overflowed”
- 快速示例（临时生效）
- sudo sysctl -w net.core.somaxconn=4096
- sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192
- sudo sysctl -w net.ipv4.tcp_abort_on_overflow=1
- 永久生效：写入 /etc/sysctl.conf 后执行 sudo sysctl -p
- 风险提示
- 将 backlog 设得过大，会在高并发且处理不及时的情况下导致 内存占用升高 与 延迟增加；过小则易出现 连接超时/拒绝。应结合业务峰值与处理能力做压测调优。
