ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / RESTORE больших таблиц
7 сообщений из 7, страница 1 из 1
RESTORE больших таблиц
    #35474903
324f4
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
324f4
Гость
День добрый всем!

Ситуация. В базе есть довольно большая таблица (несколько десятков миллионов записей). Делаю backup в формате plain text (хотя, пробовал потом и compressed, результат тот же). По умолчанию pg_backup формирует такой файл, при restore которого заполнение таблиц данными происходит при помощи COPY (а не INSERT).

Всё вроде бы нормально. Но! Когда я делаю restore этого бекапа происходит вот что: restore при обработке COPY этой большой таблицы постепенно сжирает всю память, и физическую, и виртуальную. В итоге – вываливается нафиг. И всё.

Я конечно понимаю, что допустим, мог бы создать своп побольше. Но это же не выход. А если бы таблица была ещё больше?

Ситуацию в итоге разрулил, отказавшись от бекапа с COPY, и применив бекап с INSERTами. Но такой restore ресторится сутки. То есть, очень долго.

Никто с такой фигнёй не сталкивался? Или, может, кто что подскажет? :)

Что стоит: Postgesql 8.2.6 на Centos 5.1 x86_64.
Дело было в январе. Тогда это был самый распоследний постгрес.
...
Рейтинг: 0 / 0
06.08.2008, 21:54
| Ответить | Цитировать | Написать  
RESTORE больших таблиц
    #35477435
konstantin~guest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
konstantin~guest
Гость
вообще не должно такого происходитъ. восстановление осуществляет psql и эта утилита память не жрет. Память кушает бакенд постгреса к которому конектится psql. Сколько памяти будет кушатъ бакенд посгреса и в каких случаях -- это определяет postgresql.conf.

я у себя посмотрел: во время восстановления базы ~10G ( COPY) бакенд занимает в примерно 500М. RHEL 4.6 x86_64, postgresql-8.1.11
...
Рейтинг: 0 / 0
08.08.2008, 00:24
| Ответить | Цитировать | Написать  
RESTORE больших таблиц
    #35480089
324f4
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
324f4
Гость
Совершенно верно, восстановление осуществляет psql, и память ест процесс постгреса, я это и имел в виду.

Сейчас ещё раз просмотрел доку по конфигурации сервера, и не нашёл, чтобы где-то задавалось количество памяти, которую будет кушать сервер. Подскажи, если знаешь, pls.

Единственное, что каким-то боком похоже, это настройка количества памяти, доступной процессу – параметр ОС, настраиваемый с помощью ulimit. Попробую ограничить, хотя, почему-то сомневаюсь, что поможет.

В принципе, и давно это было, и проблему, вроде бы, кое-как решил, но что-то здесь не то :-)
...
Рейтинг: 0 / 0
10.08.2008, 11:53
| Ответить | Цитировать | Написать  
RESTORE больших таблиц
    #35480136
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
324f4
Всё вроде бы нормально. Но! Когда я делаю restore этого бекапа происходит вот что: restore при обработке COPY этой большой таблицы постепенно сжирает всю память, и физическую, и виртуальную. В итоге – вываливается нафиг. И всё.

Интересен следующий вопрос: а бэкап/восстановление делается целиком всей базы
Код: plaintext
1.
2.
3.
4.
$ pg_dump -f foo.dump foo
...
$ createdb foo2
$ psql foo2 < foo.dump
или каким-то более хитрым потабличным образом? Причина вопроса: команда copy вызывает триггеры на таблице, и если их там много и разных, то память они загадить могут. Если же восстанавливается полный бэкап, то триггеры создаются уже после заливки данных и проблемы нету.
...
Рейтинг: 0 / 0
10.08.2008, 13:27
| Ответить | Цитировать | Написать  
RESTORE больших таблиц
    #35480418
Konstantin~
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Konstantin~
Участник
Sad Spirit кстати хороший вопрос. Т.е, вопрос к автору: создается-ли таблица заново или COPY/INSERT идет в стартую таблицу?

Даже не обязательно триггеры могут быть причиной, всякие CHECK constrains тоже могут "помочь". разница тут такая: COPY: одна транзакция, INSERT: много разных транзакций.


324f4 по поводу памяти с конфиге. там всего несколько параметров которые имеют значение, гляньте что у вас стоит в этих параметрах (см.ниже). Размер таблиц (без индексов) о которых удет речь у вас какой, 1-10 GB?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
shared_buffers 
work_mem 
maintenance_work_mem 
bgwriter_lru_maxpages
bgwriter_lru_percent
wal_buffers 
checkpoint_segments
...
Рейтинг: 0 / 0
11.08.2008, 01:45
| Ответить | Цитировать | Написать  
RESTORE больших таблиц
    #35480424
Konstantin~
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Konstantin~
Участник
PS: ulimit тут не поможет. бакенд постгреса просто зависнет при копировании или вообще упадет с ошибкой вроде ENOMEM 'cannot allocate'.

вообще гляньте на .sql файл из которого вы восстанавливаете. правильный порядок действий там должен быть такой:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
-- create table structure
CREATE TABLE ....

-- copy data into table
COPY ...
COPY ...
...

-- add pkeys, fkeys, indexes, constrains, triggers, etc
ALTER TABLE ... CREATE ....
...
Рейтинг: 0 / 0
11.08.2008, 02:02
| Ответить | Цитировать | Написать  
RESTORE больших таблиц
    #35482104
324f4
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
324f4
Гость
Sad Spirit

А ведь таки да! Хитрый потабличный бекап. И, действительно, сначала создаются триггеры, constraints и пр., а затем заливаются данные COPY. И хотя на "большую" таблицу триггеров нет, а есть только PK, FK и индексы, но мысль понятна. Спасибо.



Konstantin~

По поводу названных вами параметров – не менял, все по умолчанию. Да и порядок величин этих параметров никак не сравним с общим объёмом ОЗУ.

Размер большой таблицы, о которой идёт речь, без индексов около 7 ГБ.




Ещё раз, всем спасибо.
...
Рейтинг: 0 / 0
11.08.2008, 22:09
| Ответить | Цитировать | Написать  
7 сообщений из 7, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / RESTORE больших таблиц
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]