一次数据库连接泄漏导致的响应迟缓

本文主要是介绍一次数据库连接泄漏导致的响应迟缓，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

数据库连接池泄漏其实非常普遍，本文简单记一次数据库连接池泄漏问题，排查和思考。

问题与分析

问题：服务器上的负载激增， Postgres 查询的时间和CPU消耗都异常飙升。

分析：经过调试，得出以下分析：

有一个有 200 行的表，但是显示的活动元组的数量不止这个（大约 60K），我们正在使用的是 Postgresql 9.3。

以下是查询结果：

select count(*) from subscriber_offset_manager; 
count 
------- 
200 (1 row) SELECT schemaname,relname,n_live_tup,n_dead_tup FROM pg_stat_user_tables where relname='subscriber_offset_manager' ORDER BY n_dead_tup ; 
schemaname | relname | n_live_tup | n_dead_tup 
------------+---------------------------+------------+------------ 
public | subscriber_offset_manager | 61453 | 5 (1 row)

但是从 pg_stat_activity 和 pg_locks 可以看出，我们无法跟踪任何打开的连接。

SELECT query, state,locktype,mode FROM pg_locks JOIN pg_stat_activity USING (pid) WHERE relation::regclass = 'subscriber_offset_manager'::regclass ; 
query | state | locktype | mode 
-------+-------+----------+------
(0 rows)

我还在这张表上尝试了 full vacuum 。结果如下：

一直无法删除行
有几次，所有的活动元组突然变成了死元组。

这是运行 full vacuum 命令的输出：

vacuum FULL VERBOSE ANALYZE subscriber_offset_manager; 
INFO: vacuuming "public.subscriber_offset_manager" 
INFO: "subscriber_offset_manager": found 0 removable, 67920 nonremovable row versions in714 pages 
DETAIL: 67720 dead row versions cannot be removed yet. CPU 0.01s/0.06u sec elapsed 0.13 sec. 
INFO: analyzing "public.subscriber_offset_manager" 
INFO: "subscriber_offset_manager": scanned 710 of 710 pages, containing 200 live rows and67720 dead rows; 200 rows in sample, 200 estimated total rows VACUUM after that i checked for live and dead tuples for that table as follows : SELECT schemaname,relname,n_live_tup,n_dead_tup FROM pg_stat_user_tables where relname='subscriber_offset_manager' ORDER BY n_dead_tup ;
schemaname | relname | n_live_tup | n_dead_tup 
------------+---------------------------+------------+------------ 
public | subscriber_offset_manager | 200 | 67749

10 秒后：

SELECT schemaname,relname,n_live_tup,n_dead_tup FROM pg_stat_user_tables where relname='subscriber_offset_manager' ORDER BY n_dead_tup ;
schemaname | relname | n_live_tup | n_dead_tup
------------+---------------------------+------------+------------ 
public | subscriber_offset_manager | 68325 | 132

结果所有死元组都移动到活元组，而不是被清理。

有趣的是：当我停止Java 程序，然后做一个full vacuum时，它工作正常（行数和活动元组变得相等）。因此，如果我们从 Java 程序中去进行选择和更新，就会出现问题。

之后对堆栈溢出进行了分析和研究，经过许多尝试，我找到了以下根本原因。