ZilbersteinДобрый день.
С сервера бд(centOS, postgresql 9.3) сделан (pg_dump dbname --username usern | gzip > dbbackup.out.gz)
и перенесен на тестовую машину(одноядерный пентиум 2,8, гиг оперативки, CentOS 6.6, Postgresql 9.3) дамп, там же разархивирован и запущено восстановление из него( psql dbname < dbbackup.out --username usern )
Дамп базы весит примерно 32 гига, сама база на сервере весит более 50 гигов.

Процесс восстановления идет очень медленно , за сутки размер каталога data достиг примерно 1,5 гигов.
Получается этот процесс займет месяц? Возможно ли как-то ускорить процесс? Что я делаю не так?

В общем да делать dump в custom формате и восстанавивать через pg_restore.
Возможно еще посмотреть на настройки базы на тестовом сервере (далеко не факт что они вменяемы).
Учитывая размер базы и сколько у вас оперативки я бы сказал что в любом случае это будет ОЧЕНЬ надолго если у вас диск не SSD, и упираться и в диск и в процессор будет (но вероятнее всего в диск).
Посмотрите по top и по iostat - что у вас на 100% занято диск или процессор или и то и другое.

--
Maxim Boguk
www.postgresql-consulting.ru

ZilbersteinMaxim BogukВ общем да делать dump в custom формате и восстанавивать через pg_restore.
Возможно еще посмотреть на настройки базы на тестовом сервере (далеко не факт что они вменяемы).
Учитывая размер базы и сколько у вас оперативки я бы сказал что в любом случае это будет ОЧЕНЬ надолго если у вас диск не SSD, и упираться и в диск и в процессор будет (но вероятнее всего в диск).
Посмотрите по top и по iostat - что у вас на 100% занято диск или процессор или и то и другое.


Приведите пожалуйста примеры команд дампа в кастом формате и обратной ей pg_restore.
Упирается в диск: iostat показывает 92-94% загрузки диска, top показывает всего 10-12% загрузки процессом postmaster.

Мало памяти при неверно настроенной базе при слабых дисках - вот и имеем что имеем.

--
Maxim Boguk
www.postgresql-consulting.ru

ZilbersteinMaxim BogukМало памяти при неверно настроенной базе при слабых дисках - вот и имеем что имеем.

И все же что понимается под неверными настройками базы? На тестовой машине только установлена Postgresql и
выполнены следующие команды:
$ su – postgres
$ psql
postgres=# create user username unencrypted password 'passwd' ;
postgres=# create database dbname owner username ;

Настройки базы по умолчанию рассчитаны на установку на сервер 20 летней давности.
Никакой разумной производительности от настроек по умолчанию В ПРИНЦИПЕ не стоит ожидать ни на каких задачах.


--
Maxim Boguk
www.postgresql-consulting.ru

ZilbersteinursidoZilberstein,

При этом никакие изменения в параметры postgresql.conf внесены не были?
Работа продолжается на параметрах по умолчанию?


Нет, изменения были внесены по рекомендации калькулятора с сайта http://pgtune.leopard.in.ua/
max_connections = 5
shared_buffers = 512MB
effective_cache_size = 1536MB
work_mem = 104857kB
maintenance_work_mem = 128MB
checkpoint_segments = 32
checkpoint_completion_target = 0.7
wal_buffers = 16MB
default_statistics_target = 100

Помимо этого добавил оперативки до 2 гигов. Эффект тот же. Процесс pg_restore забивает 1,7 гига физической памяти, а когда количество занятой виртуальной памяти достигает 3 гигов - через 3 минуты после запуска команды вылетает сообщение: Out of memory
Единственная инфа по времени - в логе secure:
Jul 16 16:19:29 nautest runuser: pam_unix(runuser-l:session): session opened for user postgres by (uid=0)
Jul 16 16:19:31 nautest runuser: pam_unix(runuser-l:session): session closed for user postgres
Имеет ли смысл увеличивать файл подкачки?

pgtune рекомендации в принципе не расчитаны на сервера с оперативкой меньше чем в мобильном телефоне.
не удивительно что оно в swap улетает и OOM.

--
Maxim Boguk
www.postgresql-consulting.ru