|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
Привет. Имеется Postgres 10. Запустился процесс autovacuumа для одной из таблиц. Бежит уже несколько дней но похоже что "завис" (нет изменений в percents с точностью до последнего знака после запятой уже больше суток): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
strace по pid показывает: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Сам процесс автовакууминга выглядит рабочим Код: sql 1.
В 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.
В логах также довольно много таких варнингов: WARNING: you don't own a lock of type ExclusiveLock. Пока даже нет идей - завис ли процесс автовакууминга или же заблокирован или же это нормальное поведение и стоит ждать? Помогите пожалуйста разобраться ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 13:24 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
egusakova WARNING: you don't own a lock of type ExclusiveLock. так вроде ож же как бы намекает... сделай VACUUM FULL на таблицу ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 14:22 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
egusakova, у вас было какое-то массовое удаление из таблицы? после удаления сколько примерно строк должно было остаться? можно показать список индексов (кусок из \d+ tablename)? я подозреваю, что есть индекс по полю типа статуса, где очень много одинаковых значений. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 14:50 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
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 процесса автовакууминга. Сейчас варнинга нет в логах(процессы вызывавшие его выключены), но ситуация с автовакуумингом не изменилась. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 16:19 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
Alexiusegusakova, у вас было какое-то массовое удаление из таблицы? после удаления сколько примерно строк должно было остаться? можно показать список индексов (кусок из \d+ tablename)? я подозреваю, что есть индекс по полю типа статуса, где очень много одинаковых значений. не могу сказать точно было или не было массового удаления из таблицы, но Код: sql 1. 2. 3. 4. 5.
Код: sql 1. 2. 3. 4. 5.
т е приблизительно в таблице 224 000 000 записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 16:21 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
Alexius, обсчиталась на 0 Код: sql 1. 2. 3. 4. 5. 6. 7.
Код: sql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 17:05 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
egusakova, про индексы вопрос был важный. значит были массовые удаления/обновления, либо автовакуум по какой-то причине не работал (из-за долгой транзакции). имеет смысл скорей всего pg_repack таблицу сжать, если 90% данных в таблице - мусор, в таком случае вакуума не надо будет ждать (там внутри создается новая таблица, и в нее все копируется, без долгой блокировки). можно проверить настройки maintenance_work_mem и autovacuum_vacuum_cost_delay. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 17:18 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
Alexiusegusakova, про индексы вопрос был важный. значит были массовые удаления/обновления, либо автовакуум по какой-то причине не работал (из-за долгой транзакции). имеет смысл скорей всего pg_repack таблицу сжать, если 90% данных в таблице - мусор, в таком случае вакуума не надо будет ждать (там внутри создается новая таблица, и в нее все копируется, без долгой блокировки). можно проверить настройки maintenance_work_mem и autovacuum_vacuum_cost_delay. Отправила Вам вывод из \d+ таблицы на почту указанную в профиле. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 17:35 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
egusakova, Была похожая ситуация, когда был выполнен перезапуск сервера, на котором установлен PostgreSQL, тогда Vacuum завис на pg_statistic, помогло только REINDEX для данной таблицы ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 18:28 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
egusakova, покажите еще вывод Код: sql 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 22:25 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
Спасибо за ответ! Alexiusegusakova, покажите еще вывод Код: sql 1. 2.
Код: sql 1. 2. 3. 4.
Код: sql 1. 2. 3. 4. 5.
Процесс висит без изменений в pg_stat_progress_vacuum более двух суток, возможно стоит сделать ему pg_terminate_backend(), он перезапустится и посмотреть что будет? Код: sql 1.
застыло на 63.14050925629452055000 % ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 22:57 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
egusakova, надо создать новый частичный индекс по proc_phase без значений to_freeze,culled (если другие значения бывают) и затем удалить старый. или если нет других значений - то удалить его, т.к. толку от него никакого и он тут только мешает и тупит на нем (может и на других тоже, но на нем наверняка). затем сделать в сессии (в screen/tmux) set vacuum_cost_delay = 1; и vacuum verbose articles; ручной запуск прибьет автовакуум (он вроде тут не to prevent wraparound, который он не прибивает). если диски не потянут - то поставить больше значение, если диски хорошие и тянут - то можно и с 0 (дефолтное значение vacuum_cost_delay) запустить. вакуум будет рапоротовать, какие индексы он просканировал, если он затупит опять слишком надолго после какого-то индекса - то надо будет смотреть на каком именно. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 23:14 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
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. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 23:28 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
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 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 03:22 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
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 проверено кол-во n_dead_tup и n_live_tup: Код: sql 1. 2. 3. 4.
Все по 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.
Есть следующие вопросы: - размер таблицы около 900Гб - возможно лучше было бы использовать pg_repack потому что это было бы быстрее? Как я понимаю самая большая проблема исползования репака - дополнительное свободное место? Cвободное дисковое место имеется в размере 1.4T. - не ясно как pgcompacttable или pg_repack поведут себя на сервере под нагрузкой от реальных запросов. Есть предположение что с этой точки зрения pg_repack не лучший выбор потому что создаст доп нагрузку и не маленькую (но при этом отработает быстрее - чего бы очень хотелось). - что делать с запущенным процессом автовакууминга перед ужиманием? Надо ли его прибить или оставить запущенным? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2018, 19:15 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
Alexiusegusakova, надо создать новый частичный индекс по proc_phase без значений to_freeze,culled (если другие значения бывают) и затем удалить старый. или если нет других значений - то удалить его, т.к. толку от него никакого и он тут только мешает и тупит на нем (может и на других тоже, но на нем наверняка). Я не могу вносить такие изменения без согласования с разработчиками, к сожалению. Разработчикам сообщила. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2018, 22:00 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
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. Да, Вы несомненно правы. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2018, 22:02 |
|
Процесс autovacuumа "застрял"?
|
|||
---|---|---|---|
#18+
Текущий статус Код: sql 1.
Код: sql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2018, 22:16 |
|
|
start [/forum/topic.php?fid=53&msg=39749633&tid=1995427]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
52ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
others: | 291ms |
total: | 449ms |
0 / 0 |