今天遇到一个问题,就是pg一直报错,说有太多的客户端连接到数据库上面。但现在不知道是什么程序连接。pg默认的max_connection是100,我并没有修改过,以为平时公司内部用,应该够了,但现在貌似这100个连接都被消耗掉。在网上google了一下,发现用下面的SQL,居然可以查看所有连接的状况:
select * from pg_stat_activity;
结果集会显示出当前连接的数据库名,用户,IP地址,连接开始时间,查询的语句等。
这里的pg_stat_activity其实是一个视图,它的定义可以在postgres这个数据库里面的视图部分找到,以下是它的定义:
CREATE OR REPLACE VIEW pg_stat_activity AS SELECT s.datid, d.datname, s.procpid, s.usesysid, u.rolname AS usename, s.application_name, s.client_addr, s.client_hostname, s.client_port, s.backend_start, s.xact_start, s.query_start, s.waiting, s.current_query FROM pg_database d, pg_stat_get_activity(NULL::integer) s(datid, procpid, usesysid, application_name, current_query, waiting, xact_start, query_start, backend_start, client_addr, client_hostname, client_port), pg_authid u WHERE s.datid = d.oid AND s.usesysid = u.oid;
可以看到,pg_stat_activity这个视图是由 pg_database,pg_authid,以及两个方法的结果来组合成的。
pg_database ,顾名思义就是储存了在pg里面的所有的数据库名称。
pg_authid,是用来储存pg的登录账号。
pg_stat_get_backend_activity在Postgresql里面的定义如下:
CREATE OR REPLACE FUNCTION pg_stat_get_backend_activity(integer) RETURNS text AS 'pg_stat_get_backend_activity' LANGUAGE internal STABLE STRICT COST 1;
ALTER FUNCTION pg_stat_get_backend_activity(integer) OWNER TO postgres; COMMENT ON FUNCTION pg_stat_get_backend_activity(integer) IS 'statistics: current query of backend';
可见它是一个pg的内部方法,用来统计当前query的数目。
看来pg的内部结构还是挺清楚简单的。越来越喜欢pg的这种简单与强大了!
好了,现在我们找出所有连接到数据库的进程了,那么如何去杀死那些IDEL的进程从而释放出连接呢?
如果pg的版本是 8.4及以上的,可以很简单地用下面的语句来杀死所有IDEL进程 :
SELECT pg_terminate_backend(procpid) FROM pg_stat_activity WHERE current_query=''
pg_terminate_backend 是pg的内部方法,另外还有一个叫pg_cancel_backend,这个方法在8.4以前的版本中就一直存在。这两个方法的区别在于,pg_cancel_backend 只是取消当前某一个进程的查询操作,但不能释放数据库连接。但pg_terminate_backend 可以在pg的后台杀死这个进程,从而释放出宝贵的连接资源。
但如果pg的版本是在8.3或者以下的,就不能用上面的方法了。首先,同样的,要先找出pg里面有什么IDEL的连接,然后在windows的command里面,输入以下命令:
pg_ctl kill TERM PID
以上命令是调用pg的后台命令行 pg_ctl去执行命令,直接kill那个进程。这样会同时导致windows和pg的进程同时被杀死,从而释放资源。比较麻烦的是,只能手动地一个一个进程来杀,没有批量的方法。
另外一个比较有用的工具是pgAdmin提供的,在pgAdmin -> 工具 -> 服务器状态,会列出当前pg里面所有的连接,从而可以看到什么进程在进行什么操作,pid是多少,什么时候开始,运行多长时间了,结果是跟用 pg_stat_activity 查询出来的结果一样的。