PG 连接数被打满 连接池和 max_connections 谁先动

早高峰应用侧开始报 FATAL: sorry, too many clients already，新连接一律被拒，连接数曲线一直是满的。日志里能对上时间点，这种反而好排。

max_connections 只有 100，应用每个实例开 20 条常驻连接，实例一扩就超，空闲连接也不会自己退，光调大参数只是拖时间。这一点先确认清楚，后面就不用反复试。

SELECT state, count(*) FROM pg_stat_activity GROUP BY 1;
SELECT count(*) FROM pg_stat_activity WHERE state = 'idle';
ALTER SYSTEM SET max_connections = 200;

「PG 连接数耗尽」改完先别急着全量，挑一台机器放半天，真有问题这段时间就能看出来。能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。

报错里带路径的，先去看那个路径在不在、权限对不对。同一份配置存在多处的，先确认改的是被加载的那一份。

新版本先放一台机器上跑一天再全量，问题一般在这段时间暴露。

处理上按这个顺序：先查连接视图里 idle 状态占了多少，空闲连接最可疑；应用侧换成有上限的连接池，并设空闲回收时间；前面都做完再小幅上调 max_connections，同时盯内存。

结果对不对很好判断，高峰时连接总数稳定在 150 以下，日志里不再出现 too many clients。