Почему база 1С долго запускается по утрам и как это исправить

← На главную

Ситуация, когда одна из баз 1С на сервере начинает «капризничать» по утрам, — классическая проблема для системных администраторов и разработчиков. Пользователь вводит логин и пароль, после чего система замирает на 10–15 минут, в то время как соседние базы на том же сервере открываются мгновенно. Разберем по шагам, почему это происходит и как вернуть системе былую скорость.

Анализируем симптомы и исключаем очевидное

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

Получение лицензии (проверка USB-ключа или программной лицензии).
Загрузка конфигурации из таблиц базы данных в локальный кэш пользователя.
Выполнение кода в модуле управляемого приложения (процедура ПриНачалеРаботыСистемы).
Обновление или проверка динамических изменений конфигурации.

Если проблема локализована только в одной базе, а настройки лицензирования (разрешение выдачи лицензий сервером 1С) идентичны, то корень зла кроется внутри структуры самой базы данных или механизма кэширования.

Главный подозреваемый: «Мусор» от динамических обновлений

Рассмотрим наиболее частую причину — злоупотребление динамическим обновлением (так называемое «обновление демоном»). Платформа 1С сохраняет промежуточные состояния конфигурации в таблице Config. Если таких обновлений было много, в таблице накапливаются записи с признаком %dyn%. Это заставляет систему при каждом входе выполнять тяжелые проверки и пересборку конфигурации «на лету».

Выясним причину с помощью SQL-запроса. Откроем SQL Server Management Studio и выполним следующий скрипт для проблемной базы:


SELECT [FileName]
      ,[Creation]
      ,[Modified]
      ,[Attributes]
      ,[DataSize]
      ,[PartNo]
  FROM [ИмяВашейБазы].[dbo].[Config]
  WHERE [FileName] LIKE '%dyn%'

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

Алгоритм очистки базы от последствий динамических обновлений

Проанализируем безопасный метод очистки, который поможет восстановить скорость запуска. Внимание: любые действия с таблицами SQL напрямую требуют создания резервной копии!

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


DELETE FROM [ИмяВашейБазы].[dbo].[Config]
WHERE [FileName] LIKE '%dyn%'

После этого запустим службу сервера и проверим вход. Как правило, после очистки этого «хвоста» время входа сокращается с минут до секунд.

Проблема лицензирования и поиска ключей

Рассмотрим ситуацию, когда SQL чист, но задержка остается. Посмотрим на настройки поиска лицензий. Часто тонкий клиент тратит время на опрос всех доступных USB-ключей в сети. Проанализируем файл nnhasp.ini, который находится в папке conf в каталоге установки 1С.

Если в параметрах не указан конкретный адрес сервера лицензий, 1С будет использовать широковещательные запросы (Broadcast), что на Windows Server 2016 может приводить к значительным таймаутам. Рекомендуется жестко прописать адрес менеджера лицензий:


NH_SERVER_ADDR = 192.168.1.100 ; Укажите IP вашего сервера с ключом
NH_TCPIP = ENABLE

Также проверим настройки IPv6. На современных ОС Windows платформа 1С может сначала пытаться найти сервер по протоколу IPv6, ждать таймаута и только потом переходить на IPv4. Явное указание IP-адреса сервера в файле hosts или в строке подключения базы часто решает проблему «утреннего прогрева».

Влияние регламентных заданий и «утренних» процедур

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

Загрузка курсов валют и классификаторов.
Обновление индекса полнотекстового поиска (ППС).
Проверка обновлений программы.
Сбор и отправка статистической информации.

Если база данных имеет большой объем, обновление индекса полнотекстового поиска может блокировать работу на 10–15 минут. Попробуем временно отключить полнотекстовый поиск через меню «Администрирование» — «Поддержка и обслуживание» и проверить скорость входа на следующее утро.

Особенности работы Windows Server 2016 и SQL Server

Проанализируем ситуацию со стороны операционной системы. Windows Server 2016 активно использует механизмы экономии памяти. Если ночью к базе никто не обращался, SQL Server мог выгрузить страницы данных этой базы из оперативной памяти (Buffer Pool) в файл подкачки, а сама ОС могла «приостановить» неактивные процессы.

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

Установим схему электропитания сервера в режим «Максимальная производительность».
В настройках SQL Server укажем Minimum server memory, чтобы сервер не отдавал всю память операционной системе.
Настроим ночное обслуживание (Maintenance Plan) так, чтобы перед началом рабочего дня выполнялась хотя бы простая проверка целостности или реиндексация — это «прогреет» кэш SQL сервера нужными данными.

Комбинация очистки таблицы Config от динамических обновлений и правильная настройка поиска лицензий в 90% случаев решает проблему долгого запуска раз и навсегда.