Почему 1С зависает при повторном заполнении документа и как это исправить?

← На главную

В практике разработки на платформе 1С:Предприятие 8.3 часто встречается коварная проблема: программный код, который идеально работает один или два раза, на третий запуск вызывает полное «оцепенение» системы. Особенно это характерно для сложных обработок заполнения, где задействованы одновременно и механизмы компоновки данных (СКД), и прямые запросы к базе данных с использованием временных таблиц. Рассмотрим подробнее, почему так происходит, и разберем по шагам, как диагностировать и устранить подобные зависания.

Анализ симптомов: эффект накопления

Типичная ситуация выглядит так: при нажатии на кнопку заполнения документ первый раз обрабатывается за 10 секунд, второй раз за 15, а на третий раз сеанс просто «виснет». При этом замеры производительности показывают странную картину: время выполнения самого отчета остается стабильным, а вот время выполнения последующего запроса растет лавинообразно. Проанализируем ситуацию: если исключить отчет — запрос работает быстро. Если исключить запрос — отчет работает быстро. Вместе они создают критическую нагрузку. Это явный признак того, что проблема кроется не в логике алгоритма, а в управлении ресурсами на стороне сервера приложений (rphost) или СУБД.

Шаг 1. Локализация места зависания через отладку

Первым делом нам необходимо выяснить, на какой именно строке кода происходит остановка. Для этого выполним следующие действия:

Запустим сеанс в режиме отладки.
Выполним заполнение дважды (когда оно еще работает).
На третьей попытке, когда система визуально зависла, перейдем в конфигуратор и нажмем кнопку «Завершить» (Shift+F5) или воспользуемся командой «Отладка — Прервать». Однако более эффективным методом будет установка точки останова непосредственно перед вызовом отчета и запроса.
Если прерывание не срабатывает, используем замер производительности. Внимательно посмотрим на топ процедур. Если мы видим, что время выполнения запроса или метода СкомпоноватьРезультат() уходит в бесконечность, значит, проблема в ресурсах сервера.

Шаг 2. Проблема фрагментации памяти в rphost

Одной из наиболее вероятных причин является фрагментация оперативной памяти в процессе rphost. Рассмотрим, как это работает: при выполнении отчета СКД и загрузке его в ТаблицаЗначений, платформа выделяет значительные блоки памяти. Когда следом выполняется запрос, использующий МенеджерВременныхТаблиц, серверу СУБД и серверу 1С требуется выделить дополнительные непрерывные блоки памяти для передачи данных.

Даже если мы явно очищаем переменные и уничтожаем временные таблицы, платформа не всегда мгновенно возвращает память операционной системе. На третьей итерации серверу может просто не хватить «чистого» куска памяти, из-за чего система начинает бесконечно перераспределять (свопировать) данные, что и выглядит как зависание. Чтобы убедиться в этом, проанализируем счетчик Private Bytes процесса rphost через монитор ресурсов Windows. Если график растет ступенчато и не падает после завершения процедуры — мы имеем дело с удержанием памяти.

Шаг 3. Взаимодействие с TempDB и «замусоривание» сеанса

Использование МенеджерВременныхТаблиц напрямую задействует системную базу данных SQL Server — TempDB. Выясним причину возможного замедления на стороне базы данных:

Статистика временных таблиц: При первом запуске SQL Server строит план запроса. На третьем запуске, если объем данных в TempDB изменился или таблицы не были корректно очищены на уровне СУБД, SQL Server может решить, что план устарел, и начать перестраивать его в момент выполнения.
Конфликты блокировок метаданных: Интенсивное создание и удаление временных таблиц в одном и том же сеансе (особенно если это происходит внутри одной серверной транзакции) может вызвать блокировки системных таблиц в TempDB.

Рекомендуется всегда явно уничтожать временные таблицы, как только они стали не нужны, не дожидаясь закрытия менеджера:


Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
// ... выполнение кода с ВТ ...
Запрос.Текст = "УНИЧТОЖИТЬ ВременнаяТаблицаДанных";
Запрос.Выполнить();
Запрос.МенеджерВременныхТаблиц.Закрыть();

Шаг 4. Анализ контекста управляемой формы

Проанализируем ситуацию с точки зрения управляемых форм. Если процедура заполнения вызывается «на сервере» без контекста (&НаСервереБезКонтекста), то передаются только параметры. Но если используется процедура &НаСервере, то при каждом вызове вся форма (весь её контекст) сериализуется и передается между клиентом и сервером.

Если в процессе заполнения данные из отчета или запроса помещаются в реквизиты формы (например, в скрытую ТаблицаЗначений или ДеревоЗначений), «вес» формы растет. На третьей итерации объем передаваемых данных может достичь критического предела, когда процесс сериализации начинает занимать всё процессорное время, вызывая эффект зависания интерфейса. Проверьте, не накапливаются ли данные в реквизитах формы, которые не очищаются перед повторным заполнением.

Шаг 5. Применение фоновых заданий для изоляции ресурсов

Одним из самых надежных способов решения проблем с утечкой памяти и зависаниями является вынос тяжелых вычислений в фоновое задание. Разберем по шагам, почему это помогает:

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

Пример структуры вызова:


ПараметрыЗадания = Новый Структура("Параметр1, Параметр2", Значение1, Значение2);
ФоновоеЗадание = ФоновыеЗадания.Выполнить("МойМодуль.ЗаполнитьДанныеНаСервере", ПараметрыЗадания);
ФоновоеЗадание.ОжидатьЗавершения();
// Получаем результат через временное хранилище