PostgreSQL Длинный ВАКУУМ

Question

В настоящее время я очищаю таблицу с двумя индексами, 250 миллионами активных строк и примерно таким же количеством мертвых строк (или более).Я отправил команду VACCUM FULL ANALYZE со своего клиентского компьютера (ноутбука) на свой сервер.Последние 3-4 дня или около того он занимается своими делами;Мне интересно, закончится ли это в ближайшее время, потому что у меня много работы!

Сервер оснащен четырехъядерным процессором Xeon 2,66 ГГц, 12 ГБ или ОЗУ и RAID-контроллером, подключенным к 2 жестким дискам SAS емкостью 146 ГБ со скоростью вращения 10 000 об/мин в конфигурации RAID 1;он работает под управлением Suse Linux.Мне интересно...

Во-первых, процесс postmaster VACUUM, похоже, использует только одно ядро.Во-вторых, я не наблюдаю очень высокого соотношения количества операций ввода-вывода к времени простоя ввода-вывода.В-третьих, от звонка procinfo, я могу экстраполировать, что процесс VACUUM проводит большую часть своего времени (88%) в ожидании ввода/0.

Так почему же он не использует больше ядер через потоки, чтобы перегрузить RAID-контроллер (получить высокое соотношение операций ввода-вывода к простою)?Почему он ожидает ввода-вывода, если нагрузка ввода-вывода невысока?Почему он не движется быстрее со всей этой силой/ресурсами в своих руках?Мне кажется, что VACUUM может и должен быть многопоточным, особенно если он работает на огромной таблице и работает только он один!

Кроме того, есть ли способ настроить postgresql.conf, чтобы разрешить многопоточность таких VACUUM?Могу ли я убить его и при этом получить пользу от его частичной очистки?Мне нужно поработать за этим столом.

[Я использую PostgreSQL 8.1]

Еще раз спасибо

Answer 1

Вы не указываете, какую версию PostgreSQL вы используете.Возможно ли, что это до 8.0?

У меня был точно такой же сценарий.Ваш лучший лучший:

• убить вакуум
• создайте резервную копию таблицы с опцией pg_dump -t
• бросить стол
• восстановить таблицу

Если вы используете 8.x, посмотрите параметры автоочистки.Vacuum является однопоточным, и вы ничего не можете сделать, чтобы он использовал несколько потоков.

Answer 2

Несколько быстрых советов:

• Запустите VACUUM FULL VERBOSE, чтобы увидеть, что происходит.
• Отбросьте все индексы перед VACUUM.Их быстрее восстановить, чем пылесосить.Вам также придется время от времени их пересобирать, потому что VACUUM FULL недостаточно хорош (особенно на таком старом PosgreSQL, как 8.1).
• Установите очень высокое значение Maintenance_work_mem.
• Используйте более новую версию PostgreSQL.Кстати, в 8.4 будет огромное улучшение очистки.

Альтернативой ВАКУУМУ является сброс и восстановление.

Редактировать:Начиная с версии 9.0 VACUUM FULL перезаписывает всю таблицу.По сути, это то же самое, что и дамп + восстановление, поэтому запуск REINDEX не требуется.

Answer 3

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

(В любом случае, лучше использовать uum_cost_delay , чтобы вакуум не мешал работе.)

Answer 4

Старый ВАКУУМ ПОЛНЫЙ - ископаемое. Это тоже довольно медленно, и вы добрались до REINDEX потом. Не используйте это. Если вы действительно хотите дефрагментировать таблицу, используйте CLUSTER или это:

Скажем, у вас осталось немного места на диске, это намного быстрее, чем dump & reload:

CREATE TABLE newtable AS SELECT * FROM oldtable;
CREATE INDEX bla ON newtable( ... );
ALTER TABLE oldtable RENAME TO archive;
ALTER TABLE newtable RENAME TO oldtable;

Обратите внимание, что это не скопирует ваши ограничения. Вы можете использовать CREATE TABLE LIKE ... чтобы скопировать их.

  

Так почему бы не использовать больше ядер через потоки

pg не поддерживает это.