Пользуясь базами данных любой программы 1С, сотрудники предприятий и организаций часто сталкиваются с непредвиденными ситуациями. Пожалуй, одна из самых частых — когда работа программы внезапно завершается по причине того, что администратор разорвал контакт с сервером.
В данном случае Microsoft OLE DB Provider for SQL Server выдаёт такую информацию: «Неопознанная ошибка hresult 80004005». При этом главным признаком проблемы является невозможность выгрузить информацию в базу.
Следует отметить, что ошибки, содержащие именно код 80004005, встречаются постоянно. У них есть особая классификация, которую при желании можно найти в соответствующей литературе.
Для начала нужно провести проверку конфигурации. Там может содержаться мусор (иными, словами, информация, которая является некорректной). Необходимо проверить конфигурацию с помощью соответствующей команды. Вы увидите флажок, предназначенный для того, чтобы проверить её логическую целостность. Если имеются проблемы, пользователь будет уведомлен об этом с помощью сообщения.
Данные, являющиеся неверными, система удалит в автоматическом режиме, но для этого нужно дать ей доступ, чтобы она изменила главный объект. К примеру, если вы работаете в облачном хранилище, его надо просто захватить.
Поддержка конфигурации требует её проверки и у поставщиков. С этой целью:
- нужно сохранить данные о конфигурации поставщиков. Для этого используйте CF-файл;
- теперь необходимо провести загрузку файла в обновлённую базу;
- выполните операцию, которая описана в п.1.
При получении сообщения об исправлении ошибки имейте в виду то, что конфигурация, имеющаяся у поставщика, содержала неправильные данные. Если такое произошло, снимите свою конфигурацию с поддержки и установите её снова. При этом её надо объединить с новой (от поставщика).
Сейчас уже любой релиз, который выпускает 1С, не имеет таких сложностей.
Сопутствующая проблема и методы её решения
С ситуацией, описанной ранее, тесно связана ещё одна, происходящая параллельно. Выглядит она так: 10007066.
Суть проблемы: когда используется СУБД MS SQL SERVER, во время записи объекта из базы с несколькими колонками (например, «Значения» и «Хранилища»), часто случается другой тип ошибки.
Выглядит она таким образом:
Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005.
Когда происходит ошибка 1с hresult clr 80004005, программа завершает свою работу в аварийном режиме.
Если вы ознакомитесь во время загрузки программы со специальным журналом (речь идёт о технологическом журнале), там есть табличка, содержащая информацию об этих хранилищах.
С помощью средств MS SQL Server Query Analizer нужно найти в табличке несколько колонок image и сделать для каждой следующий запрос
select top 10 DATALENGTH(_Fld4044 from _InfoReg4038 order by DATALENGTH(_Fld4044) desc
При этом, со стороны стандартных проверок, проводимых платформой (chdbfl), поступит информация о том, что база полностью в порядке.
Ошибка выделения памяти hresult 80004005 (на английском это out of memory for query result 1с) может происходить вследствие различных причин, имеющей общую черту. Для системы 1С это, прежде всего, недостаток оперативной памяти. Если говорить точнее, речь идёт о некорректном применении возможностей памяти, поэтому для решения задачи лучше использовать несколько косвенных алгоритмов.
Необходимо сделать рестарт (перезапуск) сервера. Таким образом памяти, которая доступна для работы, временно станет больше. Также есть возможность воспользоваться сервером в 64 разряда, содержащем приложения.
Исходя из опыта, ошибка СУБД hresult 80004005 чаще определяется двумя факторами:
- данные хранятся в хранилище значений (реквизите);
- в таблице конфигураций содержатся двоичные данные объёмом более 120 мегабайт.
Когда советы от сотрудников 1С не приносят результата (ошибка 1с hresult 80004005 остаётся), попробуйте воспользоваться другой пошаговой инструкцией:
Наши постоянные клиенты по 1С:
- используйте все базы, включив у них все фоновые задачи;
- в 8.1.11. должен появиться переключатель о запрете на фоновые задачи (во время создания базы);
- сделайте перезапуск сервера.
Имеет смысл проверки работоспособности. Тем не менее вследствие утечек памяти проблема может возникнуть снова — после перезапуска. В этом случае целесообразно:
- воспользоваться инструментами sql и сделать бэкап;
- снять базу с поддержки;
- выгрузить cf.
Во время любых действий следует копировать файлы в резерв, так как в любой момент может возникнуть необходимость возвращения к исходному статусу информации. Далее надо убрать в менеджменте консоли (config) запись «более 120 мегабайт» и провести загрузку конфигурации (не объединять, а загрузить).
Есть ещё один способ, с помощью которого неопознанная ошибка субд hresult 80004005 может быть исправлена. Нужно открыть конфигуратор и снять конфигурацию, не сохраняя её. Далее, сохранив, нужно поместить её в отдельный файл без сохранения её изменённого вида.
Выполните в SQL операцию, предназначенную для конкретной базы:
DELETE FROM dbo.Config WHERE DataSize > 125829120
После выполнения этой команды проведите загрузку сохранённой конфигурации.
Что касается радикальных шагов, используемых в особо трудных ситуациях, иногда помогает такая схема:
- удалите таблицу config из базы данных, воспользовавшись менеджментом консоли DROP TABLE [dbo].[Config];
- проведите загрузку конфигурации (не «объединить»,а именно «загрузить»).
После проведения проверки проблема должна уйти.
- Стоимость работ специалистов IT Rush — 2000 руб./час
- Абонемент от 50 часов в месяц – 1900 руб./час
- Абонемент от 100 часов в месяц – 1800 руб./час
Нам доверяют:
При выгрузке *.dt файла через конфигуратор, в некоторых случаях вам может выдать система ошибку “Недостаточно памяти”>. Достаточно будет запустить базу с разрядностью x64.
х32 и х64- обозначают архитектуру процессора, соответственно чем выше разрядность тем больше оперативной памяти может использовать операционная система, часто х32 указывают как x86. Это значит что x64 более новая архитектура и имеет 64 битную разрядность, и приложения запускаемые с этой разрядностью будут работать быстрее чем с x86 так как эта архитектура имеет всего лишь 32 битную разрядность.
Запустить Конфигуратор с разрядностью x64 очень просто:
-
Запускаем линк 42, удаленный рабочий стол
-
И уже с удаленного рабочего стола запускаем снова линк 42, выбираем нужную нам базу
-
На панели нажимаем Настройка, в графе Разрядность выбираем x64
Если все же ошибка не уйдет, вы можете обратиться в нашу тех. поддержку
Уже более 10 000 компаний работают
в облачной 1С от 42Clouds
— Консультация по 1С Бесплатно!
— Поддержка 24/7 по техническим вопросам: в чате, по телефону, по почте
— Все типовые конфигурации онлайн, доступ через RDP, Remote App, Web
frazer
30.01.13
✎
12:13
Добрый день. Необходимо перенести документы с движениями из одной базы Бух 2.0 в другую, её копию, в которой эти же документы с неправильными проводками. Сделали правила, пытаемся выгрузить документы. Выгрузка длилась примерно сутки, после этого программа радостно выдала «Недостаточно памяти». База файловая, занимает около 2 Гб, на момент возникновения ошибки xml-файл с выгруженными документами занимает около 4 Гб. Ранее документы пытались уже выгрузить и результат тот ж — «Недостаточно памяти», хотя в компе оперативной памяти 20 Гб. Причем ошибка выскочила, когда xml-файл достиг точно такого же размера, как и во второй раз. Из-за чего это происходит и что можно сделать ?
Надсмотрщик
30.01.13
✎
12:14
(0) выгружай по частям (по 10…15 дней)
Надсмотрщик
30.01.13
✎
12:15
+ (1) или по месяцу
kosts
30.01.13
✎
12:17
У меня в файловой вылетает при добавлении за один раз более 100 тыс записей в регистр, и в некоторых других местах.
В серверной похожих вылетов не наблюдалось…
JustBeFree
30.01.13
✎
12:19
Самый простой способ — выгрузка данных частями.
Godofsin
30.01.13
✎
12:23
(0) Насколько мне помнится,у 1с лимит — 4гб. Потому (1)
frazer
30.01.13
✎
12:43
(1), (2), (4). Тут такое дело. когда выгружаешь документы с движениями за определенный период с движениями выгружаются ещё и документы за период, предшествующий выгружаемому, на которые в документах выгружаемого периода имеются ссылки. Поэтому при выгрузки частями данные за ранее выгруженный период изменяются
Godofsin
30.01.13
✎
12:47
(6) «данные за ранее выгруженный период изменяются»
Чо это вдруг?
Надсмотрщик
30.01.13
✎
12:55
(6) Правила кривые
frazer
30.01.13
✎
13:11
(7) Немного не так написал. Не «за ранее выгруженный период», а за период, который есть в базу и менять там проводки не нужно. Т.е. загружаем документы в не пустую базу, документы загружаем с движениями. И вот при такой загрузке меняются проводки в документах в периоде, который предшествует периоду загрузки
Живой Ископаемый
30.01.13
✎
13:15
2(5) лимит чего?и в какой ОС?
Надсмотрщик
30.01.13
✎
13:16
(9) Кривые бушки ручками корректировали проводки — занимались химией.
frazer
30.01.13
✎
13:22
(11) Да и теперь у нас есть 2 базы, где в одной один период правильный, а в другой — другой период правильный и надо из букв «Ж», «О», «П», «А» составить слово «счастье» — загрузить из одной базы документы в лругую, чтоб отчетность можно было сделать
neckto
30.01.13
✎
13:28
(0) Чем выгружаешь?
Ошибка «На сервере недостаточно памяти для выполнения задания» |
Я |
20.01.22 — 15:17
Добрый день!
Выполняю регламентное задание синхронизации бухгалтерии 3.0 и ERP 2.5. Выгружаю документы за месяц. Итого к выгрузке 15000-30000 объектов. Думаю, что это не такие уж большие цифры. Ничего не выгружается. Выходит ошибка выполнения фонового задания «На сервере недостаточно памяти для выполнения задания». Ресурсов на сервере достаточно. ОЗУ 48 Гб, на дисках места предостаточно.
Платформа 8.3.20.1674, БП 3.0.106.40, ERP 2.5.7.308. Сервер 1С 64-рязрядый. При установке 1С особых настроек не делали в локальном кластере, рабочем сервере и рабочем процессе. Все по умолчанию.
Как устранить данную ошибку?
Заранее спасибо!
1 — 20.01.22 — 15:19
(0) «Как устранить данную ошибку?» С меньшим объемом данных ошибки такой не было? Если нет, то можно попакетно это дело грузить, только не забывать освобождать память, после каждой выгрузки
2 — 20.01.22 — 15:20
Чисто теоретически: вся память под SQL и свободной нет
3 — 20.01.22 — 15:34
Может еще разваливаться на передаче параметров в фоновое. Там есть ограничение на общий размер параметров.
4 — 20.01.22 — 15:42
(0)
Вариантов решения много:
экстенсивные:
Увеличить объем озу,
уменьшить размер пакета (выгружать по дням, неделям, декадам),
уменьшить фрагментацию озу
интенсивные:
переписать код обмена.
5 — 20.01.22 — 15:43
Сервер проф или корп?
6 — 20.01.22 — 17:05
(5) КОРП
7 — 20.01.22 — 17:06
(1) Если грузить данные только за 5 дней, а не за месяц, то такой ошибки нет.
8 — 20.01.22 — 17:09
посмотреть настройки скуля, там ему наверно всю память сервака отдали или ограничили?
9 — 20.01.22 — 17:11
(7) Вот и грузи за 5 дней
10 — 20.01.22 — 17:13
(8) База Postgre находится на другом сервере.
11 — 20.01.22 — 17:15
(9) 5 дней 7500 объектов грузил весь рабочий день — 8 часов. Это так и должно быть?
12 — 20.01.22 — 17:15
(0) У вас ИТС есть? Почему ты на форум пишешь вместо того чтобы своего фра и НБГ напрячь багой в тиражных решениях?
13 — 20.01.22 — 17:15
(10) Ну так и событие не на клиенте
14 — 20.01.22 — 17:19
(13) Не на клиенте. Полагаю серверу 1С памяти не хватает. Не Postgre.
15 — 20.01.22 — 17:21
Ну таки да, я бы сервер 1С перезапустил, может и хватит памяти
16 — 20.01.22 — 17:25
(12) Получается это баг?
17 — 20.01.22 — 17:26
(15) Хорошая мысль. Мешает работа пользователей только.
18 — 20.01.22 — 17:26
как-то тестили подобное на предмет: «ну какого хрена так долго», когда ОП полгига.
в общем, если есть время, то следуйте по простым шагам. писали-звонили, но если воз и ныне там и тянет только приличный объем ОП, то грусть.
1. Платформа(на 2020.12): 8.3.17.1851
2. Конфигурация(на 2020.12) : Управление торговлей, редакция 11 (11.4.13.85), Клиент-Сервер. В ЕРП, вероятно, та же шляпа.
3. Предмет анализа возможной ошибки: метод общего модуля ДоходыИРасходыСервер.РаспределениеРасходовНаСебестоимостьТоваров(ДокументСсылка)
4. Места в коде указанной конфигурации где метод определен и вызывается:
Основная конфигурация ОбщийМодуль.ДоходыИРасходыСервер.Модуль(622, 9) Функция РаспределениеРасходовНаСебестоимостьТоваров(ДокументСсылка) Экспорт
Основная конфигурация ОбщийМодуль.МенеджерОбменаЧерезУниверсальныйФормат.Модуль(19170, 48) РасшифровкаДопРасходов = ДоходыИРасходыСервер.РаспределениеРасходовНаСебестоимостьТоваров(ДанныеИБ.Ссылка);
Основная конфигурация ОбщийМодуль.МенеджерОбменаЧерезУниверсальныйФормат.Модуль(54172, 48) РасшифровкаДопРасходов = ДоходыИРасходыСервер.РаспределениеРасходовНаСебестоимостьТоваров(ДанныеИБ.Ссылка);
5. Описание возможной ошибки: на указанной конфигурации рассматриваемая функция ДоходыИРасходыСервер.РаспределениеРасходовНаСебестоимостьТоваров(ДокументСсылка)
вызывается при обменах и приводит к длительному выполнению обменов.
6. Способ воспроизведения ошибки: Непосредственно при обмене тестировать не очень удобно, поэтому можно создать простейшую обработку
с реквизитом «ДокументСсылка» и в этой обработке создать команду со следующим кодом:
&НаСервереБезКонтекста
Функция РаспределениеРасходовНаСебестоимостьТоваровСервер(ДокументСсылка)
ДоходыИРасходыСервер.РаспределениеРасходовНаСебестоимостьТоваров(ДокументСсылка);
КонецФункции
&НаКлиенте
Процедура РаспределениеРасходовНаСебестоимостьТоваровКлиент(Команда)
Если НЕ ЗначениеЗаполнено(ДокументСсылка) Тогда
ПоказатьПредупреждение(,»Не выбран документ»);
Возврат;
КонецЕсли;
РаспределениеРасходовНаСебестоимостьТоваровСервер(ДокументСсылка);
КонецПроцедуры
7. В общем модуле ДоходыИРасходыСервер.РаспределениеРасходовНаСебестоимостьТоваров() ставим точку останова перед выполнением запроса, т.е.
в строке МассивРезультатов = Запрос.ВыполнитьПакет();
8. Выбираем в обработке документ и выполняем команду.
9. После остановки выполнения получаем параметры и текст запроса. В нашем случае были такие значения:
…..
Как видим, к «жирнейшему» регистру накопления выполняется запрос с фильтром только по организации и без фильтра по периоду и аналитике.
Как факт, около 13kk записей оборотов по организации «едет» в tempdb при обмене каждого документа.
Допустим документов на обмен 100 и так как узанный запрос выполнятеся около 3 минут, то несложный обмен «крутит» оклоло 300 мин 100 документов.
Самое печальное, что результирующий пакет в нашем случае пустой (доп расходов нет) и титаническая работа с tempdb бессмысленна.
Если поставить в фильтр параметры периода, то пакет выполнятся около трех секунд, при условии, что у нас в регистре себестоимости десятки миллионов записей.
Просьба рассмотреть описанную ситуацию на предмет оптимизации кода.
…………
Я допускаю, что я могу в чем-то ошибаться, делать неверные выводы. но возможно еще кто-нибудь увидит что там что-то не так и этот
дикий тормозной костыль отполируют.
19 — 20.01.22 — 17:26
(16) Ну или фича
Но раз не задокументировано то баг
20 — 20.01.22 — 17:28
Имхо
1. Связка ERP и БП причем обе последние очень странна, нафик там БП если в ERP по идее все есть?
2. На больших объемах только свои обмены, никаких глюкавых и отстающих типовых
21 — 20.01.22 — 17:32
(18) +
12. Смотрим текст пакета который самый «жирный»:
ВЫБРАТЬ
УчетСебестоимости.АналитикаУчетаНоменклатуры.Номенклатура КАК Номенклатура,
УчетСебестоимости.АналитикаУчетаНоменклатуры.СкладскаяТерритория КАК Склад,
УчетСебестоимости.Период КАК Период,
УчетСебестоимости.Регистратор КАК ДокументПоступления,
УчетСебестоимости.КоличествоПриход КАК Количество,
УчетСебестоимости.СтоимостьРеглПриход КАК Стоимость
ПОМЕСТИТЬ ВтПоступленияТоваров
ИЗ
РегистрНакопления.СебестоимостьТоваров.Обороты(
,
,
Регистратор,
РазделУчета В (ЗНАЧЕНИЕ(Перечисление.РазделыУчетаСебестоимостиТоваров.ТоварыНаСкладах), ЗНАЧЕНИЕ(Перечисление.РазделыУчетаСебестоимостиТоваров.СобственныеТоварыВПути))
И Организация = &Организация) КАК УчетСебестоимости
ГДЕ
УчетСебестоимости.КоличествоПриход > 0
И УчетСебестоимости.СтоимостьРеглПриход > 0
ИНДЕКСИРОВАТЬ ПО
Номенклатура,
Склад,
ДокументПоступления
;
это и есть узкое место
22 — 20.01.22 — 17:36
(21) Видимо и в ERP именно такая ситуация. Маленький объем данных перегружает неоправданно долго. А большие объемы данных вовсе не тянет.
Скорее всего там тоже такая же процедура кривая.
23 — 20.01.22 — 17:39
(20) 1. Т.е. такая схема работы — вести бух. учет в БП, а управленческий в ERP — не катит?
2. Видимо вы правы, что типовой обмен глючный.
24 — 20.01.22 — 17:51
(20)[нафик там БП если в ERP по идее все есть? ]
не всегда в ERP имеет смысл применять все ФСБУ/НК
не всегда имеет смысл отражать учет с детальностью ERP
часто ERP отстаёт в функционале от БП в части РСБУ
25 — 20.01.22 — 18:17
(20) А мне нравится
26 — 21.01.22 — 06:22
ERP 2.5 — сама по себе прожорливая. После перехода с 2.4 нам пришлось докупить дисков и памяти на сервер — перестало хватать. 48 Гб — вообще мало, у нас на 128 еле шевелилась.
27 — 21.01.22 — 11:13
(24) Какая схема работы лучше: 1) бух. учет ведется в ERP вместе с управленческим; 2) бух. учет ведется в БП и документы выгружаются в ERP для управленческого учета?
28 — 21.01.22 — 11:15
(26) 1) Сколько же надо памяти чтобы работало нормально?
2) Ошибка про которую я писал скорее всего не связана с нехваткой ОЗУ. Видимо сервер 1С потребляет не всю доступную память.
29 — 21.01.22 — 11:29
(27) >> Какая схема работы лучше.
Странный вопрос. Та что подойдёт именно вам. Готового ответа тут быть не может.
У любой схемы есть свои преимущества и недостатки.
Выбор напрямую зависит от того насколько ваш УУ далёк от БУ и НУ.
К тому же у вас и схема учёта странная — первоисточником первички выступает БП. Обычно наоборот — весь учёт и документооборот в ERP, а в БП выгружают данные нужные для регламентированного БУ и НУ.
Зачем вам вообще ERP, если БП хватает для ведения первичного учёта?
30 — 21.01.22 — 11:35
(28) >> сервер 1С потребляет не всю доступную память.
Что мешает проверить это утверждение? Запустить выгрузку и посмотреть за показателями. Хотя бы для начала просто в мониторе производительности ОС и в консоли администрирования кластера 1С.
31 — 21.01.22 — 11:57
(28) Мы удвоили до 256: хотя бы закрытие месяца перестало жаловаться на недостаток памяти.
32 — 21.01.22 — 12:08
(31) А сколько пользователей у вас работает в ERP?
33 — 21.01.22 — 12:16
(29) «Зачем вам вообще ERP, если БП хватает для ведения первичного учёта?» — Для бухгалтерского учета хватает БП, а для управленческого не хватает.
«К тому же у вас и схема учёта странная — первоисточником первички выступает БП. Обычно наоборот — весь учёт и документооборот в ERP, а в БП выгружают данные нужные для регламентированного БУ и НУ.» — Ранее и БУ и УУ велся в БП, а теперь внедряется ERP.
«Хотя бы для начала просто в мониторе производительности ОС» — ЦП — 35% занято, память — 64%.
34 — 21.01.22 — 12:26
(33) >> в мониторе производительности ОС» — ЦП — 35% занято, память — 64%.
Ну может надо хотя бы по процессам посмотреть. Сколько съедает rmngr, rphost.
Счетчики надо в динамике смотреть. Как и в какой момент они растут. Сравнивать с тем, что показывает консоль кластера по процессам, сеансам и соединениям.
35 — 21.01.22 — 12:27
(32) При закрытии месяца — 1.
36 — 21.01.22 — 12:29
(33) >> Для бухгалтерского учета хватает БП, а для управленческого не хватает. Ранее и БУ и УУ велся в БП, а теперь внедряется ERP.
Это я понимаю. Вроде не совсем дурачок ))). Но это не ответ на вопрос «зачем?». Что такого делается в ERP после загрузки туда данных из БП? Можно лишь гадать.
Слишком мало вводных данных, чтобы давать какие-то советы.
37 — 21.01.22 — 12:43
(34) «Ну может надо хотя бы по процессам посмотреть. Сколько съедает rmngr, rphost.» — rphost — 20% ЦП, 11400 МБ. rmngr — 0.7% ЦП, 377 МБ. Если в кратце.
38 — 21.01.22 — 12:45
(27) лучше вести учет в одной системе, но есть вышеописанные исключения
39 — 21.01.22 — 12:48
(36) «Что такого делается в ERP после загрузки туда данных из БП?» — Как минимум на основании перегруженных документов должен формироваться УУ. Как максимум документы там должны быть еще проведены по бух. учету, чтобы в последствии теоретически бухгалтерия могла тоже работать в ERP и не перегружать документы из БП.
40 — 21.01.22 — 12:51
(39)[на основании перегруженных документов должен формироваться УУ]
лажа
нет на стороне БП аналитик для УУ учета, в итоге он будет равен БУ
41 — 21.01.22 — 12:53
(40) в ERP же есть, для этого и перегружаем.
42 — 21.01.22 — 19:41
(39) ахаха
43 — 21.01.22 — 20:16
(39) Телега впереди лошади.ИМХО.
44 — 21.01.22 — 21:10
(39) а 1с точно 64 запустил? может у тебя 32 до сих пор?
45 — 22.01.22 — 11:19
(44) сервер 1С у нас 64 разрядный, а клиентский 1С — 32 разрядный
46 — 22.01.22 — 11:26
(45) запустите 64-х разрядный клиент. Что вы чудите? Как это вы вообще додумались, ЕРП 2.5, платформа 8.3.20, и запускать 32- клиент?
47 — 22.01.22 — 12:15
(41) жесть
48 — 22.01.22 — 12:23
(45)Вот здесь и засада может быть.
49 — 22.01.22 — 23:13
(47) А как будет не жесть?
50 — 24.01.22 — 09:16
(46) Не помогло
51 — 24.01.22 — 09:19
(45) беда…у вас доходит лимит 4гига на приложение и падает по ошибке. Память освобождается, только когда заканчивает свою работу запускаемая команда. В крайнем случае, можно разбить выгрузку на части, чтобы каждая не выжирала более 4гигов и через ПодключитьОбработчикОжидания запускать комадну выгрузки.
52 — 24.01.22 — 09:20
Можно просто определить период, за который не вывваливается ошибка, и обработчиком ожидания выгружать со сдвигом дат до нужного периода.
53 — 24.01.22 — 09:26
(49) УУ в ЕРП, разумеется.
54 — 24.01.22 — 09:27
(0) лицензия корп — это понятно, а вот обмен… типовой или самописный?
55 — 24.01.22 — 11:11
(54) Типовой
56 — 24.01.22 — 17:02
(54) Т.е для обмена БП — ERP желательно использовать лицензии на сервер 1С и клиентские лицензии КОРП?
57 — 24.01.22 — 17:16
(56) все же я считаю, что узкое место по вашей теме в коде (который я указал выше), а не в железе/лицухах.
у нас «фаршированное» железо, Корпы и пр. и все-равно типовой обмен в УТ -> БП — это поход черепах на кладку яиц.
58 — 25.01.22 — 11:57
(57) А какую доработку этой функции/запроса вы бы посоветовали? Какой конкретно поставить отбор и в каком месте?
59 — 25.01.22 — 12:18
(18) «Если поставить в фильтр параметры периода, то пакет выполнятся около трех секунд» — Поставить параметры ДатаНачала и ДатаОкончания такие же как в остальных частях пакета запроса?
SAURON777
60 — 25.01.22 — 12:23
(57) Самое интересное, что я делаю перелив документов только за один месяц после переноса остатков из БП в пустую ERP. Т.е. в ERP пока мало что есть. В частности в регистре РегистрНакопления.СебестоимостьТоваров практически нет записей. Видимо в моем случае не здесь находится узкое место.
Александр Рудницкий
Программист 1С компании CorpSoft24
Ошибка системы «1С: Предприятие 8.3» из-за нехватки памяти — постоянный спутник администратора 1С. Разбираемся, из-за чего они возникают, и рассматриваем пример диагностики одного подобного эпизода из практики администрирования сервера 1С.
Природа проблемы
Сообщение «Недостаточно памяти» — одна из самых часто встречающихся ошибок при работе с 1С: Предприятие версии 8.3 и выше. Она происходит по самым разным причинам — от обработки системой нескольких массивных файлов и загрузки больших объёмов данных, до обновления ПО и перегрузки ресурсов при формирования сложных отчётов.
Она не так критична при возникновении на клиентском компьютере, а вот если сообщение об ошибке выдает сервер 1С, нужно отнестись к этому максимально внимательно. Это тот самый случай, когда очень важно установить правильный «диагноз» — то есть решения не будет, пока ответственный администратор не распознает источник проблемы, не поймёт её природу.
Проблема может заключаться в несвоевременном завершении процессов, запускаемых различным ПО. Они накапливаются и перегружают доступный объём памяти на сервере. Также может иметь место интенсивная работа различных программ с постоянным резервированием и освобождением ресурсов памяти.
Приведу пример расследования одной подобной ошибки из своей практики.
Инцидент
Поступило обращение со следующей ошибкой:
Александр Рудницкий
Программист 1С компании CorpSoft24
Ошибка системы «1С: Предприятие 8.3» из-за нехватки памяти — постоянный спутник администратора 1С. Разбираемся, из-за чего они возникают, и рассматриваем пример диагностики одного подобного эпизода из практики администрирования сервера 1С.
Природа проблемы
Сообщение «Недостаточно памяти» — одна из самых часто встречающихся ошибок при работе с 1С: Предприятие версии 8.3 и выше. Она происходит по самым разным причинам — от обработки системой нескольких массивных файлов и загрузки больших объёмов данных, до обновления ПО и перегрузки ресурсов при формирования сложных отчётов.
Она не так критична при возникновении на клиентском компьютере, а вот если сообщение об ошибке выдает сервер 1С, нужно отнестись к этому максимально внимательно. Это тот самый случай, когда очень важно установить правильный «диагноз» — то есть решения не будет, пока ответственный администратор не распознает источник проблемы, не поймёт её природу.
Проблема может заключаться в несвоевременном завершении процессов, запускаемых различным ПО. Они накапливаются и перегружают доступный объём памяти на сервере. Также может иметь место интенсивная работа различных программ с постоянным резервированием и освобождением ресурсов памяти.
Приведу пример расследования одной подобной ошибки из своей практики.
Инцидент
Поступило обращение со следующей ошибкой:
Смотрим журнал регистрации, там так же выводится ошибка с пояснением о нехватке памяти на сервере:
Настроив технологический журнал (ТЖ) системы 1С с событием EXCP — EXCPCNTX обнаруживаем запись:
Ошибка СУБД out of memory for query result
То есть, обе ошибки сообщают о проблеме объёма памяти, на основании чего нашим главным подозреваемым становится код конфигурации (возможно наличие неоптимальных запросов).
Находим код конфигурации, вызывающий ошибку.
В журнале регистрации указан следующий код:
{ОбщийМодуль.ДокументооборотСКОВызовСервера.Модуль(22)}: Ошибка при вызове метода контекста (Получить)
по причине:
Недостаточно памяти для получения результата запроса к базе данных
Открываем конфигуратор и переходим в указанный модуль к указанному номеру строки кода:
Строка, на которой произошла ошибка:
ВнешниеОбъектыХранилище = Константы.ДокументооборотСКонтролирующимиОрганами_ВнешнийМодуль;
ДвоичныеДанныеОбработки = ВнешниеОбъектыХранилище.Получить().Получить();Смотрим тип объекта (константы), к которой идёт обращение:
Итак, в конфигурации есть константа:
ДокументооборотСКонтролирующимиОрганами_ВнешнийМодульОна хранит в базе что-то неструктурированное (двоичные данные), что может занимать значительный объём памяти.
Проверяем, какой объем данных фактически занимает константа. Для этого узнаем имя таблицы хранения в базе 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С, что приведёт к уменьшению объёма используемой памяти.
Источником проблемы также может быть недостаток пространства на жестком диске сервера. Здесь решение будет зависеть от устройство сервера или кластера, но здесь также могут помочь и перезапуск сервера, и наращивание ёмкости диска (или освобождение существующего пространства), а также оптимизация запросов или обновление версии ПО системы.