При переходе на релиз 3.0.95.15 конфигурации «1С:Бухгалтерия предприятия» многие технические специалисты столкнулись с аномально длительным процессом обновления. Ситуация часто осложняется использованием файлового режима работы базы данных и специфических версий системного окружения. Проанализируем причины этого явления и разберем способы оптимизации процесса.
Разберем, что именно изменилось в релизе 3.0.95. Данный выпуск стал ключевым для внедрения национальной системы прослеживаемости товаров. Это не просто рядовое обновление функционала, а фундаментальное изменение структуры метаданных. В конфигурацию были добавлены десятки новых объектов, включая регистры накопления, регистры сведений и, что самое важное, новые реквизиты (такие как РНПТ — регистрационный номер партии товара) практически во все документы товародвижения.
Когда мы запускаем обновление конфигурации базы данных, платформа 1С инициирует процесс реструктуризации таблиц. Рассмотрим подробнее, что происходит «под капотом»:
1Cv8.1cd.В файловом режиме все эти операции выполняются последовательно в один поток, что и приводит к многочасовому ожиданию.
Проанализируем влияние операционной системы. Использование Windows Server 2003 x64 для работы с современными версиями платформы 1С (например, 8.3.17.1851 или 8.3.17.2231) является критическим фактором замедления. Современные релизы платформы 8.3 оптимизированы под механизмы управления памятью и файлового кэширования, реализованные в Windows 10 и Server 2016/2019.
На устаревших ОС механизмы работы с временными файлами при выполнении этапа «Сбор служебной информации» могут работать в десятки раз медленнее. Это связано с тем, что платформа активно использует библиотеки среды выполнения (Runtime), которые в старых ОС либо эмулируются, либо работают в режиме совместимости с ограничениями дисковой подсистемы.
В релизе 3.0.95 произошло значительное обновление Библиотеки Электронных Документов. Рассмотрим, как это влияет на скорость:
Если вы столкнулись с тем, что обновление «зависло» на этапе загрузки конфигурации или сбора информации, выполним следующие шаги для оптимизации процесса:
Перед началом обновления в Конфигураторе обязательно запустим процедуру Тестирования и исправления (Администрирование — Тестирование и исправление). Выберем следующие пункты:
Это позволит уменьшить физический размер файла 1Cv8.1cd и устранить логические ошибки, которые могут прервать многочасовое обновление на середине.
Индексация полнотекстового поиска (ПП) создает колоссальную нагрузку на дисковую подсистему при масштабном изменении данных. Выясним, как его отключить программно или через интерфейс:
Перейдем в раздел Администрирование — Поддержка и обслуживание — Полнотекстовый поиск и снимем галочку «Разрешить полнотекстовый поиск». Это высвободит ресурсы процессора и диска для выполнения основной задачи обновления.
Если обновление на сервере идет слишком долго, проанализируем возможность выполнения процедуры на более мощной локальной машине с SSD-накопителем и актуальной ОС (Windows 10/11). Скопируйте файл базы данных на локальный ПК, выполните обновление там, а затем верните обновленный файл обратно на сервер. Это зачастую сокращает время работы с 5-6 часов до 40-60 минут.
После завершения работы в Конфигураторе, при первом запуске в пользовательском режиме («Предприятие»), программа начнет выполнять отложенные обработчики обновления. Посмотрим на пример кода, который можно использовать во внешней обработке для мониторинга или программного завершения лишних сеансов, мешающих обновлению:
// Пример получения списка активных фоновых заданий
Задания = ФоновыеЗадания.ПолучитьФоновыеЗадания();
Для Каждого Задание Из Задания Цикл
Если Задание.Состояние = СостояниеФоновогоЗадания.Активно Тогда
Сообщить("Выполняется задание: " + Задание.ИмяМетода);
КонецЕсли;
КонецЦикла;
Важно понимать, что в релизе 3.0.95 многие задания связаны с заполнением данных по прослеживаемости. Не прерывайте их принудительно, если они уже запущены, так как это может привести к неполному заполнению аналитики в документах.
Выясним причину, почему замена одной сборки 8.3.17.1851 на 8.3.17.2231 на одной и той же старой ОС не дает результата. Проблема кроется в 64-битной версии платформы. Для файловых баз среднего объема (2-4 Гб) использование x64 платформы на старых системах не всегда оправдано из-за повышенных требований к выделению памяти под каждый процесс обращения к базе данных.
Если обновление идет критически долго, попробуйте запустить процесс через 32-битную (x86) версию платформы той же сборки. Это может снизить накладные расходы на адресацию памяти в условиях ограничений Windows Server 2003.
Подведем итог: долгое обновление БП 3.0.95.15 — это следствие объективной сложности изменений в структуре базы данных. Основные рекомендации:
8.3.18 или выше, так как в них оптимизированы алгоритмы сравнения конфигураций.