Назад | Перейти на главную страницу

Почему pg_restore в Ubuntu занимает больше времени, чем в Windows?

Я создал файл дампа размером 21 МБ или около того:

pg_dump --format=tar --verbose --file=database.backup mydatabase

Когда я импортирую этот файл в Windows, выполняю:

pg_restore --dbname mydatabase --verbose database.backup

Это займет 1 час.

То же самое на 64-битных системах Ubuntu 10.10 займет около 7 часов!

Конечно, я говорю о тех же аппаратных характеристиках (Dell Studio XPS). Та же RAM, CPU и т. Д.

В обоих случаях я использую готовые конфигурации для PostgreSQL 8.4.7.

Возможно, конфигурация дистрибутивов другая ... Возможно, некоторая оптимизация, которую делает только дистрибутив Windows?

Дополнительная информация: В Windows 7 -> NTFS. В Ubuntu 10.10 -> ext4

Когда я делаю

pg_dump --format=tar --verbose --file=workspace/work/dumps/loaded.backup mydb

У меня занимает всего 5 секунд! Если я восстановлю пустой новый БД, сделав:

pg_restore --dbname mydb-2 --verbose workspace/work/dumps/loaded.backup

У меня всего 10 секунд. (Проблема решена? ... почти) Кажется, ребята из db экспортировали исходный дамп, используя разные параметры. Возможно, опция --inserts?

Большая разница между Windows и Ubuntu с использованием исходного дампа все еще беспокоит меня. Есть мысли по этому поводу?

Даже один час - это очень много для небольшого файла дампа размером 21 МБ. Мы восстанавливаем базы данных из сжатого файла дампа размером 2 ГБ примерно за 30 минут, но у нас может быть лучшее оборудование ;-)

Что следует прочитать в первую очередь:

http://www.postgresql.org/docs/8.4/static/populate.html

Все дело в твоей проблеме. Он расскажет вам, как быстро заполнить базу данных.

Дополнительный чаевые:

  • Сначала включите регистрацию всех выписок с указанием продолжительности и посмотрите, что происходит
  • Увеличьте shared_buffers, по умолчанию в ubuntu 10.10 это всего 24 МБ, см. http://www.postgresql.org/docs/8.4/static/kernel-resources.html#SYSVIPC для настройки вашей системы Linux на прием более высоких значений
  • используйте --format = custom или -Fc для сброса. Это лучший выбор
  • вы можете запустить pg_restore на нескольких процессорах с помощью «-j», но я думаю, у вас есть другие проблемы, связанные с получением последних бит производительности

Для дополнительной информации:

Редактировать: Я упустил из виду, что вы сказали, что дамп занимает всего 21 МБ и даже не сжат. Даже 1 час - это очень много времени, чтобы восстановить этот объем данных. Не могли бы вы пролить свет на то, что находится на свалке? Какая структура таблицы, сколько индексов и какие? Функциональные показатели? Индексы GiST / GIN? Сколько данных создается после восстановления дампа?

Список рассылки PostgreSQL может быть лучшим местом для обсуждения этого.

Старый пост

Конфигурация PostgreSQL по умолчанию очень консервативна с точки зрения требований к ресурсам. Это означает, что во время массовой загрузки он должен выполнять очень частые контрольные точки (ваши журналы Postgres, вероятно, полны предупреждений контрольных точек).

Я подозреваю, что PostgreSQL в Windows может неправильно сбрасывать все на диск, поэтому контрольные точки не сильно влияют на производительность. Если это правда, это, конечно, плохо для целостности базы данных.

Если мои предположения верны, натыкаясь checkpoint_segments до 50 в конфигурации Ubuntu должны заставить его работать аналогично Windows. (Есть много других настроек, но это самая важная для массовой загрузки)

Кроме того, что делает SHOW wal_sync_method скажите об установке Ubuntu? Так должно быть fdatasync для оптимальной производительности, но в некоторых версиях по умолчанию open_datasync.

Попробуйте отключить автоочистку в своем postgresql.conf.

Если это не помогает, попробуйте дефрагментировать свой диск ...

Кроме того, мне интересно, какова была файловая система в обоих случаях?