ERROR: out of memory

Добрый День

помогите разобраться...

пытаюсь ресторить такую вот табличку

CREATE TABLE awp_cards.idcard_idterm
(
idcard int4 NOT NULL,
idterm int4 NOT NULL,
datetimerec timestamp NOT NULL DEFAULT ('now'::text)::timestamp(6) without
time zone,
CONSTRAINT idcard_idterm_pkey PRIMARY KEY (idcard, idterm),
CONSTRAINT idcard_fkey FOREIGN KEY (idcard)
REFERENCES awp_books.idcard (idcard) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT idterm_fkey FOREIGN KEY (idterm)
REFERENCES awp_books.idterm (idterm) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITHOUT OIDS;

ресторю след. образом:

cat ./1732.dat | psql -h host -d Base -c 'COPY awp_cards.idcard_idterm
(idcard, idterm, datetimerec) FROM stdin;'

спустя некоторое время вываливается:

ERROR: out of memory
DETAIL: Failed on request of size 32.

файлик 1732.dat весит >1,5GB (>44M records)

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

еще попутно вопрос - начиная с некоторых пор (недавно, но уже стабильно) все
запросы тормозят, понимаю что накосячино, но непойму где ковырять... я так
понимаю проблема с разделяемой памятью и иже с ней, так как довольно много
таблиц перевалило за 10мега записей, и теперь посгресу тяжело... постоянно
роется в свопе. Выставлял shared_memory в 1.5G - не помогло... где еще надо
крутить?

система: FreeBSD 5.4-RELEASE-p22
СУБД: PostgreSQL 8.1.10
железка с 2GB оперативки и 20G свопа

sudo sysctl kern.ipc.
kern.ipc.maxsockbuf: 262144
kern.ipc.sockbuf_waste_factor: 8
kern.ipc.somaxconn: 128
kern.ipc.max_linkhdr: 16
kern.ipc.max_protohdr: 40
kern.ipc.max_hdr: 56
kern.ipc.max_datalen: 152
kern.ipc.nmbclusters: 25600
kern.ipc.piperesizeallowed: 1
kern.ipc.piperesizefail: 0
kern.ipc.pipeallocfail: 0
kern.ipc.pipefragretry: 0
kern.ipc.pipekva: 409600
kern.ipc.pipes: 44
kern.ipc.maxpipekva: 16777216
kern.ipc.msgseg: 2048
kern.ipc.msgssz: 8
kern.ipc.msgtql: 40
kern.ipc.msgmnb: 2048
kern.ipc.msgmni: 40
kern.ipc.msgmax: 16384
kern.ipc.semaem: 16384
kern.ipc.semvmx: 32767
kern.ipc.semusz: 332
kern.ipc.semume: 40
kern.ipc.semopm: 100
kern.ipc.semmsl: 240
kern.ipc.semmnu: 120
kern.ipc.semmns: 240
kern.ipc.semmni: 40
kern.ipc.semmap: 256
kern.ipc.shm_allow_removed: 0
kern.ipc.shm_use_phys: 0
kern.ipc.shmall: 549011456
kern.ipc.shmseg: 128
kern.ipc.shmmni: 192
kern.ipc.shmmin: 1
kern.ipc.shmmax: 549011456
kern.ipc.numopensockets: 164
kern.ipc.maxsockets: 25600
kern.ipc.nsfbufsused: 0
kern.ipc.nsfbufspeak: 2
kern.ipc.nsfbufs: 6656

из postgresql.conf

# RESOURCE USAGE (except WAL)
#---------------------------------------------------------------------------

# - Memory -

shared_buffers = 65536
work_mem = 20480

# - Free Space Map -

max_fsm_pages = 256000
max_fsm_relations = 8000

--
Malsaĝulon favoras feliĉo

On Wed, 31 Oct 2007, Alexander Kuprijanov wrote:

> Добрый День
>
> помогите разобраться...
>
> пытаюсь ресторить такую вот табличку
>
> CREATE TABLE awp_cards.idcard_idterm
> (
> idcard int4 NOT NULL,
> idterm int4 NOT NULL,
> datetimerec timestamp NOT NULL DEFAULT ('now'::text)::timestamp(6) without
> time zone,
> CONSTRAINT idcard_idterm_pkey PRIMARY KEY (idcard, idterm),
> CONSTRAINT idcard_fkey FOREIGN KEY (idcard)
> REFERENCES awp_books.idcard (idcard) MATCH SIMPLE
> ON UPDATE NO ACTION ON DELETE NO ACTION,
> CONSTRAINT idterm_fkey FOREIGN KEY (idterm)
> REFERENCES awp_books.idterm (idterm) MATCH SIMPLE
> ON UPDATE NO ACTION ON DELETE NO ACTION
> )
> WITHOUT OIDS;
>
> ресторю след. образом:
>
> cat ./1732.dat | psql -h host -d Base -c 'COPY awp_cards.idcard_idterm
> (idcard, idterm, datetimerec) FROM stdin;'
>
> спустя некоторое время вываливается:
>
> ERROR: out of memory
> DETAIL: Failed on request of size 32.
>
> файлик 1732.dat весит >1,5GB (>44M records)
>
> какие параметры крутить чтоб не вываливалось? где накосячил?

а попробуй убрать все проверки в таблице. Чего их проверять ?

>
>
> еще попутно вопрос - начиная с некоторых пор (недавно, но уже стабильно) все
> запросы тормозят, понимаю что накосячино, но непойму где ковырять... я так
> понимаю проблема с разделяемой памятью и иже с ней, так как довольно много
> таблиц перевалило за 10мега записей, и теперь посгресу тяжело... постоянно
> роется в свопе. Выставлял shared_memory в 1.5G - не помогло... где еще надо
> крутить?

это длинная история :) Для 2Gb памяти, больше 1Gb не рекомендую шаред память
ставить. Какая у тебя версия постгреса ? Судя по всему, довольно древняя

