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

  • Z时代
  • 2024-01-10
  • 分类：问答

有一个表，其中有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应用程序中连续选择并更新，则会出问题。–

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

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

回答：

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

  • 长期交易。

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

  • 过时的复制插槽。

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

以上是 postgresql中的大量活动/死元组/ Vacuum不起作用 的全部内容， 来源链接： utcz.com/qa/424998.html

回到顶部