Большое количество живых / мертвых кортежей в postgresql / вакуум не работает

есть таблица , которая имеет 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

как наш запрос приложения к этой таблице .

• наше приложение обычно выбирает некоторые строки и на основе некоторого бизнес-расчета обновляет строку .

  запрос SELECT -- выберите на основе некоторого id

  выберите * из subscriber_offset_manager, где shard_id=1;

  обновление запрос -- обновите другой столбец для этого выбранного идентификатора осколка

• около 20 потоков делают это параллельно, и один поток работает только на одной строке .

• приложение написано на java, и мы используем hibernate для выполнения операций с БД .
• версия Postgresql-9.3.24

еще одно интересное наблюдение : - когда я останавливаю свое java-приложение, а затем делаю полный вакуум, он работает нормально (количество строк и живые кортежи становятся равными). Таким образом, что-то не так, если мы выбираем и постоянно обновляем из приложения java . –

/Выпуска

эти живые кортежи несколько раз переходят в мертвые кортежи и через несколько раз снова оживают .

из-за вышеуказанного поведения выберите из таблицы время и увеличение нагрузки на сервер, так как есть много живых/мертвых ..