>
>
>
> система: FreeBSD 5.4-RELEASE-p22
> СУБД: PostgreSQL 8.1.10
> железка с 2GB оперативки и 20G свопа
>
> sudo sysctl kern.ipc.
> kern.ipc.maxsockbuf: 262144
> kern.ipc.sockbuf_waste_factor: 8
> kern.ipc.somaxconn: 128
> kern.ipc.max_linkhdr: 16
> kern.ipc.max_protohdr: 40
> kern.ipc.max_hdr: 56
> kern.ipc.max_datalen: 152
> kern.ipc.nmbclusters: 25600
> kern.ipc.piperesizeallowed: 1
> kern.ipc.piperesizefail: 0
> kern.ipc.pipeallocfail: 0
> kern.ipc.pipefragretry: 0
> kern.ipc.pipekva: 409600
> kern.ipc.pipes: 44
> kern.ipc.maxpipekva: 16777216
> kern.ipc.msgseg: 2048
> kern.ipc.msgssz: 8
> kern.ipc.msgtql: 40
> kern.ipc.msgmnb: 2048
> kern.ipc.msgmni: 40
> kern.ipc.msgmax: 16384
> kern.ipc.semaem: 16384
> kern.ipc.semvmx: 32767
> kern.ipc.semusz: 332
> kern.ipc.semume: 40
> kern.ipc.semopm: 100
> kern.ipc.semmsl: 240
> kern.ipc.semmnu: 120
> kern.ipc.semmns: 240
> kern.ipc.semmni: 40
> kern.ipc.semmap: 256
> kern.ipc.shm_allow_removed: 0
> kern.ipc.shm_use_phys: 0
> kern.ipc.shmall: 549011456
> kern.ipc.shmseg: 128
> kern.ipc.shmmni: 192
> kern.ipc.shmmin: 1
> kern.ipc.shmmax: 549011456
> kern.ipc.numopensockets: 164
> kern.ipc.maxsockets: 25600
> kern.ipc.nsfbufsused: 0
> kern.ipc.nsfbufspeak: 2
> kern.ipc.nsfbufs: 6656
>
>
> из postgresql.conf
>
> # RESOURCE USAGE (except WAL)
> #---------------------------------------------------------------------------
>
> # - Memory -
>
> shared_buffers = 65536
> work_mem = 20480
>
> # - Free Space Map -
>
> max_fsm_pages = 256000
> max_fsm_relations = 8000
>
>
>
>
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru)
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

