Ошибка субд out of memory for query result 1с postgresql

Описание ошибки:
Платоформа 1С: Предприятие 8.3.16.1148. Клиент-серверный вариант работы базы на СУБД PostgreSQL. Ошибка втречалась при попытке выгрузить базу через «Администрирование» — «Выгрузить информационную базу…», т.е. при попытке выгрузить информационную базу в архив .dt.

Найденные решения:

Как было указано в кратком описании ошибки — база клиент-серверная на СУБД PostgreSQL. Логично, если перевести формулировку «out of memory for query result» — «недостаточно памяти для результата запроса». Так же само «Ошибка СУБД» отправляет решать проблему не на стороне 1С, а на сторону СУБД. Поэтому необходимо изменить параметры использования ресурсов сервера — естественно в сторону увеличения объема используемых ресурсов. В СУБД PostgreSQL это делается путем редактирования соответствующего файла «postgresql.conf», который по умолчанию находится (при установке с параметрами «по умолчанию») в «C:Program Files (x86)PostgreSQL9.4.2-1.1Cdata» для x32-версии и в «C:Program FilesPostgreSQL9.4.2-1.1Cdata» для x64-версии.

В этот статье нет смысла описывать актуальные параметры настроек файла конфигурации «postgresql.conf», в помощь по этому вопросу соответствующая исчерпывающая публикация на сайте профессионального сообщества infostart.ru:

Настройка PostgreSQL для работы в связке с 1С 8.х на ОС Windows

После изменения и сохранения параметров в «postgresql.conf». Необходимо перезапустить службу «PostgreSQL Database Server …» в «Службах» операционной системы Windows сервера, чтобы новые параметры вступили в силу.

Если все-таки не получилось изменить параметры использования ресурсов в файле конфигурации  СУБД «postgresql.conf» по каким-либо причинам, то попробуйте выполнить операцию, которая завершается ошибкой «Ошибка СУБД: out of memory for query result» не на самом сервере, а на одном из клиентских рабочих мест. Если не получится на одном, то попробуйте на другом — на практике так получалось обходить ошибку.

Оцените, помогло ли Вам предоставленное описание решения ошибки?

© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.

22-09-2020

Журавлев А.С.
(Сайт azhur-c.ru)

Расследование
возникшей ошибки нехватки памяти на
сервере 1С

Поступило
обращение со следующей
ошибкой:
«Неспецифицированная ошибка
работы с ресурсом
Ошибка при выполнении
запроса POST к ресурсу /e1cib/login:

Недостаточно
свободной памяти для выполнения
операции
Выполняется ожидание
возможности запуска.

При
появлении возможности, запуск будет
выполнен автоматически.

Нажмите «Выполнить запуск» для немедленной
попытки запуска.

Нажмите «Отмена» для отказа от запуска.»

Смотрим
журнал регистрации:

Настроив
ТЖ с событием EXCP, EXCPCNTX обнаруживаем
запись:

«Ошибка
СУБД out of memory for query result»

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

Находим
код конфигурации, вызывающий ошибку:

В
журнале регистрации указан следующий
код:

по
причине:

по
причине:

Недостаточно
памяти для получения результата запроса
к базе данных

Открываем
конфигуратор и переходим в указанный
модуль к указанному номеру строки кода:

Строка,
на которой произошла ошибка:

ВнешниеОбъектыХранилище
= Константы.ДокументооборотСКонтролирующимиОрганами_ВнешнийМодуль;

ДвоичныеДанныеОбработки
= ВнешниеОбъектыХранилище.Получить().Получить();

Смотрим
тип объекта (константы), к которой идет
обращение:

Итак,
в конфигурации есть константа
«ДокументооборотСКонтролирующимиОрганами_ВнешнийМодуль»,
которая хранит в базе что-то
неструктурированое (двоичные данные),
и это неструктурированное может занимать
значительный объем памяти.

Проверяем,
какой объем данных фактически занимает
константа.

Узнаем
имя таблицы хранения в базе PostgreSQL —
таблица «_Const10013», индекс «_Const10013_ByKey».

Узнаем
размер таблиц «Const10013», «_Const10013_ByKey» на
диске:

На
диске таблица занимает всего 4688 Кб = 4,6
Мб. Размер является незначительным,
причина не в константе.

Обнаруживаем,
что кластер 1С является 32-разрядным:

06.09.17 — 08:02

1 — 06.09.17 — 08:10

разрядность PostgreSql какая?

