При выполнении массовой обработки данных, например, проведении более 100 000 документов в цикле, программисты часто сталкиваются со странным поведением сервера 1С:Предприятия. Сеанс может аварийно завершиться с ошибкой «Неспецифицированная ошибка работы с ресурсом», хотя видимых причин для нехватки оперативной памяти нет. Разберем детально, почему помещение операции в транзакцию решает эту проблему и какие механизмы платформы при этом задействуются.
Одной из ключевых настроек кластера 1С, влияющих на стабильность, является параметр «Безопасный расход памяти за один вызов». Рассмотрим, как он работает в контексте серверного вызова. Серверным вызовом считается любая последовательность действий, которая началась после передачи управления с клиента на сервер и продолжается до тех пор, пока управление не вернется обратно на клиентскую сторону.
Проанализируем ситуацию: если мы запускаем цикл обработки 100 000 строк кода на сервере, для платформы это выглядит как один бесконечно долгий вызов. В процессе работы 1С постоянно отслеживает, сколько памяти потребляет этот конкретный поток. Как только порог, установленный в настройках кластера, превышается, сервер должен прервать выполнение и «отцепить» сеанс, чтобы защитить рабочий процесс rphost от падения.
Однако здесь вступает в силу важное исключение: для обращений к серверу, у которых функция ТранзакцияАктивна() возвращает Истина, параметр безопасного расхода памяти игнорируется. Платформа не может принудительно завершить поток в середине транзакции, так как это приведет к логической несогласованности данных на уровне СУБД. Система «ждет» фиксации или отката транзакции, прежде чем применить санкции к «прожорливому» сеансу.
Многие разработчики полагают, что память очищается сразу после того, как объект (например, строка таблицы значений или ссылка) перестал использоваться в цикле. В реальности менеджер памяти 1С работает иначе. Высвобождение оперативной памяти сервером происходит в полном объеме только после возврата вызова на клиент.
Рассмотрим пример кода, который вызывает проблему:
Таблица = Запрос.Выполнить().Выгрузить(); // Создается тяжелый объект в памяти
Для каждого Строка из Таблица Цикл
// Обработка данных без транзакции
ПровестиДокументПоРегистру(Строка.Ссылка);
// На каждой итерации копятся временные объекты, кэши и метаданные
КонецЦикла;
Даже если вы не создаете новые таблицы внутри цикла, сама платформа генерирует множество служебных объектов (структуры, менеджеры блокировок, временные переменные). Без транзакционной «отсечки» эти объекты накапливаются в адресном пространстве процесса rphost до самого конца вызова. Если вызов длится долго, объем «мусора» растет, и срабатывает защитный механизм кластера.
Когда же мы добавляем НачатьТранзакцию() и ЗафиксироватьТранзакцию() внутрь цикла, мы создаем точки, в которых платформа может безопасно оценить состояние ресурсов. Кроме того, фиксация транзакции заставляет сервер выполнять определенные регламентные действия по очистке внутренних буферов и сбросу кэшей блокировок.
В технологическом журнале (ТЖ) при таком падении часто фиксируется событие EXCP с кодом 580392e6-ba49-4280-ac67-fcd6f2180121. Разберем, что это значит. Ошибка «Неспецифицированная ошибка работы с ресурсом» обычно указывает на то, что менеджер кластера (rmngr) принудительно терминировал поток в рабочем процессе rphost.
Это происходит по двум сценариям:
Использование транзакции внутри цикла меняет приоритет сеанса в глазах планировщика ресурсов. Платформа понимает, что идет работа с БД, и дает коду больше времени и ресурсов на завершение атомарной операции.
Выяснив причину, мы можем предложить несколько стратегий решения проблемы, помимо простого оборачивания каждой итерации в транзакцию.
Это самый надежный способ. Мы не выполняем все 100 000 итераций за один серверный вызов. Вместо этого мы передаем управление на клиент после обработки, например, каждых 1000 строк. При возврате на клиент память, занятая временными объектами текущего вызова, гарантированно очищается.
// Код на клиенте
Пока ЕстьДанные Цикл
Результат = ОбработатьПорциюНаСервере(ПараметрыПорции);
// Обновляем прогресс, проверяем прерывание пользователем
КонецЦикла;
Если процесс очень длительный (несколько часов), лучше создать вспомогательный РегистрСведений, куда записать план обработки (все ссылки, которые нужно обработать). Затем запустить регламентное задание или фоновое задание, которое будет брать по одной записи, обрабатывать её и помечать как выполненную. Это полностью исключает риск «раздувания» памяти одного вызова.
Обратите внимание на метод загрузки данных. Команда Запрос.Выполнить().Выгрузить() сразу помещает весь результат (все 100 000 строк) в оперативную память в виде ТаблицыЗначений. Если памяти на сервере впритык, это само по себе может спровоцировать ошибку.
Проанализируем альтернативу — использование выборки:
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
НачатьТранзакцию();
// Обработка данных
ЗафиксироватьТранзакцию();
КонецЦикла;
При использовании ВыборкаДетальныеЗаписи платформа подгружает данные из СУБД порциями, что значительно снижает моментальную нагрузку на память сервера 1С.
Не стоит забывать и про сервер базы данных. Если ваша база работает в режиме Read Committed Snapshot Isolation (RCSI), то длительная транзакция (или длинный цикл без транзакций, который 1С воспринимает как одну операцию) заставляет SQL Server хранить версии строк в tempdb. Это приводит к разрастанию файлов базы данных и нагрузке на дисковую подсистему.
Фиксируя транзакцию на каждой итерации (или группе итераций), вы позволяете SQL Server очищать Version Store, что предотвращает переполнение диска и замедление всей системы в целом.
Подводя итог, можно сказать, что транзакция в 1С — это не только инструмент обеспечения целостности данных, но и способ управления ресурсами сервера. Транзакция де-факто отключает «предохранитель» по памяти, позволяя тяжелым операциям завершиться. Однако правильным архитектурным решением будет не злоупотребление этим фактом, а разделение длительной обработки на короткие, контролируемые вызовы с возвратом управления системе.