Alexander Kuprijanov wrote:
> еще попутно вопрос - начиная с некоторых пор (недавно, но уже стабильно) все
> запросы тормозят, понимаю что накосячино, но непойму где ковырять... я так
> понимаю проблема с разделяемой памятью и иже с ней, так как довольно много
> таблиц перевалило за 10мега записей, и теперь посгресу тяжело... постоянно
> роется в свопе. Выставлял shared_memory в 1.5G - не помогло... где еще надо
> крутить?
Если роется именно в свопе, значит мало физической памяти для текущих
настроек, тогда буфера надо уменьшать.

Вообще, как Олег правильно заметил, дело это нетривиальное. Невозможно
дать правильных рекомендаций, не зная:
- конфигурацию железа (это не только память, там вроде диски ещё бывают
обычно)
- настройки ФС для раздела с базами постгреса и для раздела с логами
транзакций (желательно, чтобы это были разные физические диски)
- насколько часто обновляются данные и как - часто понемногу, или редко
большими кусками
- насколько эффективно оптимизированы запросы
- и т.д. и т.п. - очень много всего, так сразу и не вспомнить всего, на
что стоит обратить внимание.

Вот ссылка неплохая на тему куда смотреть для выявления тормозов:
http://www.powerpostgresql.com/PerfList/

> ERROR: out of memory
> DETAIL: Failed on request of size 32.
>
> файлик 1732.dat весит >1,5GB (>44M records)
>
> какие параметры крутить чтоб не вываливалось? где накосячил?
Я бы попробовал выключить все индексы и constraint'ы на время загрузки.
Не вредно разбить этот файл на несколько и скормить их по очереди.

Alexander Kuprijanov wrote:
> Добрый День
>
> помогите разобраться...
>
> пытаюсь ресторить такую вот табличку
>
> CREATE TABLE awp_cards.idcard_idterm
> (
> idcard int4 NOT NULL,
> idterm int4 NOT NULL,
> datetimerec timestamp NOT NULL DEFAULT ('now'::text)::timestamp(6) without
> time zone,
> CONSTRAINT idcard_idterm_pkey PRIMARY KEY (idcard, idterm),
> CONSTRAINT idcard_fkey FOREIGN KEY (idcard)
> REFERENCES awp_books.idcard (idcard) MATCH SIMPLE
> ON UPDATE NO ACTION ON DELETE NO ACTION,
> CONSTRAINT idterm_fkey FOREIGN KEY (idterm)
> REFERENCES awp_books.idterm (idterm) MATCH SIMPLE
> ON UPDATE NO ACTION ON DELETE NO ACTION
> )
> WITHOUT OIDS;
>
> ресторю след. образом:
>
> cat ./1732.dat | psql -h host -d Base -c 'COPY awp_cards.idcard_idterm
> (idcard, idterm, datetimerec) FROM stdin;'
>
> спустя некоторое время вываливается:
>
> ERROR: out of memory
> DETAIL: Failed on request of size 32.

Если есть возможность посмотреть stderr от PG при возникновении этой
ошибки - там должна быть статистика по использованию памяти, есть ли
возможность ее прислать?
В любом случае, скорее всего ошибка вызвана наличием FOREIGN KEY в
таблице, если их убрать на время копирования - проблема должна
исчезнуть.

>
> файлик 1732.dat весит >1,5GB (>44M records)
>
> какие параметры крутить чтоб не вываливалось? где накосячил?

>
>
> еще попутно вопрос - начиная с некоторых пор (недавно, но уже стабильно) все
> запросы тормозят, понимаю что накосячино, но непойму где ковырять... я так
> понимаю проблема с разделяемой памятью и иже с ней, так как довольно много
> таблиц перевалило за 10мега записей, и теперь посгресу тяжело... постоянно
> роется в свопе. Выставлял shared_memory в 1.5G - не помогло... где еще надо
> крутить?

Как часто делается vacuum для тормозящих таблиц?

Regards,
Alexey.

За ссылочку спасибо,

Проблему решил скармливанием файла по кускам... скоро придут новые серваки там
памяти на порядок больше, с ними и буду экспериментировать в плане
производительности..

а с этим чудо-железом незнаю что делать...
RAID-5 (5+1 на SATA)
% mount
/dev/amrd0s1a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local)
/dev/amrd0s1e on /tmp (ufs, local, soft-updates)
/dev/amrd0s1f on /usr (ufs, local, noatime, soft-updates)
/dev/amrd0s1d on /var (ufs, local, noatime, soft-updates)

PostgreSQL 8.1.10 из портов (с опцией O3)

запросы все довольно тяжелые:
периодическое добавление больших объемов
и постоянные юзерские селекты (сборка из большого числа табличек, некоторые из
которых гигабольшие...)

таблички все нормализованы (в пределах разумного), где надо добавлены ключи и
индексы...

пытался проапгрейдить базу, но на pg_restore ручки опустились (прождал 4 часа,
не увидел прогресса, и вернул все в обратный зад...)

помнится мне, Олег упоминал некую программулину, которая на уровне файлов
апгрейдит postgres...

а сабж, собственно, не только на insert встречается, но и на select всей
таблички (вне зависимости от того куда: на вывод или в другую табличку).
больше 6,5 гигазаписи из таблички (int4, int4, timestamp) не получить
(собственно, в рабочем порядке не требуется, но для админских целей было
надо...)

В сообщении от Thursday 01 November 2007 09:35:14 Andrey N. Oktyabrski
написал(а):
> Alexander Kuprijanov wrote:
> > еще попутно вопрос - начиная с некоторых пор (недавно, но уже стабильно)
> > все запросы тормозят, понимаю что накосячино, но непойму где ковырять...
> > я так понимаю проблема с разделяемой памятью и иже с ней, так как
> > довольно много таблиц перевалило за 10мега записей, и теперь посгресу
> > тяжело... постоянно роется в свопе. Выставлял shared_memory в 1.5G - не
> > помогло... где еще надо крутить?
>
> Если роется именно в свопе, значит мало физической памяти для текущих
> настроек, тогда буфера надо уменьшать.
>
> Вообще, как Олег правильно заметил, дело это нетривиальное. Невозможно
> дать правильных рекомендаций, не зная:
> - конфигурацию железа (это не только память, там вроде диски ещё бывают
> обычно)
> - настройки ФС для раздела с базами постгреса и для раздела с логами
> транзакций (желательно, чтобы это были разные физические диски)
> - насколько часто обновляются данные и как - часто понемногу, или редко
> большими кусками
> - насколько эффективно оптимизированы запросы
> - и т.д. и т.п. - очень много всего, так сразу и не вспомнить всего, на
> что стоит обратить внимание.
>
> Вот ссылка неплохая на тему куда смотреть для выявления тормозов:
> http://www.powerpostgresql.com/PerfList/
>
> > ERROR: out of memory
> > DETAIL: Failed on request of size 32.
> >
> > файлик 1732.dat весит >1,5GB (>44M records)
> >
> > какие параметры крутить чтоб не вываливалось? где накосячил?
>
> Я бы попробовал выключить все индексы и constraint'ы на время загрузки.
> Не вредно разбить этот файл на несколько и скормить их по очереди.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
Tajloro krimis, botisto pendas