PostgreSQL性能监控需构建覆盖系统资源、数据库内部状态和SQL执行的完整体系，通过操作系统工具监控CPU、内存、磁盘I/O和网络，结合pg_stat_database、pg_stat_statements等视图分析连接数、慢查询、锁等待与缓冲区命中率，利用Prometheus+Grafana或Zabbix实现自动化采集与告警，并定期巡检表膨胀、索引使用及vacuum情况，最终将底层资源与业务影响关联形成闭环管理。
PostgreSQL的性能监控不是单一工具或指标能解决的问题，而是一个涵盖系统资源、数据库内部状态和应用行为的完整体系。要实现有效的监控，需从操作系统层到数据库实例层再到SQL执行层面层层覆盖，确保能及时发现瓶颈、预测容量并保障服务稳定。
系统资源监控：掌握底层运行状态
PostgreSQL运行依赖于CPU、内存、磁盘I/O和网络等系统资源，这些是判断数据库是否健康的基础。
CPU使用率：持续高CPU可能意味着复杂查询、锁竞争或索引缺失。可通过top、htop或sar命令观察postgres进程的CPU占用。若CPU长期超过80%，应结合慢查询日志分析执行计划。
内存使用：关注shared_buffers、work_mem配置是否合理，以及系统是否有频繁swap。free -m查看内存使用，vmstat观察page-in/page-out情况。PostgreSQL依赖OS缓存，因此剩余内存不低通常是正常现象。
磁盘I/O：使用iostat监测读写延迟（await）和利用率（%util）。高延迟常与checkpoint频繁、WAL写入压力或存储瓶颈有关。建议将数据、WAL日志、备份目录分离到不同磁盘。
网络流量：在高并发场景下，网络可能成为瓶颈。iftop或nethogs可帮助识别异常连接或大量数据传输。
数据库内部监控：聚焦关键性能指标
系统资源只是表象，深入数据库内部才能定位问题根源。
连接数监控：通过pg_stat_database视图查看当前活跃连接。连接过多会导致内存耗尽和上下文切换开销增大。建议设置max_connections合理值，并使用连接池（如PgBouncer）。
慢查询识别：启用log_min_duration_statement记录执行时间超过阈值的SQL。配合pg_stat_statements扩展，可统计SQL执行频率、总耗时、调用次数，快速定位“热点SQL”。
锁等待与阻塞：查询pg_locks和pg_stat_activity，找出长时间持有锁或被阻塞的会话。常见于未提交事务、缺少索引导致全表扫描加锁。
缓冲区命中率：计算公式为 (1 - blks_read / blks_hit) * 100。理想值应高于99%。低于95%说明物理I/O频繁，需检查shared_buffers或查询是否缺乏索引。
自动化监控与告警体系建设
手动检查不可持续，需构建自动化的监控管道。
常用方案包括：
- 使用Prometheus + Grafana + postgres_exporter采集并可视化指标
- 部署Zabbix或Nagios，通过自定义脚本监控关键视图数据
- 利用云平台自带监控（如AWS RDS Performance Insights）
设定合理告警规则，例如：
- 连接数超过阈值80%
- 慢查询数量突增
- 复制延迟超过30秒（主从环境）
- 检查点频繁触发（checkpoint_timeout或write量过大）
定期巡检与容量规划
监控不仅是故障响应，更是预防手段。
建议每周执行一次巡检，内容包括：
- 表膨胀程度（使用pgstattuple或check_postgres工具）
- 索引使用率（扫描index_scan次数，避免冗余索引）
- vacuum和autovacuum运行情况
- WAL生成速率变化趋势
根据历史数据预测未来增长，提前扩容存储或优化架构。
基本上就这些，关键是把系统资源、数据库指标和业务影响串联起来看，形成闭环。
