Linux如何排查数据库连接数过多_Linux数据库连接数过多排查总结-LINUX-PHP中文网

数据库连接数过多本质是连接泄漏或滥用，需先区分os层tcp连接异常还是db层会话超限：用ss命令查tcp连接数，再用sql查db会话数，结合来源ip、进程及socket数量定位泄漏源，重点关注close_wait和time_wait状态成因。

linux如何排查数据库连接数过多_linux数据库连接数过多排查总结

数据库连接数过多，本质是连接没释放或被滥用，不是“连太多”本身有问题，而是背后存在泄漏、配置失当或攻击。必须分层确认：是操作系统看到的 TCP 连接异常，还是数据库内部会话真超限？两者排查路径完全不同。

查清是 OS 层 TCP 连接爆了，还是 DB 层会话超限

先明确问题归属，避免在错误层面折腾：

运行 ss -tn state established | grep :1521 | wc -l（Oracle 默认端口）或 ss -tn state established | grep :3306 | wc -l（MySQL），看真实 TCP 连接数。若远高于业务预期（比如 Web 服务下 MySQL 出现 5000+ ESTABLISHED），说明网络层已堆积
登录数据库执行对应查询：SELECT COUNT(*) FROM v$session WHERE status='ACTIVE'（Oracle）或 SHOW STATUS LIKE 'Threads_connected'（MySQL）。若该值接近 processes（Oracle）或 max_connections（MySQL）上限，才是 DB 层真超限
若 OS 层连接数高但 DB 层会话数低，大概率是客户端建连后没发请求就挂起（如空闲连接池未回收、爬虫握手即断），或中间件（如 HAProxy、Nginx）与 DB 之间连接未复用
若两者都高且同步增长，重点查应用是否未归还连接（如 Java 没 close()、Python requests 没用 session 或 connection pooling）

定位占用连接最多的客户端 IP 和进程

光看总数没用，得知道谁在连、怎么连、连了多久：

快速聚合来源 IP：ss -tn state established | grep :1521 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10。若某 IP 占比极高，检查其行为是否合理（如定时任务未限频、客户端重试逻辑失控）
查本地哪个进程在连 DB：ss -tunlp | grep :1521（需 root）。输出中 pid/program 列直接给出进程 ID 和名称，比如 24567/java 或 1892/mysqld
进一步确认该进程打开的 socket 数量：ls -l /proc/24567/fd/ | grep socket | wc -l。若远高于其应有连接池大小（如 HikariCP 配置了 maxPoolSize=20，却打开 300+ socket），基本可判定连接泄漏
注意：lsof -i -n -P -p 24567 也能列出所有网络句柄，但比 ss -tunlp 慢，且在高负载下可能卡住

CLOSE_WAIT 大量存在？十有八九是应用代码没关 socket

CLOSE_WAIT 是最危险的状态之一——它表示数据库已发 FIN 关闭连接，你的应用进程却一直没调 close()。内核完全无法干预，纯属应用层 bug：

用 ss -tn state close-wait | grep :1521 | wc -l 确认数量。持续 >100 就要立即处理
定位到对应进程后，立刻检查日志：是否有 IOException、SocketTimeoutException、Connection reset 等未捕获异常导致 finally 块跳过关闭逻辑
Java 场景下，确认是否用了 try-with-resources；Python 中是否用 with conn.cursor():；Go 是否 defer rows.Close()。任何分支（包括 return、throw、panic）都必须保证资源释放
临时验证：用 strace -p 24567 -e trace=close,recv,send 观察进程是否卡在 recv() 调用上，迟迟不进入 close()

TIME_WAIT 过多？别急着改内核参数，先看是不是短连接滥用

TIME_WAIT 本身不是故障，是 TCP 正常机制。但大量出现往往暴露架构问题：

统计：ss -tn state time-wait | grep :1521 | wc -l。若单机长期 >30000，结合 cat /proc/sys/net/ipv4/ip_local_port_range（如输出 1024 65535），说明可用端口已近耗尽，可能出现 Cannot assign requested address 错误
优先从应用层优化：数据库客户端必须启用连接池（如 HikariCP 的 maximumPoolSize + connection-timeout），禁用 autoReconnect=true 类伪健壮逻辑；HTTP 调用 DB 的中间层（如 API 网关）必须开启 Keep-Alive 并复用下游连接
仅当确认是客户端角色（如 ETL 工具、监控探针）高频建连时，才考虑开 net.ipv4.tcp_tw_reuse = 1（需同时确保 net.ipv4.tcp_timestamps = 1）；服务端角色（如 Oracle Listener）开这个参数无效
net.ipv4.tcp_tw_recycle 已从 Linux 4.12+ 移除，任何文档还在提它，都是过时信息，切勿配置

真正难处理的从来不是数字本身，而是那些 CLOSE_WAIT 状态里藏着的未关闭 finally 块、那些 ESTABLISHED 背后没设超时的 HTTP 客户端、以及把 max_connections 调到 10000 却不配连接池的应用配置。状态分布和进程绑定，永远比“重启服务”更能直击根因。