Переход с конфигурации 1С:Управление торговлей редакции 11.1 на 11.2 по праву считается одним из самых ресурсоемких обновлений. Это связано с кардинальной переработкой архитектуры данных: объединением справочников единиц измерения и упаковок, введением новых ключей аналитики номенклатуры и полной конвертацией регистров накопления. В данной статье мы разберем комплексный подход к ускорению этого процесса, начиная от настроек СУБД и заканчивая манипуляциями с программным кодом обработчиков.
Прежде чем приступать к ускорению, выясним причину задержек. В версии 11.2 разработчики реализовали масштабную реструктуризацию. Основное время тратится на:
ЕдиницыИзмерения в объединенный справочник УпаковкиЕдиницыИзмерения.Если ваша база работает на PostgreSQL (особенно под управлением Linux), стандартные настройки «из коробки» не подходят для массовой перезаписи миллионов строк. Проанализируем параметры, которые необходимо изменить в файле postgresql.conf на время проведения обновления:
1. Отключение синхронизации (критически важно):
Параметр fsync=off заставляет СУБД не дожидаться подтверждения физической записи на диск. Это дает колоссальный прирост скорости, но делает базу уязвимой к сбою питания. Рассмотрим это как временную меру под обязательный бэкап.
2. Увеличение буферов:
Для сервера с 32 ГБ оперативной памяти и базой в 20 ГБ рекомендуются следующие параметры:
shared_buffers = 8GB
effective_cache_size = 24GB
work_mem = 128MB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
3. Дополнительные настройки для Linux:
Используйте synchronous_commit = off. Это ускоряет транзакции за счет асинхронной записи логов. После завершения всех процедур обновления обязательно верните параметры к безопасным значениям.
После монопольного этапа обновления в конфигураторе наступает этап выполнения обработчиков в режиме «Предприятие». По умолчанию регламентное задание Обновление информационной базы запускается с определенным интервалом (часто раз в 60 секунд), что создает простои.
Настройка интервала заданий:
Зайдем в консоль регламентных заданий и установим расписание для задания обновления с интервалом в 1 секунду. Это позволит системе сразу переходить к следующему пакету данных или следующему обработчику, не ожидая стандартную минуту.
Количество потоков:
В современных версиях БСП (используемых в УТ 11.2) можно регулировать количество потоков обновления. Рассмотрим путь: Администрирование — Поддержка и обслуживание — Результаты обновления. Если система позволяет, установите количество потоков, равное числу ядер вашего процессора (для Core i7 это 4–8 потоков). Это позволит выполнять независимые обработчики параллельно.
Практика показывает, что реструктуризация в файловом режиме на быстром локальном SSD зачастую проходит быстрее, чем на SQL-сервере. Разберем этот алгоритм:
.dt.Этот метод помогает избежать накладных расходов на сетевое взаимодействие и транзакционную логику СУБД на самом тяжелом этапе — реструктуризации таблиц.
Иногда процесс «зависает» на конкретной процедуре из-за логических ошибок в данных. Чтобы понять, что именно происходит, проанализируем общий модуль ОбновлениеИнформационнойБазыУТ. Выясним, какие процедуры помечены как монопольные, а какие — как отложенные.
Пример структуры регистрации обработчиков в коде:
Процедура ПриДобавленииОбработчиковОбновления(Обработчики) Экспорт
// Монопольные обработчики (блокируют работу пользователей)
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "11.2.2.1";
Обработчик.РежимВыполнения = "Монопольно";
Обработчик.Процедура = "ОбновлениеИнформационнойБазыУТ.КонвертироватьУпаковки";
// Отложенные обработчики (можно работать в базе)
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "11.2.2.1";
Обработчик.РежимВыполнения = "Отложенно";
Обработчик.Процедура = "Справочники.КлючиАналитикиУчетаНоменклатуры.ЗаполнитьНовыеКлючи";
КонецПроцедуры
Если вы видите, что один из 170+ обработчиков крутится часами, посмотрите Журнал регистрации. Там фиксируются ошибки записи объектов. Часто причиной торможения являются дубли в справочниках или некорректные даты, которые обработчик не может обработать и уходит в бесконечный цикл попыток. В таком случае стоит временно пропустить проблемный обработчик (изменив его статус программно), исправить данные вручную и запустить его снова.
Многие пользователи пытаются ускорить обновление с помощью свертки базы, но при переходе на 11.2 это не всегда дает эффект, так как основная нагрузка ложится на справочники и ключи аналитики, которые при свертке сохраняются.
Рекомендуемые действия перед обновлением:
_InfoRg.Подводя итог: для успешного и быстрого обновления УТ 11.2 необходимо обеспечить максимальную производительность дисковой подсистемы через настройки PostgreSQL (fsync=off), минимизировать простои фоновых заданий (интервал 1 сек) и предварительно очистить базу от «мусорных» данных и лишних индексов.