如何监测PostgreSQL单个活跃连接的CPU/RAM等资源占用

PostgreSQL采用进程模型，每个客户端连接会对应一个独立的操作系统后端进程，连接开销不能一概而论，核心看连接的状态：

• 空闲连接：基础开销很低，默认配置下单个空闲连接通常仅占用2~10MB常驻私有内存，几乎不消耗CPU，只有维持连接心跳、等待客户端请求的极少量调度开销，百级规模的空闲连接一般不会对实例造成明显压力。
• 活跃连接（正在执行查询、持有事务的连接）：开销波动范围极大，和当前执行语句复杂度、结果集大小、事务持有的资源规模直接相关：轻量点查类的活跃连接仅比空闲连接多占几MB内存、产生毫秒级CPU占用；但执行复杂多表关联、大结果集排序、哈希聚合、批量写入的连接，可能占用GB级工作内存、吃满单个CPU核心（PostgreSQL单连接单事务默认不会自动跨核调度）。如果是长事务不提交的idle in transaction状态连接，还会长期持有事务快照、行锁/表锁，阻塞其他连接写入、拖慢VACUUM垃圾回收，带来的隐性开销远高于自身直接占用的资源。

生产环境通用经验：PostgreSQL实例的同时活跃连接数建议控制在CPU核心数的1.5~2倍，超过阈值后多连接带来的CPU上下文切换、锁竞争开销会急剧上升，这也是生产环境普遍部署PgBouncer这类连接池做连接复用的核心原因。

统计单连接资源占用时，不要只看直接的CPU、内存占用，还要覆盖会影响整体性能的隐性开销：

• CPU类指标
  • 连接进程用户态/内核态的实时CPU使用率、累计CPU消耗时间片
  • 连接等待CPU调度的等待时长（用于判断是否因连接数过多出现CPU抢占）
• 内存类指标
  • 连接进程独占的常驻内存（RSS，注意不要把所有连接共享的shared_buffers部分算到单连接头上）
  • 连接执行语句时申请的work_mem工作内存（用于排序、哈希表计算的临时内存）
  • 连接持有的临时表、服务端游标占用的内存
• 隐性关联开销指标
  • 连接当前事务持续时长、持有锁的数量与级别
  • 连接的等待事件类型（区分是等IO、等锁、等网络还是等CPU）
  • 连接执行语句时产生的临时文件大小（work_mem不足时排序、聚合操作会落盘，会消耗大量磁盘IO）

不需要复杂的商业工具，用原生能力和轻量开源工具就能完成精准监测：

原生能力（无需额外安装插件） #

1. 先通过系统视图拿连接基础信息
   pg_stat_activity是PostgreSQL自带的核心系统视图，可以查询所有连接的状态、执行语句、事务时长、对应的操作系统进程PID，示例查询语句：

-- 查询所有非空闲连接的基础信息，排除当前查询自身的连接
SELECT 
  pid,
  usename,
  application_name,
  client_addr,
  state,
  now() - query_start AS query_running_duration,
  wait_event_type,
  wait_event,
  query
FROM pg_stat_activity
WHERE state != 'idle'
  AND pid != pg_backend_pid();

2. 关联系统命令拿实时资源数据
   拿到连接对应的操作系统PID后，直接用Linux原生命令就能读取精准的资源占用数据：

• 查实时CPU、内存占用：执行ps -o pid,%cpu,%mem,rss,vsz,cmd -p <替换为连接PID>，返回结果中rss列就是连接独占的常驻内存，单位为KB；也可以用top -p <替换为连接PID>看实时动态变化。
• 查累计CPU、IO消耗：读取/proc/<替换为连接PID>/stat文件可以拿到进程从启动开始累计的用户态、内核态CPU消耗时间；读取/proc/<替换为连接PID>/io文件可以拿到连接进程累计的磁盘读写量、临时文件IO量。

常用辅助工具 #

• pg_top：专为PostgreSQL设计的类top轻量工具，启动后直接实时展示所有连接的CPU、内存、IO占用、当前执行语句，支持按资源占用排序、查看单连接锁等待情况，是排查单连接性能问题最顺手的工具。
• 官方扩展插件：pg_stat_statements是官方维护的必装扩展，可以按连接、按SQL模板统计累计CPU消耗、临时块读写、总执行时长，不需要手动关联系统层数据；pg_buffercache可以查看单个连接访问共享内存缓冲区的情况，判断内存使用效率。
• 连接池监控：如果部署了PgBouncer做连接复用，其自带的监控视图可以查看客户端连接和后端数据库连接的映射关系、请求排队时长、连接空闲状态，避免连接数打满导致的性能雪崩。
• 时序监控栈：如果部署了postgres_exporter+node_exporter的常规监控栈，可以长期存储单连接的资源占用时序数据，回溯排查偶发的性能尖刺问题。

排查小技巧：日常排查时优先关注状态为active和idle in transaction、事务运行时长超过1分钟的连接，这类连接通常是高开销来源；普通空闲连接只要总数量不超过实例配置的最大连接数阈值，不需要过度干预。

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