Почему файловая база 1С запускается более 30 минут и как это исправить

← На главную

В процессе длительной эксплуатации информационных баз 1С многие сталкиваются с ситуацией, когда программа при входе зависает на десятки минут. При этом сама база имеет небольшой размер (менее одного гигабайта), тестирование и исправление (ТиИ) и утилита chdbfl.exe не выявляют физических повреждений, а после завершения запуска конфигурация работает с нормальной скоростью. Перенос базы на быстрый локальный SSD-диск или другой компьютер не дает ощутимого прироста скорости. Разберем по шагам, почему возникает такое поведение и как локализовать и устранить причину деградации запуска.

Диагностика зависания с помощью замера производительности

Когда база одинаково долго открывается локально и по сети, исключив влияние антивируса и сетевого окружения, необходимо проанализировать программный код, выполняемый при входе пользователя. В файловом режиме платформа 1С выполняет код клиентских обработчиков и серверных вызовов в едином потоке, последовательно обращаясь к таблицам файла 1cv8.1cd.

Выполним диагностику в конфигураторе следующим образом:

Откроем конфигурацию в режиме Конфигуратор.
Найдем модуль управляемого приложения или модуль обычного приложения (в зависимости от используемого режима).
Установим точку останова в самом начале первой процедуры инициализации — ПередНачаломРаботыСистемы или ПриНачалеРаботыСистемы.
Включим отладку и запустим сеанс в режиме 1С:Предприятие.
В момент остановки на первой точке запустим инструмент Замер производительности через главное меню конфигуратора (пункт Отладка — Замер производительности).
Продолжим выполнение программы клавишей F5 и дождемся полной отрисовки пользовательского интерфейса.
Остановим замер производительности и отсортируем результаты по колонке времени выполнения.

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

Причины замедления стартовых запросов на файловой СУБД

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

Отсутствие ограничения периода. Стартовый запрос опрашивает таблицы документов или задач за все время существования базы без фильтра по дате (например, без отсечения данных старше одного месяца).
Специфика файлового движка. Встроенная файловая СУБД 1С не имеет продвинутого оптимизатора запросов уровня MS SQL Server или PostgreSQL. При наличии сложных левых соединений, условий с ИЛИ, подзапросов в условиях соединения файловый движок переходит к полному сканированию таблиц (Table Scan), блокируя процесс на десятки минут.
Неактуальные итоги регистров. Если в базе годами не выполнялось регламентное смещение границы итогов, расчет остатков или получение среза последних заставляет систему пересчитывать все движения от устаревшей точки итогов через миллионы записей.
Произвольный запрос динамического списка без основной таблицы. Если на форме начальной страницы используется динамический список со сложным запросом, но не указано свойство ОсновнаяТаблица, платформа не может применить постраничную подгрузку (динамическое считывание). В результате при каждом открытии страницы на клиентскую машину считывается весь массив данных.

Способ 1. Отключение тяжелых форм в пользовательском режиме

Если пользователи не используют виджеты текущих дел, мониторы показателей или специализированные рабочие столы, проблему можно решить мгновенно без вмешательства в программный код и снятия конфигурации с поддержки:

Запустим сеанс пользователя и дождемся открытия программы.
Перейдем в главное меню: Главное меню — Вид — Настройка начальной страницы (в некоторых версиях интерфейса: Настройка рабочего стола).
В открывшемся окне найдем формы, отображаемые в левой и правой колонках.
Удалим ресурсоемкие формы (например, «Текущие дела», «Задачи», «Монитор руководителя»), оставив только простые журналы либо сделав начальную страницу полностью пустой.
Нажмем ОК и перезапустим программу для проверки скорости открытия.

Способ 2. Корректировка и комментирование нетипового кода

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


// Фрагмент формирования запроса задач начальной страницы
ТекстЗапроса = "ВЫБРАТЬ
               |    Задачи.Ссылка КАК Задача,
               |    Задачи.СрокИсполнения КАК Срок
               |ИЗ
               |    Задача.ЗадачиПользователя КАК Задачи
               |ГДЕ
               |    Задачи.Выполнена = ЛОЖЬ";

// Если отраслевой блок не требуется, исключаем его добавление:
// ТекстЗапроса = ТекстЗапроса + " ОБЪЕДИНИТЬ ВСЕ " + НетиповойТекстЗапросаРарус();

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

Способ 3. Оптимизация стартового запроса

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

Ограничение выборки по дате. Добавим обязательное условие по периоду, чтобы не сканировать историю за прошлые годы:


Запрос.Текст = "ВЫБРАТЬ
               |    Документы.Ссылка КАК Документ,
               |    Документы.Дата КАК Дата
               |ИЗ
               |    Документ.ЗаказНаряд КАК Документы
               |ГДЕ
               |    Документы.Дата >= &ГраницаПериода
               |    И Документы.Проведен = ИСТИНА";

Запрос.УстановитьПараметр("ГраницаПериода", НачалоМесяца(ТекущаяДатаСеанса()));

Использование временных таблиц с индексацией. Если требуется соединять несколько источников, разделим сложный запрос через МенеджерВременныхТаблиц и обязательно используем конструкцию ИНДЕКСИРОВАТЬ ПО для полей связи. Это снизит нагрузку на файловый процессор базы данных.
Проверка индексов реквизитов. Убедимся в дереве метаданных конфигуратора, что реквизиты, участвующие в секции ГДЕ или в условиях соединения, имеют свойство Индексировать (или Индексирование с дополнительным упорядочиванием).
Отложенное чтение данных. Перенесем инициализацию тяжелых таблиц из событий открытия формы в обработчик ожидания с помощью метода ПодключитьОбработчикОжидания. Это позволит интерфейсу открыться мгновенно, а вспомогательные списки подгрузятся в фоновом режиме через несколько секунд после старта.

Регламентные операции с итогами регистров

Если запрос обращается к остаткам или оборотам регистров накопления, обязательно выполним пересчет итогов. Для этого перейдем в режим конфигуратора, откроем меню Администрирование — Тестирование и исправление..., отметим пункт Пересчет итогов и запустим обработку. В пользовательском режиме также проверим обработку «Управление итогами» и сдвинем период рассчитанных итогов на текущий месяц. Это избавит платформу от необходимости вычислять остатки от старых периодов.