2 — 06.09.17 — 08:12

(1) 64 разрядная как и windows server

3 — 06.09.17 — 08:21

В логе вот что пишет:  

pg_authid_rolname_index: 1024 total in 1 blocks; 552 free (0 chunks); 472 used

  MdSmgr: 8192 total in 1 blocks; 6544 free (0 chunks); 1648 used

  LOCALLOCK hash: 8192 total in 1 blocks; 2880 free (0 chunks); 5312 used

  Timezones: 79320 total in 2 blocks; 5968 free (0 chunks); 73352 used

  ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used

2017-09-04 18:55:43 MSK ERROR:  out of memory

2017-09-04 18:55:43 MSK DETAIL:  Failed on request of size 536870912.

2017-09-04 18:55:43 MSK CONTEXT:  COPY config, line 328, column binarydata

2017-09-04 18:55:43 MSK STATEMENT:  COPY Config FROM STDIN BINARY

4 — 06.09.17 — 08:21

попробуй в  work_mem указать немного больше чем от тебя просят

5 — 06.09.17 — 08:22

ставил 256 и 512

6 — 06.09.17 — 08:22

и да, этот ДТ куда-то вообще загружается? Он точно не битый?

7 — 06.09.17 — 08:23

(5) переведи  «on request of size 536870912»

8 — 06.09.17 — 08:25

(6) Да как файловая база он загружается

9 — 06.09.17 — 08:27

(6) и точно не битый делал тестирование и исправление и chdbfl,без ошибок

10 — 06.09.17 — 08:30

(7)размер по запросу 536870912,полагаю что не хватает памяти загрузить какую то таблицу

11 — 06.09.17 — 08:31

а где её увеличить!?или может какой то другой параметр нужно увеличить

12 — 06.09.17 — 08:34

(11) 536 больше 512?

13 — 06.09.17 — 08:36

(12) я понял к чему ты,я пробовал и 1024 ставить

14 — 06.09.17 — 08:36

(12) но вот только не везде

15 — 06.09.17 — 08:39

Попробую work_mem выставить > 536 ,но смогу попробовать вечером

16 — 06.09.17 — 08:52

(15) сделай сразу побольше чтобы наверняка

17 — 06.09.17 — 09:07

(16) да 1024 поставлю,отпишусь по результату

18 — 06.09.17 — 09:20

и temp_buffers тоже.

19 — 06.09.17 — 09:30

shared_buffers рекомендуется делать побольше. 1/4 — 1/3 RAM.

maintenance_work_mem в 1/2 RAM или больше (до RAM-shared_buffers)

20 — 06.09.17 — 09:40

(19) если не ошибаюсь то пробовал я ставить и больше 1 gb в

shared_buffers или temp_buffers служба pg перестаёт запускаться

21 — 06.09.17 — 11:01

(16) Попробывал,выставить 1024 work_mem,shared_buffers,temp_buffers ошибка всё равно выходит

22 — 06.09.17 — 11:04

Увидел вот какой момент,в свойствах Pg есть строка версии где написано PostgreSQL 9.4.2,complited by Visual C++ build 1500, 32-bit

23 — 06.09.17 — 11:06

мне эта строка не нравится,типа используются компоненты Visual C++ 32 бита,посмотрел на давно созданном сервере тоже на pg там 64 стоит м.б дело в этом!?

24 — 06.09.17 — 11:26

Похоже что да,вроде как ура..грузит ,но ошибку не выкидывает

25 — 06.09.17 — 11:36

победа,парни дико извиняюсь,3 дня не в ту сторону смотрел,не тот дистрибутив поставил поставил общий,а надо было postgresql-9.4.2-1.1C_x64

26 — 06.09.17 — 11:49

(25) Теперь научился отличать приложения х64 от х86?

27 — 06.09.17 — 11:55

(12) они равны

(26) Да,я поставил не посмотрев,а в описании в pg и сервис написано 64 Bit,а вот когда увидел строку версии ,тогда меня смутило

1. 07.07.2015, 10:17

   
   

   #1

   

   
   Гость форума
   

   ---

   Ошибка СУБД: out of memory for query result
   

   Собственно говоря вылетает такая ошибка при попытке сохранения конфигурации, 1 раз сохраняет нормально а потом начинается ошибка вылетать, делаю стоп/старт сервер 1с и опять 1 раз сохраняет а потом ошибка, сервер 1с на вин2003сервер х32, сервер баз данных на постгри центос7_х64, что можно сделать, кто сталкивался и как решили?

   ---

