PostgreSQL Long VACUUM - PullRequest
Новая
       7

PostgreSQL Long VACUUM

4 голосов
/ 12 января 2009

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

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

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

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

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

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

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

Ответы [ 4 ]

5 голосов
/ 12 января 2009

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

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

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

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

4 голосов
/ 12 января 2009

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

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

Альтернативой VACUUM является сброс и восстановление.

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

0 голосов
/ 04 мая 2011

Старый VACUUM FULL - это ископаемое. Это тоже довольно медленно, и вы добрались до 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 не поддерживает это.

0 голосов
/ 24 января 2009

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

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

...