这是一个非常经典且典型的系统性能瓶颈问题。当 ECS(云服务器)的 连接数达到上限 但 CPU 空闲 时,说明系统的瓶颈不在计算能力上,而在 资源限制、网络配置或内核参数 方面。
以下是可能导致该问题的主要原因及排查方向:
🔍 一、操作系统层面的限制(最常见原因)
1. 文件描述符(File Descriptors, FD)限制
- 现象:每个网络连接在 Linux 中通常占用一个文件描述符。如果进程能打开的最大 FD 数量受限,即使 CPU 有空闲,也无法建立新连接。
- 检查命令:
ulimit -n # 查看当前用户/进程的文件描述符上限 cat /proc/sys/fs/file-max # 查看系统全局最大文件描述符数 - 解决方案:
- 修改
/etc/security/limits.conf,增加nofile限制。 - 调整
/etc/sysctl.conf中的fs.file-max。 - 重启后生效,或使用
sysctl -p即时生效。
- 修改
2. 端口号范围限制(Ephemeral Ports)
- 现象:客户端向外发起连接时,操作系统会分配一个临时端口(ephemeral port)。默认范围通常是
32768–60999(约 28000+ 个端口)。如果所有端口被占满,无法建立新连接。 - 检查命令:
cat /proc/sys/net/ipv4/ip_local_port_range ss -tan | wc -l # 查看当前已建立的连接数 - 解决方案:
- 扩大临时端口范围:
echo "net.ipv4.ip_local_port_range = 1024 65535" >> /etc/sysctl.conf sysctl -p
- 扩大临时端口范围:
3. TCP 连接状态积压(TIME_WAIT 过多)
- 现象:大量连接处于
TIME_WAIT状态,占用本地端口和内存,导致无法新建连接。 - 检查命令:
ss -s # 查看 TCP 各状态统计 netstat -an | grep TIME_WAIT | wc -l - 解决方案:
- 启用 TCP 快速回收:
echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf sysctl -p - 缩短
TIME_WAIT超时时间(谨慎使用)。
- 启用 TCP 快速回收:
🌐 二、网络与安全组限制
1. 安全组(Security Group)规则限制
- 现象:云厂商的安全组可能对并发连接数或每秒新建连接数(New Connections/sec)有隐性限制。
- 排查:
- 检查阿里云/AWS/腾讯云控制台中的安全组规则。
- 查看是否有“限流”策略或白名单限制。
2. 负载均衡器(SLB/ALB/NLB)连接数限制
- 若前端有 LB:
- LB 本身有最大连接数限制,可能成为瓶颈。
- 检查 LB 的健康检查和后端服务器连接池配置。
3. 网卡驱动或 MTU 问题
- 现象:网络包丢失或重传率高,导致连接建立缓慢或失败。
- 排查:
ethtool eth0 # 查看网卡状态 ping -c 100 <gateway> # 测试丢包率
💻 三、应用层限制
1. Web 服务器配置限制
- Nginx/Apache/Tomcat 等:
- Nginx 的
worker_connections设置过小。 - Tomcat 的
maxThreads或acceptCount限制。
- Nginx 的
- 检查示例(Nginx):
events { worker_connections 1024; # 默认可能较小,需调大 }
2. 数据库连接池耗尽
- 现象:应用服务器与数据库之间的连接池已满,导致新请求无法获取数据库连接,表现为“连接不上”。
- 排查:
- 检查 MySQL/PostgreSQL 的
max_connections。 - 检查应用端连接池配置(如 HikariCP、Druid)。
- 检查 MySQL/PostgreSQL 的
3. 应用程序自身逻辑限制
- 某些框架或中间件(如 Redis、RabbitMQ)可能有最大连接数限制。
- 代码中存在连接泄漏(未正确关闭连接)。
📊 四、如何快速定位?
| 步骤 | 操作 | 目的 |
|---|---|---|
| 1 | ss -tan | awk '{print $1}' | sort | uniq -c |
查看各 TCP 状态分布,确认是否 TIME_WAIT 或 ESTABLISHED 过多 |
| 2 | ulimit -n |
检查文件描述符限制 |
| 3 | dmesg | grep -i error |
查看内核日志是否有“Too many open files”等错误 |
| 4 | 检查 Web 服务器配置 | 确认 worker_connections 或线程池上限 |
| 5 | 监控工具(Prometheus/Grafana) | 观察历史连接数趋势,判断是突发流量还是持续泄漏 |
✅ 总结建议
- 优先检查文件描述符和端口范围:这是最常见的原因。
- 检查应用服务器配置:如 Nginx 的
worker_connections。 - 清理异常连接状态:如
TIME_WAIT过多,启用tcp_tw_reuse。 - 检查云平台限制:安全组、LB 连接数配额。
- 监控连接泄漏:通过
ss或netstat定期观察连接状态变化。
💡 提示:如果连接数突然飙升,还需考虑是否遭受 DDoS 攻击或存在恶意扫描行为,建议结合云安全中心进行排查。
云小栈