2. 07.07.2015, 10:47

   
   

   #2

   

   
   Пришел за помощью
   

   ---

   
   

   Попробуйте обновить сервер на более свежую платформу и соответственно клиентскую часть, бывали ошибки в релизах.

   ---

3. 07.07.2015, 11:18

   
   

   #3

   

   
   Гость форума
   

   ---

   
   

   8.3.6.1977 вот эта версия, а не может быть из-за того что сервер 1с 32 битный, а сервер баз данных 64 битный?

   ---

4. 07.07.2015, 11:43

   
   

   #4

   

   
   Пришел за помощью
   

   ---

   
   

   Сообщение от Eugene87
   

   8.3.6.1977 вот эта версия, а не может быть из-за того что сервер 1с 32 битный, а сервер баз данных 64 битный?

   У меня данный релиз, проблем не замечалось подобных.
   А раньше данные проблемы наблюдали или новое поднимали?
   Если старое, то после чего стали появляться данные проблемы?

   ---

5. 07.07.2015, 12:13

   
   

   #5

   

   
   Гордость форума PRO
   

   ---

   
   

   сервер баз данных на постгри центос7_х64

   Проблема на стороне СУБД — однозначно.

   ---

6. 07.07.2015, 12:55

   
   

   #6

   

   
   Гость форума
   

   ---

   
   

   да раньше было на винде2003сервер стоял ibm db2 c, вроде работало, но сейчас и базы стали тяжелее..———- Post added at 15:55 ———- Previous post was at 15:53 ———-я тоже сначала так думал.. но проблема устраняется когда я делаю именно перезапуск сервера 1с, а сервер бд вообще по ресурсам не напрягается, что самое удивительное и рпхост 2 процесса по 600-800 мб весят и не поднимаются выше, а пишет аут оф мемори.. ничего не понимаю..

   ---

7. 07.07.2015, 13:12

   
   

   #7

   

   
   Гордость форума PRO
   

   ---

   
   

   но проблема устраняется когда я делаю именно перезапуск сервера 1с, а сервер бд вообще по ресурсам не напрягается

   Это ни о чем не говорит.

   Если например проблема с tempdb, то при перезапуске ты чистишь его (сервер 1С отваливается от сиквела и все «занятое» идёт в треш). Поэтому однозначно рыть в сторону СУБД, я бы начал бы с tempdb, хотя может и проблемы с лог или дата файлами.

   ---

8. 07.07.2015, 13:59

   
   

   #8

   

   
   Гость форума
   

   ---

   
   

   попробую 32 битную посгри поставить или еще есть идея ibm db2 express c поставить) в 10й версии увеличили ограничение озу до 4 гб

   ---

9. 07.07.2015, 14:03

   
   

   #9

   

   
   Гордость форума PRO
   

   ---

   
   

   или еще есть идея ibm db2 express

   Поставь мелкомягкий экспрес — там сейчас также 4 Гб

   ---

I have an AWS RDS PostgreSQL 12.3 (t3.small, 2CPU 2GB RAM). I have this table:

CREATE TABLE public.phones_infos
(
    phone_id integer NOT NULL DEFAULT nextval('phones_infos_phone_id_seq'::regclass),
    phone character varying(50) COLLATE pg_catalog."default" NOT NULL,
    company_id integer,
    phone_tested boolean DEFAULT false,
    imported_at timestamp with time zone NOT NULL,
    CONSTRAINT phones_infos_pkey PRIMARY KEY (phone_id),
    CONSTRAINT fk_phones_infos FOREIGN KEY (company_id)
        REFERENCES public.companies_infos (id) MATCH SIMPLE
        ON UPDATE NO ACTION
        ON DELETE CASCADE
)

There are exactly 137468 records in this table, using:

SELECT count(1) FROM phones_infos;

The ERROR: out of memory for query result occurs with this simple query when I use pgAdmin 4.6:

SELECT * FROM phones_infos;

I have tables with 5M+ records and never had this problem before.

EXPLAIN SELECT * FROM phones_infos;
Seq Scan on phones_infos  (cost=0.00..2546.68 rows=137468 width=33)

I read this article to see if I could find answers, but unfortunately as we can see on metrics: there are no old pending connections that could eat memory.

As suggested, the shared_buffers seems to be correctly sized:

SHOW shared_buffers;
449920kB

What should I try?