powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Процесс autovacuumа "застрял"?
18 сообщений из 18, страница 1 из 1
Процесс autovacuumа "застрял"?
    #39749419
egusakova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Привет.

Имеется Postgres 10. Запустился процесс autovacuumа для одной из таблиц. Бежит уже несколько дней но похоже что "завис" (нет изменений в percents с точностью до последнего знака после запятой уже больше суток):

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
postgres=# select *,heap_blks_scanned/heap_blks_total::numeric*100 AS percents  from pg_stat_progress_vacuum;
....
-[ RECORD 3 ]------+----------------------------
pid                | 6149
datid              | 16403
datname            | db_name
relid              | 13664079
phase              | vacuuming indexes
heap_blks_total    | 37789852
heap_blks_scanned  | 23860705
heap_blks_vacuumed | 0
index_vacuum_count | 0
max_dead_tuples    | 178956970
num_dead_tuples    | 178956680
percents           | 63.14050925629452055000




strace по pid показывает:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
....
select(0, NULL, NULL, NULL, {0, 32393}) = 0 (Timeout)
read(393, "\374\\\0\0\3008\205j\0\0\0\0D\3@\23\360\37\4 \0\0\0\0@\223 \0\340\237 \0"..., 8192) = 8192
futex(0x7fe0e2ba7538, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff) = 0
futex(0x7fe0e2ba7538, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7fe0e2ba0838, FUTEX_WAKE, 1)    = 1
futex(0x7fe0e2ba7538, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff) = 0
select(0, NULL, NULL, NULL, {0, 80000}) = 0 (Timeout)
read(393, "DV\0\0\300\266,\377\0\0\0\0\20\3\20\24\360\37\4 \0\0\0\0\20\224 \0\340\237 \0"..., 8192) = 8192
futex(0x7fe0e2ba7538, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff) = -1 EAGAIN (Resource temporarily unavailable)
select(0, NULL, NULL, NULL, {0, 80000}) = 0 (Timeout)
....



Сам процесс автовакууминга выглядит рабочим
Код: sql
1.
postgres  6149  3.6 23.4 31306868 30547540 ?   Rs   Dec15 177:33  \_ postgres: autovacuum worker process    db_name



В postgresql.conf такие настройки:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
autovacuum_analyze_scale_factor = 0.01
autovacuum_freeze_max_age = 200000000
autovacuum = on
checkpoint_completion_target = 0.7
default_statistics_target = 1000
data_directory = '/pgdata/10'
datestyle = 'iso, mdy'
default_text_search_config = 'pg_catalog.english'
dynamic_shared_memory_type = posix
effective_cache_size = 84GB
hot_standby = on
lc_messages = 'C'
lc_monetary = 'C'
lc_numeric = 'C'
lc_time = 'C'
listen_addresses = '*'
log_timezone = 'UTC'
maintenance_work_mem = 2GB
max_connections = 1000
max_replication_slots = 10
max_wal_senders = 10
max_worker_processes = 10
port = 5432
shared_buffers = 28GB
timezone = 'UTC'
vacuum_freeze_min_age = 30000000
wal_buffers = 16MB
wal_keep_segments = 16384
wal_level = replica
wal_sender_timeout = 60000
work_mem = 1024MB
log_destination = syslog



В логах также довольно много таких варнингов: WARNING: you don't own a lock of type ExclusiveLock.


Пока даже нет идей - завис ли процесс автовакууминга или же заблокирован или же это нормальное поведение и стоит ждать? Помогите пожалуйста разобраться
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749497
Alex URS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
egusakova WARNING: you don't own a lock of type ExclusiveLock.
так вроде ож же как бы намекает...
сделай VACUUM FULL на таблицу
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749536
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egusakova,

у вас было какое-то массовое удаление из таблицы? после удаления сколько примерно строк должно было остаться? можно показать список индексов (кусок из \d+ tablename)? я подозреваю, что есть индекс по полю типа статуса, где очень много одинаковых значений.
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749633
egusakova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alex URSegusakova WARNING: you don't own a lock of type ExclusiveLock.
так вроде ож же как бы намекает...
сделай VACUUM FULL на таблицу

Перепроверила - WARNING: you don't own a lock of type ExclusiveLock не был связан с pid процесса автовакууминга. Сейчас варнинга нет в логах(процессы вызывавшие его выключены), но ситуация с автовакуумингом не изменилась.
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749637
egusakova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alexiusegusakova,

