连接数问题是「量」的问题
并发连接相关的故障有个共同特征：单次手工操作完全正常，一旦并发或频率上来就开始失败，且失败比例随时段波动。原因是链路上有多处独立的数量上限——服务端允许的并发会话数、登录叠加的限制、进程可打开的文件描述符、可用的临时端口，以及服务自身的连接池与后端连接上限。任何一处被打满，表现都可能是超时或直接拒绝，因此要按「限制点」逐个对照而不是笼统加压。
基本信息
| 适用对象 | SSH 批量执行、数据库客户端、HTTP 客户端与服务端 |
|---|---|
| 常见限制点 | 服务端会话数、登录叠加限制、文件描述符、临时端口、后端连接池 |
| 典型表现 | 低并发正常、高并发超时或拒绝，失败比例随时段波动 |
| 观测手段 | 套接字统计、连接状态计数、服务端日志与连接池指标 |
| 权限要求 | 查看与调整系统级限制需 root |
数量上限的常见位置
- 服务端会话上限：同一连接内允许的通道数与同源并发登录数各有上限
- 登录叠加限制：登录类限制可对同一用户或整个系统的并发登录数设上限
- 文件描述符上限：进程能打开的文件与套接字总数，用尽后报「打开文件过多」
- 临时端口范围：客户端向外发起连接时可用源端口有限，耗尽后只能等待回收
- 连接状态堆积：网络抖动或服务不响应时，连接滞留在等待状态，占着资源不释放
- 服务侧连接池：应用与后端之间另有连接上限，池满时请求排队而非立即失败
观测与调整
观测与调整
ss -s # 各类连接状态的总量概览
ss -tan state time-wait | wc -l # 处于等待回收状态的连接数
ss -tan state established | wc -l # 当前已建立的连接数
ulimit -n # 当前会话的文件描述符上限
ss -lntp | grep ':22' # 确认 SSH 服务实际在监听与处理
sysctl net.ipv4.ip_local_port_range # 查看可用临时端口范围
systemctl show sshd -p LimitNOFILE # 服务单元里的实际限制限制点与表现
| 限制点 | 打满后的表现 | 观测方式 |
|---|---|---|
| 服务端会话数上限 | 新通道建立失败，已有会话仍可用 | 服务端日志与套接字统计 |
| 同源并发登录上限 | 新登录被拒，旧登录不受影响 | 授权日志与登录限制配置 |
| 文件描述符上限 | 报打开文件过多，服务可能整体异常 | 进程限制与实际句柄数 |
| 临时端口耗尽 | 出向连接失败，等待回收后可恢复 | 连接状态计数与端口范围 |
| 连接池上限 | 请求排队，延迟升高而非直接报错 | 应用指标与后端连接数 |
连接复用能显著减少握手与认证开销，但也带来新的故障形态：复用通道出问题时所有借用它的任务一起失败，且单个任务超时可能污染后续任务。批量执行时应当设置合理的复用空闲超时，并对失败任务做独立重试。
调整系统级上限时要同时看两处：会话级限制与进程运行时的实际限制。服务由服务管理器启动时，两者可能不一致，只看其中一处容易得出「已经调大了却还是报错」的结论。