Что делать с зависанием PostgreSQL 9.3 VACUUM ANALYZE?

Мы запускаем PostgreSQL 9.3 на платформе AWS RDS. Каждую ночь в час ночи мы запускали глобальную задачу VACUUM ANALYZE.

Вчера мы наблюдали серьезное снижение производительности, и, как оказалось, за последние 5 дней у нас зависло 5 VACUUM ANALYZE процессов. За тот же период использование диска увеличилось на 45 гигабайт.

Я убил его с помощью pg_terminate_backend, но это не оказало большого влияния. Процессы выглядели мертвыми, но производительность по-прежнему сильно снижалась. Поскольку мы используем AWS RDS, мы выполнили перезагрузку с аварийным переключением, и производительность сразу же значительно улучшилась.

Сегодня утром я проверил и обнаружил, что VACUUM ANALYZE снова застрял на 5 часов. Я убил его, но подозреваю, что он все еще где-то там.

После дальнейшего изучения я подтвердил, что auto_vacuum включен правильно, что означает, что нам не нужно запускать вручную VACUUM, но нам может потребоваться запустить ANALYZE для некоторых или всех таблиц.

В своем исследовании я нашел эту статью: http://rhaas.blogspot.com/2011/03/troubleshooting-stuck-vacuums.html и http://wiki.postgresql.org/wiki/Introduction_to_VACUUM,_ANALYZE,_EXPLAIN,_and_COUNT .

В итоге у меня следующие вопросы:

  1. Правильно ли не запускать ручной VACUUM с включенным auto_vacuum?
  2. Как я могу отслеживать ход и производительность auto_vacuum? Как я узнаю, что он не застрял в том же месте, что и ручной ПЫЛЕСОС?
  3. Нужно ли мне по-прежнему запускать ANALYZE на регулярной основе?
  4. Есть ли способ включить автоматический ANALYZE, аналогичный auto_vacuum?

postgresql amazon-web-services performance vacuum
person Oleg Dulin    schedule 02.09.2015    source источник
comment
Кстати: в следующий раз постарайтесь избежать переполнения cron.   -  person wildplasser    schedule 02.09.2015
comment
Спасибо... в процессе не заканчивается cron, но это хороший момент.   -  person Oleg Dulin    schedule 02.09.2015
comment
Вам следует обратиться в службу поддержки AWS, чтобы узнать больше о том, почему он зависает.   -  person Craig Ringer    schedule 03.09.2015

Ответы (2)


arrow_upward
5
arrow_downward

Правильно ли не запускать ручной VACUUM с включенным auto_vacuum?

Как правило, вам не нужен ручной пылесос любого типа. Если автоочистка не поспевает за ней, заставьте ее запускаться чаще и быстрее. См. документацию по автоочистке.

Как я могу отслеживать ход и производительность auto_vacuum?

Следите за ростом раздувания таблицы. К сожалению, нет pg_stat_autovacuum или подобного. Вы можете видеть, как автоочистка работает в pg_stat_activity, но только от одного мгновения к другому. Детальный анализ требует просмотра файлов журналов с включенной автоматической очисткой журнала.

Как я узнаю, что он не застрял в том же месте, что и ручной ПЫЛЕСОС?

Проверьте pg_stat_activity. Вы не знаете, что он находится в том же месте, и вы даже не можете точно сказать, прогрессирует он или нет, но вы можете видеть, работает он или нет.

Как видите, в администрирование/мониторинг вакуума можно внести множество улучшений. Однако у нас не хватает людей, у которых есть время, желание и знания, необходимые для этого. Вместо этого все хотят добавить новые блестящие функции.

Нужно ли мне по-прежнему запускать ANALYZE на регулярной основе?

No.

Есть ли способ включить автоматический ANALYZE, аналогичный auto_vacuum?

Autovacuum запускает анализ (или, скорее, VACUUM ANALYZE) при необходимости.

person Craig Ringer    schedule 03.09.2015

arrow_upward
13
arrow_downward

В Postgres 9.6+ есть два спасательных средства для этого варианта использования:

  • Новое системное представление (pg_stat_progress_vacuum), который позволяет вам видеть прогресс очистки
  • VACUUM теперь может выполнять частичную очистку, что очень удобно для больших таблиц. Пылесосы часто зависают из-за одновременных (пользовательских) запросов и в конечном итоге замедляются или блокируются и истекают по тайм-ауту. В Postgres 9.6+ Vacuum может, например. Очистите 80% большой таблицы и очистите оставшиеся 20% таблицы в последующем запуске. В предыдущих версиях это было невозможно.
person Robins Tharakan    schedule 07.11.2016
comment
Спасибо за то, что поделился этим. - person Nick; 30.11.2016