Ситуация, когда «Универсальный обмен данными в формате XML» (обработка для загрузки данных на базе «1С:Конвертация данных 2.1») работает быстро в тестовой базе, но безнадежно «вешает» рабочую систему, встречается довольно часто. Программисты нередко сталкиваются с тем, что индикатор загрузки замирает, журнал регистрации молчит, а база данных перестает отвечать на запросы. В этой статье мы подробно разберем, почему так происходит, и проанализируем неочевидные факторы, влияющие на производительность обмена.
Разберем основной корень проблемы, с которым столкнулся автор темы. В конфигурации «Конвертация данных 2.1» предусмотрено несколько этапов выполнения кода. Один из самых коварных — обработчик «После загрузки данных». Рассмотрим подробнее, как он работает:
Если в этом обработчике прописан пересчет итогов, поиск связанных объектов или сложные запросы к базе, то время выполнения этих операций в рабочей базе может в десятки раз превышать время в тестовой. Выясним причину: в рабочей базе таблицы содержат миллионы записей, и запрос, который «пролетает» в тестовой базе на 10 000 строк, в рабочей начинает сканировать огромные индексы. Если вы заметили зависание в самом конце процесса, попробуйте временно закомментировать код в этом обработчике:
// Пример проблемного кода в правилах обмена (обработчик После загрузки)
// Для Каждого СсылкаИзСписка Из Параметры.ЗагруженныеОбъекты Цикл
// Объект = СсылкаИзСписка.ПолучитьОбъект();
// Объект.Записать(РежимЗаписиДокумента.Проведение); // Это может вызвать лавинообразный рост времени
// КонецЦикла;
Как только мы отключаем тяжелые алгоритмы «пост-обработки», загрузка часто завершается мгновенно. Это говорит о том, что проблема не в самих данных, а в логике их финальной обработки.
Рассмотрим ситуацию с точки зрения платформы 1С. Каждый раз, когда в базу записывается новый объект (справочник или документ), система пытается обновить индекс полнотекстового поиска. Проанализируем разницу между базами:
Для ускорения процесса мы рекомендуем перед началом массовой загрузки через XML зайти в раздел Администрирование — Общие настройки — Полнотекстовый поиск данных и временно отключить его. Это снимет значительную нагрузку с сервера rphost и СУБД.
В ходе обсуждения автор упомянул, что размер рабочей базы на SQL-сервере составлял 40 Гб, а после манипуляций с .dt файлом упал до 3 Гб. Это явный признак того, что регламентные задания на уровне SQL-сервера не выполнялись долгое время. Выясним, как это влияет на обмен данными:
Статистика SQL — это данные, на основе которых сервер строит план выполнения запроса. Если статистика устарела, SQL-сервер может выбрать крайне неэффективный способ поиска данных при записи или проведении объектов. Это превращает секундную операцию в минутную.
Фрагментация индексов — при массовом удалении или изменении данных индексы «распухают» и становятся фрагментированными. Разберем по шагам, что нужно сделать перед загрузкой в рабочую базу:
UPDATE STATISTICS).REBUILD INDEX).После этих процедур даже «тяжелая» рабочая база начнет обрабатывать XML-пакеты значительно быстрее.
Проанализируем еще один фактор — фоновые процессы. В рабочей базе постоянно запускаются регламентные задания: расчет итогов, извлечение текста, обновление агрегатов, синхронизация с другими системами. Если во время загрузки 10 000 объектов стартует тяжелое регламентное задание, возникает конкуренция за ресурсы процессора и блокировки таблиц в СУБД.
Решение: Перед загрузкой через «Универсальный обмен данными» обязательно установите блокировку регламентных заданий в консоли администрирования кластера 1С. Это гарантирует, что все ресурсы системы будут отданы процессу импорта данных.
Посмотрим на техническую сторону работы самой обработки. Она предлагает два режима. Разберем их отличия:
rphost читает его напрямую. Это самый быстрый способ, так как исключается лишняя передача данных по сети. Однако стоит помнить, что в этом режиме отладка кода в правилах обмена (если она включена) может потребовать дополнительных настроек сервера.Каждое событие записи объекта фиксируется в Журнале регистрации (ЖР). Если в настройках базы установлен уровень детализации «Регистрировать все», то при загрузке 100 000 объектов файл ЖР (или таблица в SQL) моментально вырастет на несколько сотен мегабайт. Постоянная запись в .lgf файл или SQL-таблицу ЖР создает дополнительную очередь на дисковую подсистему.
Попробуйте на время загрузки снизить уровень логирования до «Регистрировать только ошибки». Это часто дает прирост скорости на 10-15%.
Подводя итог, можно сказать, что «зависание» — это почти всегда следствие либо избыточной логики в самих правилах обмена (обработчики событий), либо неготовности инфраструктуры к массовому приему данных. Чтобы решить проблему, мы рекомендуем действовать по следующему алгоритму:
ПриЗагрузке и ПослеЗагрузки.Используя этот комплексный подход, мы сможем добиться стабильной и быстрой работы обмена данными даже в самых нагруженных системах.