ВАКУУМ занимает много времени

Следующая команда VACUUM my_table выполняется уже 24 часа на Postgres (v11.5)

На столе есть около:

  • 112 миллионов строк
  • Табличное пространство: 193 ГБ
  • 6 индексов по 6 разным полям + индекс первичного ключа

Это нормально?

Дополнительная информация, если поможет...

  • Экземпляр AWS RDS
  • 16 ГБ памяти + 4 виртуальных процессора (db.m5.xlarge)
  • 800 ГБ выделенного хранилища (база данных пока занимает 495 ГБ)
  • Подготовленное количество операций ввода-вывода в секунду — 10 000

Добавление дополнительной информации здесь -

  • SELECT relname, n_dead_tup FROM pg_stat_user_tables; возвращает 163441017
  • Мы не запускаем никаких запросов приложений к БД, мы хотели, чтобы БД завершила процесс очистки

person kapso    schedule 24.11.2019    source источник
comment
Лучше задать этот вопрос на родственном сайте: dba.stackexchange.com.   -  person Basil Bourque    schedule 24.11.2019
comment
Что показывает select * from pg_stat_progress_vacuum?   -  person jjanes    schedule 24.11.2019
comment
@jjanes показывает фазу=scanning heap   -  person kapso    schedule 24.11.2019


Ответы (1)


Может быть. Возможно, ваших 16 ГБ ОЗУ слишком мало для эффективной работы с большими таблицами (190 ГБ). Очень общее правило гласит, что размер оперативной памяти должен составлять около 1/10 дБ.

Что вы можете проверить:

а) посмотрите в таблице pg_stat_activity связанный процесс и проверьте, не находится ли vacuum в состоянии ожидания блокировки.

б) если можете, проверьте метрики, связанные с IO. Возможно, там вы увидите высокие ожидания ввода-вывода - это сигнал, поэтому ваш ввод-вывод перегружен, и тогда vacuum может быть очень медленным. Таблица 193GB действительно большая.

person Pavel Stehule    schedule 24.11.2019
comment
Состояние процесса очистки теперь сканирует кучу, раньше он очищал индексы. Итак, дело движется. С точки зрения показателей ввода-вывода, он в целом был низким, так что это не кажется узким местом. - person kapso; 24.11.2019