у вас было какое-то массовое удаление из таблицы? после удаления сколько примерно строк должно было остаться? можно показать список индексов (кусок из \d+ tablename)? я подозреваю, что есть индекс по полю типа статуса, где очень много одинаковых значений.


не могу сказать точно было или не было массового удаления из таблицы, но

Код: sql
1.
2.
3.
4.
5.
db_name=# SELECT relname, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'articles';
 relname  | n_dead_tup
----------+------------
 articles |  214653365
(1 row)





Код: sql
1.
2.
3.
4.
5.
db_name=# SELECT reltuples AS approximate_row_count FROM pg_class WHERE relname = 'articles';
 approximate_row_count
-----------------------
           2.23663e+07
(1 row)



т е приблизительно в таблице 224 000 000 записей.
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749674
egusakova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alexius,

обсчиталась на 0

Код: sql
1.
2.
3.
4.
5.
6.
7.
db_name=# SELECT reltuples AS approximate_row_count FROM pg_class WHERE relname = 'articles';
 approximate_row_count
-----------------------
           2.23663e+07
(1 row)
```
22 400 000 записей



Код: sql
1.
2.
3.
4.
5.
db_name=# SELECT relname, n_dead_tup, n_live_tup FROM pg_stat_user_tables WHERE relname = 'articles';
 relname  | n_dead_tup | n_live_tup
----------+------------+------------
 articles |  214779420 |   23832015
(1 row)
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749685
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egusakova,

про индексы вопрос был важный.
значит были массовые удаления/обновления, либо автовакуум по какой-то причине не работал (из-за долгой транзакции).
имеет смысл скорей всего pg_repack таблицу сжать, если 90% данных в таблице - мусор, в таком случае вакуума не надо будет ждать (там внутри создается новая таблица, и в нее все копируется, без долгой блокировки).
можно проверить настройки maintenance_work_mem и autovacuum_vacuum_cost_delay.
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749704
egusakova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alexiusegusakova,

про индексы вопрос был важный.
значит были массовые удаления/обновления, либо автовакуум по какой-то причине не работал (из-за долгой транзакции).
имеет смысл скорей всего pg_repack таблицу сжать, если 90% данных в таблице - мусор, в таком случае вакуума не надо будет ждать (там внутри создается новая таблица, и в нее все копируется, без долгой блокировки).
можно проверить настройки maintenance_work_mem и autovacuum_vacuum_cost_delay.

Отправила Вам вывод из \d+ таблицы на почту указанную в профиле.
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749752
Valser
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
egusakova,

Была похожая ситуация, когда был выполнен перезапуск сервера, на котором установлен PostgreSQL, тогда Vacuum завис на pg_statistic, помогло только REINDEX для данной таблицы
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749884
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egusakova,

покажите еще вывод
Код: sql
1.
2.
select null_frac, most_common_vals, most_common_freqs from pg_stats where tablename = 'articles' and attname = 'proc_phase';
\di+ new_articles_proc_phase_idx
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749890
egusakova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо за ответ!
Alexiusegusakova,

покажите еще вывод
Код: sql
1.
2.
select null_frac, most_common_vals, most_common_freqs from pg_stats where tablename = 'articles' and attname = 'proc_phase';
\di+ new_articles_proc_phase_idx


Код: sql
1.
2.
3.
4.
# select null_frac, most_common_vals, most_common_freqs from pg_stats where tablename = 'articles' and attname = 'proc_phase';
 null_frac |  most_common_vals  |  most_common_freqs
-----------+--------------------+---------------------
         0 | {to_freeze,culled} | {0.709537,0.290463}



Код: sql
1.
2.
3.
4.
5.
\di+ new_articles_proc_phase_idx
                                    List of relations
 Schema |            Name             | Type  |  Owner   |  Table   | Size  | Description
--------+-----------------------------+-------+----------+----------+-------+-------------
 public | new_articles_proc_phase_idx | index | postgres | articles | 25 GB |




Процесс висит без изменений в pg_stat_progress_vacuum более двух суток,
возможно стоит сделать ему pg_terminate_backend(),
он перезапустится и посмотреть что будет?

Код: sql
1.
select *,heap_blks_scanned/heap_blks_total::numeric*100 AS percents  from pg_stat_progress_vacuum where pid=6149;


застыло на 63.14050925629452055000 %
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749896
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egusakova,

надо создать новый частичный индекс по proc_phase без значений to_freeze,culled (если другие значения бывают) и затем удалить старый. или если нет других значений - то удалить его, т.к. толку от него никакого и он тут только мешает и тупит на нем (может и на других тоже, но на нем наверняка).

затем сделать в сессии (в screen/tmux) set vacuum_cost_delay = 1; и vacuum verbose articles; ручной запуск прибьет автовакуум (он вроде тут не to prevent wraparound, который он не прибивает).
если диски не потянут - то поставить больше значение, если диски хорошие и тянут - то можно и с 0 (дефолтное значение vacuum_cost_delay) запустить.
вакуум будет рапоротовать, какие индексы он просканировал, если он затупит опять слишком надолго после какого-то индекса - то надо будет смотреть на каком именно.
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749900
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egusakova,

heap_blks_scanned и heap_blks_total весьма неслучайно начинаются с heap потому что только к heap и относятся.
А фаза vacuuming indexes обрабатывает индексы и прогресса у неё нет. Аналогично фаза cleaning up indexes
Ну и, конечно, отношение heap_blks_scanned к heap_blks_total не есть процент выполнения всего vacuum, а это есть процент выполнения отдельно фазы scanning heap. Затем для vacuuming heap надо смотреть heap_blks_vacuumed. https://www.postgresql.org/docs/10/progress-reporting.html#VACUUM-PROGRESS-REPORTING

У вас, поскольку начался vacuuming indexes при heap_blks_scanned < heap_blks_total, не хватило maintenance_work_mem. Когда дожуёт индексы, вернётся к scanning heap. Затем снова vacuuming indexes.
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39749918
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexiusegusakova,

надо создать новый частичный индекс по proc_phase без значений to_freeze,culled (если другие значения бывают) и затем удалить старый. или если нет других значений - то удалить его, т.к. толку от него никакого и он тут только мешает и тупит на нем (может и на других тоже, но на нем наверняка).

затем сделать в сессии (в screen/tmux) set vacuum_cost_delay = 1; и vacuum verbose articles; ручной запуск прибьет автовакуум (он вроде тут не to prevent wraparound, который он не прибивает).
если диски не потянут - то поставить больше значение, если диски хорошие и тянут - то можно и с 0 (дефолтное значение vacuum_cost_delay) запустить.
вакуум будет рапоротовать, какие индексы он просканировал, если он затупит опять слишком надолго после какого-то индекса - то надо будет смотреть на каком именно.

Я бы сказал что когда мертвых строк в 10 раз больше чем живых - репак или компактор в руки (Или vacuum full если недоступность таблицы не критична)... vacuum ситуацию с тем что таблица и индексы в 10 раз больше чем должны быть не решит.

PS: как вы такого распухания добились то? ;)

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39751032
egusakova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim BogukAlexiusegusakova,

надо создать новый частичный индекс по proc_phase без значений to_freeze,culled (если другие значения бывают) и затем удалить старый. или если нет других значений - то удалить его, т.к. толку от него никакого и он тут только мешает и тупит на нем (может и на других тоже, но на нем наверняка).

затем сделать в сессии (в screen/tmux) set vacuum_cost_delay = 1; и vacuum verbose articles; ручной запуск прибьет автовакуум (он вроде тут не to prevent wraparound, который он не прибивает).
если диски не потянут - то поставить больше значение, если диски хорошие и тянут - то можно и с 0 (дефолтное значение vacuum_cost_delay) запустить.
вакуум будет рапоротовать, какие индексы он просканировал, если он затупит опять слишком надолго после какого-то индекса - то надо будет смотреть на каком именно.

Я бы сказал что когда мертвых строк в 10 раз больше чем живых - репак или компактор в руки (Или vacuum full если недоступность таблицы не критична)... vacuum ситуацию с тем что таблица и индексы в 10 раз больше чем должны быть не решит.

PS: как вы такого распухания добились то? ;)

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru


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

Так как доcтупность таблицы критична - vacuum full не подходит. Решено попробовать ужать таблицу а потом возможно и всю базу.
Был поднят сервер с полной копией базы (развернута из AWS EBS снапшотов) и на нем запущен pgcompacttable со следующими параметрами:

Код: sql
1.
2.
3.
4.
5.
6.
./pgcompacttable \
    -U postgres \
    --dbname db_test \
    --table articles \
    --no-initial-vacuum \
    --verbose



До запуска pgcompacttable проверено кол-во n_dead_tup и n_live_tup:

Код: sql
1.
2.
3.
4.
# SELECT relname, n_dead_tup, n_live_tup FROM pg_stat_user_tables WHERE relname = 'articles';
 relname  | n_dead_tup | n_live_tup
----------+------------+------------
 articles |     0 |          0



Все по 0 - вероятно потому что нет статистики после рестарта.


За 16 часов прогресс 6%, при этом около 14 часов ушло на Bloat statistics with pgstattuple: duration 50914.223 seconds.
Решено было перезапустить pgcompacttable добавив --delay-ratio=0.
После этого дело пошло быстрее: Bloat statistics with pgstattuple: duration 1805.022 seconds и прогресс на данный момент 11% (за 1.5 часа).


pgcompacttable проэстимейтил уменьшение таблицы приблизительно на 300 Гиг:

Statistics: 37789852 pages (116971872 pages including toasts and indexes), it is expected that ~89.930% (33985888 pages) can be compacted with the estimated space saving being 259.292GB.

Кол-во n_dead_tup растет:

Код: sql
1.
2.
3.
4.
5.
# SELECT relname, n_dead_tup, n_live_tup FROM pg_stat_user_tables WHERE relname = 'articles';
 relname  | n_dead_tup | n_live_tup
----------+------------+------------
 articles |     148644 |          0
(1 row)




Есть следующие вопросы:

- размер таблицы около 900Гб - возможно лучше было бы использовать pg_repack потому что это было бы быстрее? Как я понимаю самая большая проблема исползования репака - дополнительное свободное место? Cвободное дисковое место имеется в размере 1.4T.

- не ясно как pgcompacttable или pg_repack поведут себя на сервере под нагрузкой от реальных запросов. Есть предположение что с этой точки зрения pg_repack не лучший выбор потому что создаст доп нагрузку и не маленькую (но при этом отработает быстрее - чего бы очень хотелось).

- что делать с запущенным процессом автовакууминга перед ужиманием? Надо ли его прибить или оставить запущенным?
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39751066
egusakova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alexiusegusakova,

надо создать новый частичный индекс по proc_phase без значений to_freeze,culled (если другие значения бывают) и затем удалить старый. или если нет других значений - то удалить его, т.к. толку от него никакого и он тут только мешает и тупит на нем (может и на других тоже, но на нем наверняка).


Я не могу вносить такие изменения без согласования с разработчиками, к сожалению.
Разработчикам сообщила.
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39751067
egusakova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Melkijegusakova,

heap_blks_scanned и heap_blks_total весьма неслучайно начинаются с heap потому что только к heap и относятся.
А фаза vacuuming indexes обрабатывает индексы и прогресса у неё нет. Аналогично фаза cleaning up indexes
Ну и, конечно, отношение heap_blks_scanned к heap_blks_total не есть процент выполнения всего vacuum, а это есть процент выполнения отдельно фазы scanning heap. Затем для vacuuming heap надо смотреть heap_blks_vacuumed. https://www.postgresql.org/docs/10/progress-reporting.html#VACUUM-PROGRESS-REPORTING

У вас, поскольку начался vacuuming indexes при heap_blks_scanned < heap_blks_total, не хватило maintenance_work_mem. Когда дожуёт индексы, вернётся к scanning heap. Затем снова vacuuming indexes.

Да, Вы несомненно правы.
Спасибо.
...
Рейтинг: 0 / 0
Процесс autovacuumа "застрял"?
    #39751070
egusakova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Текущий статус
Код: sql
1.
[Thu Dec 20 19:15:36 2018] (database:public.articles) Progress: 29%,  9951040 pages completed.



Код: sql
1.
2.
3.
4.
5.
# SELECT relname, n_dead_tup, n_live_tup FROM pg_stat_user_tables WHERE relname = 'articles';
 relname  | n_dead_tup | n_live_tup
----------+------------+------------
 articles |  216520661 |   24025528
(1 row)
...
Рейтинг: 0 / 0
18 сообщений из 18, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Процесс autovacuumа "застрял"?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]