postgresql / vacuum中大量活动/死元组不起作用

Question

有一个表，其中有200行。但是显示的活动元组的数量不止于此（约60K）。

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)

我也在这张桌子上尝试了全真空，结果如下：

• 一直没有删除任何行
• 有时，所有的活动元组都变成死元组。

这是输出。

vacuum FULL VERBOSE ANALYZE subscriber_offset_manager;
INFO:  vacuuming "public.subscriber_offset_manager"
INFO:  "subscriber_offset_manager": found 0 removable, 67920 nonremovable row versions in 714 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 and 67720 dead rows; 200 rows in sample, 200 estimated total rows
VACUUM

 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

我们的应用程序如何查询此表。

• 我们的应用程序通常选择一些行，并根据一些业务计算来更新该行。

选择查询 -根据一些ID选择

选择* from subscription_offset_manager其中shard_id = 1;

更新查询 -为此选定的分片ID更新其他一些列

• 大约20个线程并行执行此操作，而一个线程仅在一行上工作。

• 应用程序是用Java编写的，我们正在使用hibernate进行数据库操作。

• PostgreSQL版本是9.3.24

另一个有趣的观察：
-当我停止我的Java应用程序然后完全吸尘时，它可以正常工作（行数和活动元组变为相等）。因此，如果我们从Java应用程序中连续选择并更新，则会出问题。–

问题/问题

这些活动元组有时会变成死元组，过了一段时间又复活了。

由于上述行为，请从表中进行选择，因为要花费大量时间并增加服务器的负载，因为那里有很多实时/重复数据。

Answer 1

我知道VACUUM无法完成工作的三件事：

• 长期交易。

• 未提交的准备好的事务。

• 过时的复制插槽。

有关详细信息，请参见我的博客文章。