← На главную

Анализ проблемы: почему скуль вешается при первом старте 1С

При переходе с редакции 11.2 на 11.3 в конфигурации 1С:Управление торговлей многие системные администраторы и разработчики сталкиваются с ситуацией, когда при первом запуске в режиме «1С:Предприятие» система зависает, а MS SQL Server загружает процессор на 99–100%. При этом процесс обработки данных может длиться от нескольких часов до суток, сгенерировав высокую нагрузку на базу tempdb.

Рассмотрим основные технические причины такого поведения:

1. Заполнение глобального регистра документов. В редакции 11.3 существенно изменилась архитектурная концепция журналов документов. Все документы и их ключевые реквизиты переносятся в единый регистр сведений РеестрДокументов для формирования универсальных списков. При первом старте запускаются фоновые процедуры, формирующие записи в этом регистре за всю историю базы.
2. Прямой переход через большой интервал релизов. Попытка обновиться с ранних релизов (например, с 11.2.3.X) сразу на поздние версии 11.3 (например, 11.3.3.X) вызывает колоссальную нагрузку из-за большого объема накопившихся процедур отложенного обновления.
3. Неактуальная статистика и настройки СУБД. Массовая реструктуризация и запись миллиона строк во временные таблицы при устаревшей статистике оптимизатора MS SQL Server приводит к построению неэффективных планов запросов.

Шаг 1. Использование стратегии пошагового обновления

Разберем первоочередное правило при обновлении крупных баз данных. Прямой переход между крайними версиями веток 11.2 и 11.3 формально может поддерживаться платформой, однако на практике приводит к многочасовым задержкам или зацикливанию обработки.

Для ускорения и стабильности процесса применим последовательный подход:

1. Выполним обновление конфигурации на ближайший промежуточный релиз ветки 11.3.
2. Запустим режим «1С:Предприятие» и дождемся завершения всех основных процедур первого старта.
3. Проверим выполнение отложенных обработчиков обновления и только после их полного завершения перейдем к следующему релизу по цепочке.

Шаг 2. Контроль и отслеживание выполнения отложенных обработчиков

Выясним, как проверить, идет ли реальная работа или система зависла окончательно. Во время первого запуска не следует прерывать процесс, если в базе меняются данные и фиксируется активность рабочих процессов.

Проанализируем состояние процедур обновления с помощью встроенных средств платформы и конфигурации:

1. Откроем журнал регистрации и отфильтруем события по фоновым заданиям и процедурам обновления.
2. Перейдем в форму отложенного обновления ИБ по пути: Администриование — Обслуживание — Регламентные операции — Отложенное обновление ИБ.
3. Используем специализированный отчет о статусе выполнения процедур обновления. Настроив в нем отбор % выполнения <> 100 и сортировку по убыванию количества объектов, мы сможем наглядно видеть динамику обработки документов.

Шаг 3. Оптимизация СУБД MS SQL Server на время обновления

Посмотрим, какие технические настройки на стороне сервера баз данных помогут ускорить процесс обработок и исключить падение производительности:

1. Обновление статистики СУБД. Не дожидаясь окончания всех фоновых заданий, во время тяжелой обработки запустим обновление статистики для базы данных. В SQL Server Management Studio выполним команду: EXEC sp_updatestats; Это позволит оптимизатору SQL построить правильные планы запросов к регистру РеестрДокументов и служебным таблицам.
2. Настройка базы tempdb. Проверим конфигурацию tempdb. Рекомендуется разбить ее на несколько файлов одинакового размера (по числу логических ядер процессора, обычно до 8 файлов) с фиксированным шагом приращения в мегабайтах (например, по 256–512 МБ), исключив авторасширение в процентах.
3. Ограничение степени параллелизма (MAXDOP). На время длительного обновления временно ограничим параметр Max Degree of Parallelism значением 1 или 2, чтобы тяжелые служебные запросы 1С не монополизировали все ядра процессора.

Шаг 4. Работа с RLS и журналами документов после обновления

Разберем особенности работы списков документов после завершения перехода на УТ 11.3. Из-за переноса данных в единый регистр РеестрДокументов при включенном ограничении прав на уровне записей (RLS) возможны падения производительности у бизнес-пользователей.

Если после завершения обновления наблюдаются задержки при открытии списков документов, проанализируем варианты настройки:

1. Проверим корректность работы специализированных журналов (например, ЖурналДокументовЗакупки, ЖурналДокументовПродажи или ЖурналДокументовВнутреннегоТовародвижения).
2. При возникновении проблем с RLS вернем отображение стандартных журналов документов в командном интерфейсе пользователей или скорректируем настройки профилей групп доступа.