Postgres 9.5: восстановление дампов происходит очень медленно

0

После обновления сервера (а также компьютера для дополнительных тестов) до Postgres 9.5 я попытался импортировать дампы PG 9.4 и / или восстановить дампы 9.5:

pg_dump testdb > db.sql
psql -d testdb -f db.sql

Восстановление этих дампов в PG 9.4 занимает менее 30 минут, восстановление их в PG 9.5 занимает несколько часов (даже если я создаю дамп PG 9.5 и пытаюсь восстановить этот) !!! Тестовые дампы имеют размер 8 ГБ.

Кто-нибудь знает, в чем причина? Пробовал с оригинальными конфигами PG 9.4 и 9.5, а также с различными опциями, такими как увеличение max_wal_size в 9.5, например

Я пропускаю конкретную опцию по умолчанию в 9.5, которая может отличаться от 9.4?

Пример журнала:

LOG:  duration: 278349.128 ms  statement: COPY test (id, ...)
LOG:  duration: 646487.952 ms  statement: ALTER TABLE ONLY test ...

То же самое с созданием индекса ... Это занимает часы с PG 9,5.

postgresql restore dump Barmi
источник
Хм ... проверил диск с помощью badblocks -sv / dev / sda. Но ошибок нет. Обновление все еще медленное - но только на сервере. Установил PG 9.4, тот же результат. Любая идея, что может вызвать супер длительный срок? Заранее спасибо.
Барми
Это не похоже на проблему с PG. Скорее всего, это проблема языка или локали с PG в Ubuntu 16.04, потому что проблема связана с установкой огромных индексированных таблиц с иностранными языками и, следовательно, со многими символами utf-8. Мы пропускаем языковой пакет? На другом сервере с Ubuntu 14.04 все работает нормально.
Барми

Ответы:

0

Интересно, что никто не нашел ответ ...

Это ошибка glibc: после обновления Ubuntu 14.10 (glibc 2.19) до 15.04 (glibc 2.21) мы наблюдаем значительное снижение производительности при создании одного конкретного индекса PostgreSQL. Создание индекса теперь занимает более 10 минут, а до того, как это было сделано, - около 30 секунд.

https://sourceware.org/bugzilla/show_bug.cgi?id=18441

Barmi
источник