高负载性能服务器PostgreSQL连接全部中断问题求助

这种在高负载服务器上突然出现全量PostgreSQL连接断开、抛出「connection has been closed」和I/O异常的情况，我在生产环境处理过好几次，给你梳理几个优先级最高的排查方向：

1. 数据库端的连接资源或会话回收问题 #

• 先查PostgreSQL的max_connections配置——高负载下如果应用侧发起的连接数打满了数据库上限，数据库会直接拒绝新连接，甚至主动踢掉旧连接来释放资源。你可以用这条SQL查看当前连接数：SELECT count(*) FROM pg_stat_activity;，对比数据库配置里的max_connections值。同时翻数据库日志，看有没有too many connections的报错。
• 另外，idle_in_transaction_session_timeout这个参数如果设置得太短，高负载下慢事务导致的空闲连接会被数据库强制回收，也会触发这类连接断开的错误。

2. 网络链路或中间件的限流/中断 #

• 高负载很容易把服务器网络栈打满，比如TCP的TIME_WAIT队列溢出，导致新连接无法建立，旧连接被重置。可以用netstat -an | grep TIME_WAIT统计一下这类连接的数量，如果数值特别高，就得调整TCP参数（比如tcp_tw_reuse）。
• 还要检查应用和数据库之间的防火墙、负载均衡设备——很多设备会有连接数上限或超时规则，高负载下触发限流后会直接断开连接，去看这些设备的日志有没有拦截记录。
• 极端情况是物理网络波动，比如交换机故障、带宽耗尽，导致TCP连接被重置，这种在高并发场景下更容易触发I/O异常。

3. 应用侧连接池的配置漏洞 #

• 如果用了连接池（比如HikariCP、Druid），先检查核心配置：
  • maxPoolSize是不是超过了数据库的max_connections？如果是，高负载下连接池会拿不到有效连接，甚至导致数据库连接耗尽。
  • connectionTimeout、validationTimeout是不是设置过短？高负载下数据库响应变慢，连接池可能会误判连接失效，提前关闭或者抛出错误。
  • 有没有开启连接泄漏检测？比如HikariCP的leakDetectionThreshold，如果连接被代码泄漏（比如没关闭），长期积累后在高负载下会突然爆发，导致所有连接失效。

4. 服务器资源耗尽导致的进程异常 #

• 先看应用服务器的监控：异常发生时CPU、内存、磁盘IO是不是打满了？比如内存耗尽触发OOM，系统杀死了部分数据库连接线程；或者磁盘IO过高导致数据库请求超时，进而触发连接断开。可以用top、iostat回溯当时的资源使用情况。
• 再看数据库服务器的资源：如果数据库本身CPU跑满、磁盘空间不足，也会导致无法响应请求，主动断开连接。

快速排查小技巧 #

• 优先拉取PostgreSQL的完整日志，应用端的异常栈只说了I/O错误，数据库日志里会有更具体的原因，比如「terminating connection due to administrator command」或者「could not receive data from client: Connection reset by peer」。
• 用tcpdump在应用或数据库服务器抓包，看异常发生时是哪一端发起的FIN/RST包，能快速定位是应用、数据库还是网络的问题。

内容的提问来源于stack exchange，提问作者Nicu