前言：
postgresql的调优是比较重要的，那么，如何调优呢？自然是在某一个时间段内，通常是业务高峰期或者压测时间内实时观察数据库的运行情况，然后通过观察到的信息判断数据库的瓶颈，比如，读写瓶颈，索引瓶颈等等，最终得到一个比较准确的调优方案
那么，关键的就来了，如何实时监控数据库的运行状态？系统工具比如htop，top，free等等命令只是针对操作系统的，并不能准确反映数据库的运行情况，慢SQL这样的数据库运行细节是无法把握的哦，因此，专业的事情还是需要专业的人，专业的工具来做了，pg_activity 或者pg_top 这样的专业工具就非常的nice了
pg_activity 是一个相对较新的 PostgreSQL 实用程序，它提供了一种交互式的、易于阅读的方式来监控和分析 PostgreSQL 数据库活动。相比传统的命令行工具，如 psql 或 pg_stat_activity 视图，pg_activity 提供了更丰富的视觉展示和实时更新的特性，方便运维人员快速了解数据库的运行状态，它可以实时显示数据库的进程、查询、锁、等待事件等信息。
虽然不如 top 或 htop 这类通用系统监控工具普及，但在 PostgreSQL 社区中，pg_activity 越来越受到重视，尤其对于那些需要实时监控数据库活动的用户而言，它是一个非常有用的工具。pg_activity 通过清晰的表格形式展示进程、查询、内存、CPU使用率等信息，使得问题排查和性能分析更加直观便捷。
总之，虽然不能说 pg_activity 是绝对的主流或常用工具，但在 PostgreSQL 监控和管理领域，它是一个受欢迎且具有一定影响力的选择。
🆗，废话了半天，下面就直接上干货，不在多说了
一、
pg_activity 的安装部署（centos7）
pg_activity 和pg_top 这两个工具都是实时监控数据库运行信息的，但pg_top本文将不会多说什么，它十分类似于操作系统的实时监控小工具top命令，该工具监控的内容过于简单，其实对我们的调优活动帮助有限，而pg_activity 是有更多的功能，可以展示更多的数据库运行的详细的细节；这么说吧，就好像厨师的🔪和医生的手术刀一样，pg_activity 像手术刀一样准确
pg_activity 是基于python3.X运行的，安装部署方式比较多，但我这里只推荐使用rpm方式安装，因为这只是一个小工具，大可不必兴师动众的编译安装
yum安装也是比较的简单，把官方源配置好就可以了，安装部署见数据库的安装博客，不在这里废话了
Linux|centos7-postgresql数据库|yum安装数据库和配置repmgr高可用集群以及repmgr的日常管理工作-CSDN博客
这里需要说明一下，pg_activity 不需要特意安装在数据库的位置，可以随意安装到任意的服务器上，例如，我在192.168.123.19这个新服务器上安装pg_activity ，该服务器只安装了pg_activity ，也可以非常愉快的连接postgresql数据库，进行实时监控：
二、
简单的使用
该命令的使用非常简单方便，和psql基本一致，端口，用户，IP指定好，如果有密码按提示输入用户的密码就好了，root用户可以执行此命令：
例如，192.168.123.17服务器上安装的pg数据库，开放端口是15433，那么，连接命令如下：
pg_activity -h 192.168.123.17 -p15433 -Upostgres程序运行起来后，就可以进行简单的压测来获取数据库运行的一些细节了：
按F3，可以查看当前数据库获取到锁的是哪些进程，哪些SQL命令，十分直观的显示：
按F2，查看在等待的SQL语句，空格键暂时停止实时显示
上述输出来自于 PostgreSQL 的查询活动监控，展示了当前正在运行的事务、锁定状态、等待时间和查询语句。以下是对每一列的解读：
- SE：session ID，即会话编号，标识每个独立的数据库会话。
- APP：应用程序名称，在这里是
pgbench，一个用于基准测试PostgreSQL性能的工具。 - USER：执行查询的数据库用户，这里均为
pgbench。 - CLIENT：客户端地址和端口，这里均为
192.168.123.17/3。 - RELATION：受影响的表，例如
319565代表表OID（对象标识符），None表示未显示具体的表名。 - TYPE：锁定类型，这里是
tuple（行级锁定）或transactionid（事务ID锁定）。 - MODE：锁定模式，这里均为
ExclusiveLock，表示独占锁，不允许其他事务同时持有该锁。 - TIME+：事务等待锁定的时间，单位为秒。
- Waiting：事务当前正在等待的资源，如
transactionid、WALSync、ClientRead等。 - state：事务的状态，例如
active（事务正在执行中）、idle in trans（事务已开始但尚未提交或回滚）。 - Query：执行的SQL查询语句。
根据这些信息，可以看出 pgbench 在执行一组银行转账样例事务，包括对 pgbench_tellers 和 pgbench_branches 表的更新操作，以及将交易历史记录插入到 pgbench_history 表中。同时，还可以观察到一些事务在等待锁定资源，这在并发环境中是很常见的现象。通过监控此类信息，可以分析数据库的性能瓶颈、死锁情况以及事务处理效率等方面的问题。
总之，可以看到pg_activity 非常容易但不简略的显示了postgresql数据库压测时的实时运行细节，可以暴露出数据库的弱点，压测命令如下；
-bash-4.2$ tail 1111.txt
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 100
number of threads: 1
duration: 1000 s
number of transactions actually processed: 756649
latency average = 132.181 ms
tps = 756.539109 (including connections establishing)
tps = 756.547789 (excluding connections establishing)
-bash-4.2$ pgbench -U postgres -p 15433 -T 1000 -c 100 -h 192.168.123.17 -d pgbench > 1111.txt 2>&1 >>1111.txt
那么，其实关键的倒不是如何监测了，而是认识这些监控的数据，从而发现数据库的问题，上面我的数据库就比较强悍，TPS比较高嘛，吞吐率强大
好了pg_activity 这个小工具就完结撒花了！！！！~~~~~