1с ошибка субд out of memory for query result 1с
Переводим БД с postgree на MS SQL.
При попытке выгрузить БД получаю ошибку Ошибка СУБД out of memory for query result.
Кто сталкивался подскажите варианты выгрузки.
Какой объем бд, железо, версии ПО?
PS Если просите помощи, прикладывайте как можно больше информации о проблеме. А то получается почти как "Ваша программа нам неправильно считает".
Тестирование и исправление базы пробовали делать?
А платформу 1С обновить не пробовали?
У нас на одной из версий платформы 8.2 такая же ошибка была с постгри
Как правильно обновить платформу?
Установил 8.2, сервер 8.2. - прописываю путь к бд - пишет БД не найдена.
Тии попробую.
(7)комп перегрузили после установки 8.2? В 8.2 новые базы создавать получается?
(9) опять же, комп перегрузили?
(10)у него не выгружается база из конфигуратора. Как он в файловую версию выгрузит то?
(11) alexbur,
Комп перезагрузил, новые бд создаются а эту не видит зараза.
Может у кого есть conf файл норм настроенный - поделитесь. все таки мне кажется проблема в нем.
Еще одну вещь заметил БД выгружается, но как только начинается операция сохранения в файл вываливается ошибка.
(13)Какой именно текст ошибки выдает при попытке выгрузки базы из postgre? на какую-нибудь таблицу ссылается?
У нас не выгружается типовая база УПП, ругается на таблицу public.config. Проблема решается отвязкой конфы от поддержки, но нас это решение не устраивает.
(14) alexbur,
через постгри выгружается без ошибок.
Но вот если потом загрузить в пустую базу(восстановить) - то база выдает разные ошибки и ни конфигуратор, ни клиент не грузятся..
(15) на всякий случай тормозните postgre и сохраните каталог в котором база храниться. Сделайте техобслуживание базы в pgadmin (analyze, vacuum, reindex) может выдаст какие-нибудь ошибки
Может быть уже имеет смысл думать о том, чтобы вытащить инфу другим путем? К примеру, создать пустую базу с такой же конфой и перетащить в неё данные с помощью обработки "Универсальный обмен данными черех XML". Не самый плохой путь, на мой взгляд.
(17) alexbur,
Это крайний вариант так как на этой бд у нас РИБ + обмены с сайтами(2 штуки)
Это все полетит в данном случае.
конф файл был стандартный - ошибка и на нем была, сейчас я уже влез в него прилично, но успехов пока нет. Все таки надеюсь что получится стандартными средствами выгрузку сделать.
А если я подниму эту же версию постгри на сервере и скопирую туда папку постгри - он увидит БД. Может на болле мощной машине получится выгрузить.
(22) kliman, не факт что слетит. Универсальный обмен данными в формате xml при загрузке формирует объекты БД с теми же уникальными идентификаторами что и в исходной БД. При повторной выгрузке/загрузке информация не дублируется, а "ложится" на нужные объекты.
РИБ использует тот же самый механизм при обмене. Скорее всего при первом обмене придётся перегрузить весь объём инфы, но, во всяком случае, я бы повел эксперимент.
(14) alexbur, дак снимай с поддержки - загрузи в СКУЛь - потом "загрузить конф. из файла", правда какие-нибудь аналитики могут пропасть.
(20) Мне это незачем, т.к. dt файл из конфигурации прекрасно выгружается. А если снять с поддержки и потом загрузить конфу из файла, то проблема выгрузки из postgre возвращается.
Так что пока обхожусь бэкапами из конфигуратора и подумываю о переходе на x64 postgre.
(19)дык я об это же говорил в (17). Кстати, а какого плана горе может возникнуть при проведении?
(13) Конф файл настраивается индивидуально под каждую конфигурацию - та ещё пляска с бубном.
Возможно имеет смысл наоборот попробовать выгрузить со стандартным конф файлом. Или он у вас изначально стандартный был?
в интернете нашел что у кого-то помогло установка значений
work_mem = 64MB
maintenance_work_mem = 256MB
проставил галочки в конф файле, перезапустил.
Если захожу в конф файл там в значение верное знач, а в текущем значение другие цифры.
Что за колонка текущее значение?
есть вариант с выгрузкой данных в идентичную конфигурацию(на ИТСе есть обработки), если получится в СКУЛе в чистой базе развернуть .cf, то переноси данные через обработки, только галочку "выгружать движения" поставь, иначе при проведении горя хапнешь.
Когда-то давно задавал вопрос на партнерском форуме 1С, а сейчас решил выложить в общий доступ.
Исходные данные:
Платформа: 1С:Предприятие 8.1 (8.1.15.14)
Кофигурация: БП 1.6.24.7 (Конфигурация типовая, на поддержке). Ситуация может воспроизвестись на любой конфигурации.
Сервер СУБД: Postgres 8.3.8 (сборка 1с)
ОС: Debian Lenny 5.0 (Linux 2.6.26-2-686-bigmem i686 GNU/Linux)
Физ: на сервере 8Гб памяти, параметры остального оборудования думаю не критичны.
Воспроизводимость 100%
При закрытии месяца вылетает с ошибкой: Ошибка СУБД. ERROR: Out of memory. DETAIL: Failed on request size 8388608
enable_mergejoin=off (в .conf файле или через SET в консоли/PgAdmin)
Проблема в оптимизаторе, который выбирает неудачный план(merge join), требующий большого объема памяти и большого времени для выполнения запроса.
«If the default plan chosen by the optimizer for a particular query is not optimal, a temporary solution can be found by using one of these configuration parameters to force the optimizer to choose a different plan. Turning one of these settings off permanently is seldom a good idea, however. «
Что такое mergejoin? Алгоритм соединения слиянием сортированных списков (merge join, sort merge join, sort-merge join) — разновидность алгоритма соединения. Алгоритм получает на вход 2 таблицы и условие соединения. Результатом его работы является таблица с результатами соединения. Главным недостатком алгоритма является необходимость в предварительной сортировке списков. Накладные расходы на сортировку могут быть неприемлемо высокими.
(26) Да, решить удалось на этих выходных. Перенес Постгри полностью на новый сервер(64 и и хороший по производительности) и на нем удалось произвести выгрузку в dt. Все таки дело в ресурсах. С постгри больше не работаю)
(28) перенес dump, каталоги не получилось перенести. Загрузить дамп получилось(архив не меняли) раза с 5, до этого сыпались какие-то ошибки. причем каждый раз разные.
Спешу поделиться решением проблемы. Недавно перевел 1с из файлового варианта в SQL, при этом решил использовать PostgreSQL. По началу, при попытки выгрузить базу в .dt файл, вылетала ошибка "Соединение разорвано и чего-то там еще. ". Платформа 1с была 8.2.19.68, в тех. поддержке посоветовали поставить более старую версию (установил 8.2.18.61), ошибка исчезла, но появилась другая "Ошибка СУБД out of memory for query result". Перекопал весь интернет, пробовал различные советы, но ничего не помогало. Исходя из текста ошибки, я понял что программе не хватает памяти, но вот только какой?! На сервере стоит Win2008srv c 8Гб оперативной памяти (вроде должно хватать), но вот в настройках Windows виртуальная память выбирается автоматом, при этом если у вас два раздела (C и D), то на диске D файл подкачки отключен по умолчанию. А так как у меня все базы находятся на диске D, и размер базы 1с составляет порядка 1,5 Гб, то для того чтобы её выгрузить в файл .dt необходимо было включить использование файла подкачки с параметром "по выбору системы" и будет вам счастье.
Спешу поделиться решением проблемы. Недавно перевел 1с из файлового варианта в SQL, при этом решил использовать PostgreSQL. По началу, при попытки выгрузить базу в .dt файл, вылетала ошибка "Соединение разорвано и чего-то там еще. ". Платформа 1с была 8.2.19.68, в тех. поддержке посоветовали поставить более старую версию (установил 8.2.18.61), ошибка исчезла, но появилась другая "Ошибка СУБД out of memory for query result". Перекопал весь интернет, пробовал различные советы, но ничего не помогало. Исходя из текста ошибки, я понял что программе не хватает памяти, но вот только какой?! На сервере стоит Win2008srv c 8Гб оперативной памяти (вроде должно хватать), но вот в настройках Windows виртуальная память выбирается автоматом, при этом если у вас два раздела (C и D), то на диске D файл подкачки отключен по умолчанию. А так как у меня все базы находятся на диске D, и размер базы 1с составляет порядка 1,5 Гб, то для того чтобы её выгрузить в файл .dt необходимо было включить использование файла подкачки с параметром "по выбору системы" и будет вам счастье.
(31)Спасибо совет помог. Но есть еще одна проблемка на другой машине. При выгрузке dt ошибка субд server closed connection unexpectedly
This problems means the server terminated abnormally before or while processing the request.
Такая же ерунда. Ничего не помогло :( Сделал дамп из PG. На локальной машине с Виндой развернул 1с сервер и PG, дамп закинул туда и через конфигуратор выгрузил ИБ.
(34) Ну вот не факт что поможет.
На текущий момент имею тестовую виртуалку под CentOS 7 + PostgresPRO 9.6 + 1C sever x32 - 8.3.10.2580
База УТ 10.3, вес в слоне 22Gb. В виртуалке 8Gb памяти, 2cpu по 6core.
При попытке выгрузить в dt выпадает с ошибкой Out of memory. Хотя память в виртуалке отъедалась максимум в районе половины.
Благо это все эксперименты и можно поиграться. Все что выше советовалось - не помогает. Пока играюсь и смотрю.
Плюс заметил глюк этой версии платформы под CentOS:
Грузил dt этой базы (9,3Гб). Толстым клиентом подсоединялся к 1С серверу на этой виртуалке. И начинаю загрузку. По поведению системы вижу, что dt туда перекачался, и пошла закачка базы в postgres. После заливки примерно 1,3Gb конфигуратор выдает ошибку, что (кратко): "Не все данные загружены. Ошибка формата потока."
Тесты, настройки, чпоки, эксперименты с настройками Postgres и 1С сервер на этой машине ничего не дали.
Делаю следующее: У себя на виндовой машине поднимаю туже версию 1С сервера (и тоже х32), создаю тестовую базу и в качестве СУБД указываю тот же Postgres в той тестовой виртуалке. Заливаю dt и вулая! База залилась без ошибок!
Т.е. есть какой-то глюк в платформе.
Вот в качестве эксперимента по той же схеме запустил выгрузку dt. В итоге в CentOS занято чуть меньше 1,7Гб. По активности сети вижу, что база интенсивно льется на мой компьютер через 1С сервер на моем компьютере. Ошибки пока не выпадало. Будем посмотреть.
UPD: Тоже упало с ошибкой out of memory. Хотя памяти при этом на сервер до опы свободной.
Ну собственно, потыкавшись и помыкавшись, посмотрев за памятью, пришел к выводу, что PostgreSQL тут как бы не причем.
rphost давится. 32-битный процесс доходит до своего предела в 3,5 гига озу и все. после этого резкое высвобождение памяти и в последующем нелюбимая ошибка Out of memory.
Установа х64 1C сервера и последующая повторная выгрузка прошли без проблем.
В процессе наблюдения за поведением x64 rphost, было видно, что потребление памяти процессом доходило до 4,5 Гигабайт. Причем несколько раз.
Интересно, почему та же база, на х32 1C сервере в сочетании с MSSQL не дает такого эффекта?
А вот c PostgreSQL такое наблюдаю постоянно?
Тоже была такая проблема. Мне помог перезапуск службы сервера 1С. Но на огромных базах такое решение скорее всего не поможет, но почему бы не попробовать?
В настройках 1С сервера 32х Свойства рабочего сервера - количество ИБ на процесс. Было 8, сделал 1. Помогло без перезапуска 1С сервера и постгри.
Была точно такая проблема, ничего не помогло из того что тут написано.
Но помогло вот что: в postgresql.conf параметр shared_buffers снизил в разы.
Перевожу клиента на клиент-серверный вариант работы 1С. В целях попытаться сэкономить на лицензиях в качестве движка БД выбрали (пробуем) PostgresQL.
Конфигурация:
Сервер 32G RAM, Intel Core i7-6700, 3.4Ghz
Windows Server 2012 x64
SSD RAID 256 Гб
1С-server 32бита
postgresql-9.4.2-1.1C(x64) - (дистрибутив скачан с сайта ИТС)
Базы: основная УТ 11 (11.2.3.185) с обменами в бухгалтерии (16! баз) с использованием универсального формата.
Базы перевожу постепенно, чтобы поймать все костыли на "тестовой" эксплуатации.
К производительности проблем нет, всё "летает", но при выполнении некоторых отчетов (произвольных) как в УТ, так и в бухгалтериях вылетает ошибка:
Ошибка СУБД: out of memory for query result.
По результатам опроса интернета, настройки постгрес, помимо стандартных, выставлены следующие:
shared_buffers = 8GB
temp_buffers = 256MB
work_mem = 256MB
fsync = on
enable_mergejoin = off
effective_cache_size = 8GB
autovacuum = on
autovacuum_naptime = 10min
Но ошибка всё равно периодически воспроизводится (на прошлой неделе словили 1 раз). Пока решаю перезапуском сервера 1С и Postgres при случае инцидента, ошибка уходит.
Нагрузка относительно не большая. В УТ в пике 10-13 пользователей, в бухгалтерских базах по 1-2 пользователей (пока на клиент-серверный варинт переведены 4 бухгалтерских базы из 16). rphost съедает максимум 2,5-3,5 ГБ. Процессы постгреса по 50-100 мб. От общего объема оперативки максимум используется 30% с учетом процессов пользователей.
Подскажите, в чем может быть дело, каких параметров не хватает, куда вообще смотреть?
(9) Нет.
Это СУБД такая заботливая, сообщает что ее клиенту(т.е. серверу приложений 1С) не хватает памяти для получения результатов запроса.
Представитель сообщества разработчиков PostgreSQL так и пишет :
"Process memory allowed to the client; this is not a server-side error."
(13) неуместное предложение. Пользователи не будут особо вариантов предлагать, когда у них при наборе больших документов программа будет периодически вылетать. С каждым новым вылетом атмосфера будет накаляться. Это в общем случае. На следующей работе уже будете аккуратнее перезагружать сервер.
Конкретно в этом случае проблема в 32-битном сервере 1С. Если почитать mailing list постгри, то можно найти такую же ошибку, но только не связанную с 1С. Возникает эта ошибка тогда, когда приложение, запросившее данные из СУБД не может физически их получить, ибо упирается в ограничение по памяти.
Дальше смотрим ограничения по памяти. Опять-таки не 1С, а в целом. 2 гига для 32-разрядного приложения в 32-битной системе и 3,5 гига для 32-разрядного приложения в 64-битной системе. Цифры приблизительные, но суть понятна. Отсюда и наблюдения, что rphost больше 3.5 не отъедает. Он падает. Точнее не падает, а не может получить и отказывается, а постгря выдает ошибку.
А теперь почему помогает перезагрузка. Предположим объем данных из СУБД весит 1гб. Сервер только что после запуска, в него еще никто не зашел и rphost весит 500мб. Запрос отлично проходит, rphost начинает весить 1.5 гига. Другая ситуация - rphost запущен давно, пользователи работают, и rphost съел 3гб ОЗУ. И тут еще запрос на 1гб. Ошибка.
Описание ошибки:
Платоформа 1С: Предприятие 8.3.16.1148. Клиент-серверный вариант работы базы на СУБД PostgreSQL. Ошибка втречалась при попытке выгрузить базу через "Администрирование" - "Выгрузить информационную базу. ", т.е. при попытке выгрузить информационную базу в архив .dt.
Как было указано в кратком описании ошибки - база клиент-серверная на СУБД PostgreSQL. Логично, если перевести формулировку "out of memory for query result" - "недостаточно памяти для результата запроса". Так же само "Ошибка СУБД" отправляет решать проблему не на стороне 1С, а на сторону СУБД. Поэтому необходимо изменить параметры использования ресурсов сервера - естественно в сторону увеличения объема используемых ресурсов. В СУБД PostgreSQL это делается путем редактирования соответствующего файла "postgresql.conf", который по умолчанию находится (при установке с параметрами "по умолчанию") в "C:\Program Files (x86)\PostgreSQL\9.4.2-1.1C\data" для x32-версии и в "C:\Program Files\PostgreSQL\9.4.2-1.1C\data\" для x64-версии.
После изменения и сохранения параметров в "postgresql.conf". Необходимо перезапустить службу "PostgreSQL Database Server . " в "Службах" операционной системы Windows сервера, чтобы новые параметры вступили в силу.
Если все-таки не получилось изменить параметры использования ресурсов в файле конфигурации СУБД "postgresql.conf" по каким-либо причинам, то попробуйте выполнить операцию, которая завершается ошибкой " Ошибка СУБД: out of memory for query result " не на самом сервере, а на одном из клиентских рабочих мест. Если не получится на одном, то попробуйте на другом - на практике так получалось обходить ошибку.
Ошибка системы «1С: Предприятие 8.3» из-за нехватки памяти — постоянный спутник администратора 1С. Разбираемся, из-за чего они возникают, и рассматриваем пример диагностики одного подобного эпизода из практики администрирования сервера 1С.
Природа проблемы
Проблема может заключаться в несвоевременном завершении процессов, запускаемых различным ПО. Они накапливаются и перегружают доступный объём памяти на сервере. Также может иметь место интенсивная работа различных программ с постоянным резервированием и освобождением ресурсов памяти.
Приведу пример расследования одной подобной ошибки из своей практики.
Инцидент
Поступило обращение со следующей ошибкой:
Смотрим журнал регистрации, там так же выводится ошибка с пояснением о нехватке памяти на сервере:
Настроив технологический журнал (ТЖ) системы 1С с событием EXCP — EXCPCNTX обнаруживаем запись:
Ошибка СУБД out of memory for query result
То есть, обе ошибки сообщают о проблеме объёма памяти, на основании чего нашим главным подозреваемым становится код конфигурации (возможно наличие неоптимальных запросов).
Находим код конфигурации, вызывающий ошибку.
В журнале регистрации указан следующий код:
Открываем конфигуратор и переходим в указанный модуль к указанному номеру строки кода:
Строка, на которой произошла ошибка:
Смотрим тип объекта (константы), к которой идёт обращение:
Итак, в конфигурации есть константа:
Она хранит в базе что-то неструктурированное (двоичные данные), что может занимать значительный объём памяти.
Проверяем, какой объем данных фактически занимает константа. Для этого узнаем имя таблицы хранения в базе PostgreSQL — таблица «_Const10013», индекс «_Const10013_ByKey».
Узнаем размер таблиц «Const10013», «_Const10013_ByKey» на диске:
На диске таблица занимает всего 4688 Кб = 4,6 Мб. Размер является незначительным, значит, причина не в константе.
Обнаруживаем, что кластер 1С является 32-разрядным:
32-разрядный кластер 1С имеет ограничение примерно в 3.8 Гб, при достижении которого происходит падение процесса. В режиме отсутствия нагрузки rphost занял 3,2 Гб, что близко к порогу падения. Подобные инциденты будут происходить в любой момент времени.
Внесены изменения:
- В кластере серверов 1С «Интервал превышения допустимого объёма памяти процессов» = 300. Настройка не избавляет от ошибки, но необходима для снижения частоты возникновения ошибки.
- В планировщике Windows настроен перезапуск службы 1С; такими образом освобождается виртуальное адресное пространство в памяти, создаётся новый рабочий процесс.
Настройка также не гарантирует от ошибки, но снижает вероятность её возникновения.
Для предотвращения повторной ошибки следует:
- Сменить 32-разрядный кластер серверов 1С на 64-разрядный.
- Так как на сервере используется 14 ядер процессора, необходимо осуществить переход на платформенные лицензии 1С КОРП для снятия ограничений по настройкам и обеспечения возможностей для гибкой настройки распределения памяти сервера.
Другие варианты
Зачастую, особенно в ситуации, когда нужно срочно вернуть систему в работоспособное состояние при возникновении подобной ошибки, можно попробовать такие «дедовские» способы, как перезагрузка сервера 1С или перезапуск рабочих процессов 1С, что приведёт к уменьшению объёма используемой памяти.
Источником проблемы также может быть недостаток пространства на жестком диске сервера. Здесь решение будет зависеть от устройство сервера или кластера, но здесь также могут помочь и перезапуск сервера, и наращивание ёмкости диска (или освобождение существующего пространства), а также оптимизация запросов или обновление версии ПО системы.
Поступило обращение со следующей ошибкой:
"Неспецифицированная ошибка работы с ресурсом
Ошибка при выполнении запроса POST к ресурсу /e1cib/login:
Обе ошибки сообщают о проблеме объема памяти, на основании которых подозреваемым становится код конфигурации (возможно наличие неоптимальных запросов).
Итак, в конфигурации есть константа «ДокументооборотСКонтролирующимиОрганами_ВнешнийМодуль», которая хранит в базе что-то неструктурированое (двоичные данные), и это неструктурированное может занимать значительный объем памяти.
На диске таблица занимает всего 4688 Кб = 4,6 Мб. Размер является незначительным, причина не в константе.
32-разрядный кластер 1С имеет ограничение, примерно, 3.8 Гб, по достижении которого происходит падение процесса, службы.
- в кластере серверов 1С «Интервал превышения допустимого объема памяти процессов» = 300. Настройка не избавляет от ошибки, но необходима для снижения частоты возникновения ошибки.
- в планировщике Windows настроен перезапуск службы 1С; такими образом освобождается виртуальное адресное пространство в памяти, создается новый рабочий процесс. Настройка тоже не гарантирует исключение ошибки, но снижает вероятность ее возникновения.
- осуществить переход на платформенные лицензии КОРП для снятия ограничений по настройкам, возможности гибкой настройки распределения памяти сервера.
Так как на сервере используется 14 ядер процессора, то необходим переход на платформенные лицензии КОРП.
Читайте также: