适用于 PostgreSQL 13+、psql 13+。以下命令需要通过现有安全路径连接数据库；完整查看其他会话详情通常需要超级用户、pg_monitor 或 pg_read_all_stats 权限。示例不包含终止会话或修改配置，先保留故障时间线。
1. 确认是连接槽位紧张，而不是服务未启动
SELECT now() AT TIME ZONE 'UTC' AS utc_time, version();
SELECT current_setting('max_connections')::int AS max_connections,
current_setting('superuser_reserved_connections')::int AS superuser_reserved,
count(*) FILTER (WHERE backend_type = 'client backend') AS client_backends
FROM pg_stat_activity;
SELECT backend_type, count(*)
FROM pg_stat_activity
GROUP BY backend_type
ORDER BY count(*) DESC;
client_backends 可作为应用会话占用的直接指标，但不要把它简单当成所有槽位的精确余额；复制连接和不同后端类型应结合第二条查询一起看。客户端出现 too many clients already 或“剩余连接槽位保留给管理连接”时，再与同一 UTC 时间的 PostgreSQL 日志对应。pg_isready 只适合判断服务器是否响应连接探测，不能证明普通应用角色还能建立并完成查询。
2. 找出连接集中在哪个来源
SELECT datname, usename, application_name, client_addr, state, count(*) AS sessions
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY datname, usename, application_name, client_addr, state
ORDER BY sessions DESC
LIMIT 30;
SELECT pid, datname, usename, application_name, client_addr, state,
now() - xact_start AS xact_age,
now() - state_change AS state_age,
wait_event_type, wait_event
FROM pg_stat_activity
WHERE backend_type = 'client backend'
ORDER BY xact_start NULLS LAST
LIMIT 30;
重点区分三类现象：大量 active 可能是查询变慢导致连接归还不及时；大量 idle 常见于每个进程各自建立过大的池；长时间 idle in transaction 可能同时占连接、持有事务快照或锁。application_name 为空时，应回到连接串和驱动配置补齐标识，否则很难区分实例。查询文本、地址和角色名可能包含敏感信息，公开排障时只保留必要摘要。
3. 对齐数据库日志与慢点
先确认日志去向和生效配置：
SHOW log_destination;
SHOW logging_collector;
SHOW log_directory;
SHOW log_connections;
SHOW log_disconnections;
SELECT name, setting, unit, source, sourcefile, pending_restart
FROM pg_settings
WHERE name IN (
'max_connections',
'superuser_reserved_connections',
'statement_timeout',
'idle_in_transaction_session_timeout'
)
ORDER BY name;
若由 systemd 托管，可从实际单元读取同一窗口；发行版的单元名可能不是 postgresql，执行前先确认：
systemctl list-units --type=service 'postgresql*'
sudo journalctl -u <actual-postgresql-unit> \
--since '<UTC-start>' --until '<UTC-end>' --no-pager -o short-iso
把首次拒绝连接的时间与部署、流量变化、查询延迟、锁等待和应用副本数对应。只看到连接数高并不能判断是容量不足还是下游变慢造成的堆积。
4. 核算连接池的总预算
按“每个应用进程的最大池大小 × 进程数 × 副本数”计算理论上限，并把后台任务、迁移工具、监控、复制和管理连接单独列出。常见问题不是单个池很大，而是水平扩容后每个副本都复制了同一池配置。
修复优先级通常是：先让连接池具备等待上限和背压，再缩小每副本池并修复连接泄漏或慢查询；只有完成内存与并发评估后，才考虑提高 max_connections。该参数需要重启才能生效，pg_reload_conf() 不能代替重启；可用上面的 pending_restart 验证。不要在没有确认事务用途时批量终止 idle in transaction 会话。
5. 闭环验证
变更后至少确认：
SHOW max_connections;
SELECT state, count(*)
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY state
ORDER BY count(*) DESC;
在超过原故障周期的观察窗口内，应用错误日志不再新增连接获取超时，客户端会话数稳定低于预算，长事务和 idle in transaction 没有持续累积，并通过真实入口完成无副作用查询。若做了应用扩缩容，还要重新按新副本数核算池上限；只在低流量时复测一次不足以证明问题已经闭环。