连接耗尽告警表面上像是网络层或端口数量的问题，其内核几乎都指向同一类容量短板并发连接数触到了系统或组件的上限，本质是服务处理并发连接的能力达到了既定边界，而非带宽或磁盘不够用。它暗示着某个层面的“连接槽位”被占满，新连接无法建立,后续业务请求被直接拒绝或排队超时。
这类告警一旦出现，你首先要意识到：瓶颈不在某个进程本身有多慢，而在支撑并发连接的资源被耗尽，常见的表现形式有四种：Nginx或负载均衡器的代理连接池占满、Tomcat或Spring Boot的内嵌容器线程池打满、数据库连接池达到maxActive上限、操作系统的文件描述符或TCP连接表耗尽，下面从排查、修复到容量规划逐层拆解。
连接耗尽告警背后的容量类型与判断路径
是连接数上限不够，不是负载太高
多数运维同学第一次看到连接耗尽告警时，会习惯性地去看CPU或内存占用，发现并不高，进而怀疑告警误报，连接是否耗尽与CPU是否吃饱没有必然关系，当服务端每个连接的处理耗时较长（比如慢SQL或外部接口响应迟缓），并发连接数就会大幅攀升，而CPU可能仍然空闲。
可以从三个维度快速定位：
- 连接数监控曲线：在告警发生前，到监控面板看当前活跃连接数和系统配置的最大连接数,判断是否逼近或者已经持平。
- 错误日志特征：Nginx报“upstream timed out”、Java应用报“Connection pool exhausted”、MySQL报“Too many connections”,这些都是不同组件连接耗尽时的典型痕迹。
- 快速自证动作：临时调大连接池上限，观察告警是否立即消失，如果恢复，就说明确实是容量边界问题；如果还在报,那就要检查是否有连接泄漏或异常堆积。
拆分四层容量模型
为了不遗漏任何一个可能的短板,建议把连接容量拆成四层分别核对：
| 层级 | 典型组件 | 关键容量参数 | 耗尽时的典型表现 |
|---|---|---|---|
| 接入层 | Nginx / LVS / SLB | worker_connections、并发连接总数 | 502 / 504，连接被重置 |
| 应用层 | Tomcat / 微服务容器 | maxThreads、maxConnections | 请求排队，响应时间暴增 |
| 数据层 | MySQL / Redis | max_connections、maxclients | Too many connections |
| 系统层 | Linux内核 | fs.file-max、nf_conntrack_max | 无法新建socket，日志报Cannot assign requested address |
系统层的文件描述符限制是最容易被忽视的，很多应用本身配置没问题，但Linux进程默认的ulimit -n只有1024，一个稍活跃的服务瞬间就能把它打满，行业共识认为，生产环境至少要把进程的软硬限制调整到65535以上,再结合每秒新建连接的峰值来估算。
连接耗尽告警排查路径和恢复动作
实战排查顺序：从现象反推组件
连接耗尽告警通常不是单一节点的监控指标，而是由某个入口组件发出，顺着流量路径,从边缘往内部逐层排查。
第一站：负载均衡器和Nginx
先看Nginx的连接统计,执行以下命令：
nginx -V 2>&1 | grep -o with-stream # 确认是否启用stream模块 curl http://127.0.0.1/nginx_status # 查看Active connections
如果
Active connections持续高于worker_connections的80%以上，说明Nginx的全局并发能力接近饱和,此时有两个调整方向：
- 调高
worker_connections，同时确认worker_processes和CPU核心数匹配。 - 检查
upstream配置中的keepalive参数，长连接复用不足会导致大量短连接反复建立,连接数虚高。
第二站：应用容器线程池
以Java Spring Boot应用为例，内嵌Tomcat默认的maxThreads为200，maxConnections为8192，但maxConnections只在连接被接受后处理，如果业务线程全部卡住，accept队列不断堆积，连接池很快被占满,检查JVM线程状态：
jstack <pid> | grep "http-nio" | wc -l
再配合jstat -gcutil <pid> 1000，如果连接数高而GC正常,说明确实是线程阻塞导致连接排队。
第三站：数据库连接池
数据库连接池耗尽是最常见的告警源头之一，以MySQL为例,先用管理账号查看：
SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections'; SHOW PROCESSLIST;
Threads_connected接近max_connections时，新连接会被拒绝，重点看SHOW PROCESSLIST里的Sleep线程数量，如果大量连接处于空闲状态，说明应用侧连接池的maxActive偏高或者minIdle配置过大，占用了大量数据库连接槽位，调优方向是压缩空闲连接,而不是一味扩大连接池上限。
紧急情况下的恢复操作
如果生产环境已经出现大量报错，核心原则是先止损、再排查、后根治，按以下顺序操作，每一步至少观察12分钟：
- 重启应用实例：清理被占用的连接和异常线程，至少能恢复大部分服务，但注意，如果是数据库连接耗尽，重启应用只会释放连接,不必重启数据库。
- 调大连接池上限：针对具体的组件，临时修改参数并热加载，Nginx执行
nginx -s reload,JDBC连接池通过配置中心动态调整。 - 杀掉阻塞源头：定位到执行时间特别长的SQL或外部接口调用，在数据库层
KILL <thread_id>，在应用层用kill -3 <pid>导出线程快照分析堆栈。 - 限流降级：接入层临时开启限流，把突发流量挡在系统容量边界之外,防止雪崩。
这里要警惕一个常见误区：盲目重启只能缓解，不能当作修复方案，如果底层容量配置没调整，重启后大概率会在业务高峰期再次触发告警,且频率会越来越高。
连接池容量规划的合理思路
别陷入“越大越好”的误区
针对Nginx连接池耗尽怎么解决，很多人的第一反应就是把worker_connections调到百万级，但连接数并不是越大越好，每个连接都会占用内存和内核资源，在调整之前,需要计算一条关键公式：
单机最大并发连接数 ≈ 每秒新增连接数 × 平均连接持续时间（秒）
举个例子，接入层每秒接收1000个新连接，每个连接平均持续30秒，那么同时活跃的连接数在30000左右，就算worker_connections设置到100万，业务后端也扛不住这么大的并发穿透，连接池的容量应该游服务的处理能力为基准回推,而不是盲目叠加。
预留安全水位与动态伸缩
容量规划不是设置一个固定值就结束，对比2020年前后，云原生架构和容器化部署改变了连接池管理方式,现在更推荐动态调整与监控联动：
- 为连接池设定水位线告警（比如达到70%时提前预警），而不是等到100%才触发连接耗尽告警。
- 对无状态服务使用HPA（Horizontal Pod Autoscaler）,根据连接数指标自动扩缩容。
- 定期利用全链路压测评估各层连接上限，压测时重点观测连接数曲线是否出现“断崖式”上涨,这比看吞吐量更能提前暴露容量风险。
业内专家指出，连接耗尽告警很少由单一参数导致，多数情况下是流量模型变化、配置不合理、代码连接泄漏三者叠加的结果，如果你在排查时反复调参仍无法解决，优先怀疑是否有连接未关闭，使用lsof -p <pid> | wc -l对比进程句柄数和预期值,异常偏差往往意味着代码层面的资源泄漏。
关键字参数配置清单
对于常见组件的连接容量设置，以下参考值适用于多数中大型业务场景,可作为容量规划的起始点：
- Nginx：
worker_connections设为65535起，配合multi_accept on; use epoll; - Tomcat：
maxThreads建议设为核心业务线程池的23倍，acceptCount不要超过1000 - MySQL：
max_connections先按“业务实例数 × 每实例最大活跃连接数 × 冗余系数”计算，再用压测验证 - Linux内核：
fs.file-max调高到1000000，net.ipv4.tcp_max_syn_backlog和net.core.somaxconn同步调整，避免半连接队列先溢满
Nginx连接池耗尽怎么解决的配置示例与实际调优
Nginx是连接耗尽告警的高发区,给出一个完整的调优操作路径：
worker_processes auto;
events {
worker_connections 65535;
multi_accept on;
use epoll;
}
http {
upstream backend {
server 10.0.0.11:8080;
server 10.0.0.12:8080;
keepalive 128;
}
server {
listen 80 backlog=4096;
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
}
在此配置中,两个细节直接关系连接耗尽是否触发：
keepalive 128：表示Nginx到后端应用每个worker保持128个长连接,避免每次请求都重新建立TCP连接。backlog=4096：代表Nginx监听队列的长度，若这里太小，TCP握手成功但应用来不及accept,连接依然会报错。
执行nginx -t && nginx -s reload后，观察ss -s的输出，重点关注TIME-WAIT和ESTAB的数量，如果大量处于TIME-WAIT，说明短连接过多，需要将keepalive值进一步调大，或者开启tcp_tw_reuse。
防火墙和系统层还需要同步调整,否则Nginx配置再高也会被内核限制住：
# 加大文件描述符限制 echo " soft nofile 1000000" >> /etc/security/limits.conf echo " hard nofile 1000000" >> /etc/security/limits.conf # 设置SYN队列长度 sysctl -w net.core.somaxconn=65535 sysctl -w net.ipv4.tcp_max_syn_backlog=65535
防止连接泄漏与周期性检查的方法
主动检查的实操路径
建立每月一次或每季度一次的连接容量巡检,避免告警总是被动出现：
- 通过
ss -tan state established | wc -l查看当前TCP建立连接的绝对数量,与上周同期对比是否有趋势性上涨。 - 在监控面板创建“连接数日同比”视图，观察是否存在一周内持续走高、周末回落的规律，如果没有回落,大概率存在慢连接泄漏。
- 对数据库层定期执行：
SELECT user, host, db, COUNT() FROM information_schema.processlist GROUP BY user, host, db;
如果某个应用IP的连接数持续升高且没有下降趋势,优先检查该应用是否在使用完连接后执行close逻辑。
面对连接耗尽时的处理顺序总结
最后再梳理一次应对连接耗尽告警的标准处理逻辑,这能有效避免你在多台服务器之间反复切换排查而无所得：
- 先看全局连接数曲线，区分突发型（数分钟内快速上升）和累积型（一整天逐步走高）。
- 突发型优先查慢SQL与外部依赖阻塞,用线程快照确认是否有大量线程卡在同一个调用上。
- 累积型优先查连接泄漏，结合
lsof和GC日志查看是否有对象无法被回收。 - 确认组件配置无误后,再从系统内核参数层面排查文件描述符与连接跟踪表上限。
在你的业务规模扩大、峰值流量翻倍时，连接耗尽告警会以更高的频次出现，这个指标是容量规划最直接的信号灯，不用对它过度恐惧，它每次亮起都在提醒你：某个连接槽位的容量到了极限，是时候主动调整了。
常见问题解答
MySQL连接数满了怎么排查？
先登录MySQL执行SHOW PROCESSLIST;，观察Command字段为Query的线程执行的SQL，如果大量Query处于Waiting for table metadata lock状态，说明表结构锁冲突，优先排查是否存在未提交事务持有MDL锁，如果大量连接处于Sleep状态，则是应用连接池配置过大，建议缩减连接池的maxActive或增加空闲连接回收时间，可以通过SHOW VARIABLES LIKE 'wait_timeout';确认当前空闲连接超时时间,并适当调低来加速释放闲连接。
连接耗尽告警与TCP连接数超限有什么差异？
连接耗尽告警是业务层的提示，TCP连接数超限是内核层的特征，当业务组件（如Tomcat或MySQL）报告连接池满时，系统层面的TCP连接数未必达到内核上限；而TCP连接数超限时，业务层肯定会表现为连接失败或超时，排查差异的核心方法：当业务报连接耗尽时，用ss -s检查系统整体连接数；如果系统连接数仍有空间，问题出在业务组件自身；如果timewait或established数量巨大,就需要先清理系统层连接再调业务参数。
为什么数据库连接池配置已经很大，还是会报连接耗尽？
一个典型原因是“大连接池把小连接池堵死”，例如应用A的连接池设置了1000，应用B的限制是200，数据库整体上限是2000，应用A在高并发时占满所有连接槽位，应用B的连接请求直接被拒绝，要打破这个局面，需按业务优先级拆分独立的MySQL实例或账号限制，同时在数据库侧设置用户级MAX_USER_CONNECTIONS，避免单一业务抢占全部空闲连接，另一个原因是连接耗尽告警本身就来自你所配置的巨大连接池，错误日志报的是“能够创建新连接的上限”，不是内核限制,这说明应用持有的连接未正常回收。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/634972.html
