Подробный гайд: Одна база 1С стартует мгновенно, а вторая «висит» или отвечает очень долго

Почему одна база 1С работает быстро, а вторая зависает? Краткий гайд по диагностике: проверка блокировок, кэша, СУБД и кода для файловых и клиент-серверных режимов.

2026.09.30                  


Подробный гайд: Одна база 1С стартует мгновенно, а вторая «висит» или отвечает очень долгоПодробный гайд: Одна база 1С стартует мгновенно, а вторая «висит» или отвечает очень долго Ситуация, когда одна информационная база (ИБ) 1С стартует мгновенно, а вторая «висит» или отвечает очень долго — классическая. Поскольку базы находятся в разных условиях, проблема локализуется либо в самой базе данных (СУБД), либо в специфике конфигурации/кода, либо в настройках кластера серверов.


ЭТАП 1. Быстрая первичная диагностика (Универсально)

Прежде чем лезть в дебри, проверьте три «тихие» причины:



  1. Проблема с DNS (Обратное преобразование). Сервер 1С при подключении клиента пытается определить его имя по IP. Если DNS настроен некорректно, подключение может висеть 10–30 секунд. Решение: прописать IP клиента и сервера в файл hosts на сервере 1С.
  2. Антивирус / Экран. Убедитесь, что антивирус на сервере 1С и сервере СУБД не сканирует в реальном времени файлы баз данных (.mdf/.ldf для MS SQL, файлы PG для PostgreSQL) и каталоги кластера 1С.
  3. Монопольная блокировка. Зайдите в консоль администрирования кластера 1С -> Сеансы. Нет ли там сеанса с установленной блокировкой (например, администратор делает тестовое обновление или кто-то запустил тяжелое фоновое задание и «повесил» базу).

ЭТАП 2. Если базы работают в КЛИЕНТ-СЕРВЕРНОМ варианте

Если первая база работает быстро, а вторая нет (при условии, что они на одном кластере и одной СУБД), проблема на 90% внутри второй базы.

1. Проверка уровня СУБД (MS SQL / PostgreSQL)

Когда клиент открывает базу, 1С выполняет множество служебных запросов к системным таблицам. Если в базе «плохо» с индексами или есть блокировки, она будет тормозить.

Блокировки и долгие транзакции:

  • MS SQL: Выполните sp_who2 или посмотрите sys.dm_exec_requests. Ищите сессии со статусом WAIT или BLOCKED.
  • PostgreSQL: Посмотрите pg_stat_activity. Ищите запросы со статусом active или idle in transaction, которые висят давно.

Раздувание журнала транзакций (MS SQL):

Если файл .ldf базы переполнен и настроен авторост (autogrowth), СУБД будет тратить время на расширение файла при каждом чихе. Проверьте размер лога и настройте регулярное бэкапирование логов (чтобы они усекались).

Отсутствие или фрагментация индексов:

В 2-й базе может быть сильно фрагментирована кластерная таблица или отсутствовать индексы.

Решение:

Запустите в 1С обработку «Обслуживание» -> «Перестроение индексов» или используйте штатные средства СУБД (REBUILD/REORGANIZE).

Кэш планов запросов:

Иногда СУБД «запоминает» неоптимальный план запроса. В MS SQL можно попробовать очистить кэш планов (но только в нерабочее время!).


2. Проверка кода конфигурации (Обработчики старта)

Очень частая причина — «тяжелый» код, который выполняется при старте.

  • ПриНачалеРаботыСистемы (в модуле обычного приложения или управляемого). Посмотрите, нет ли там прямых запросов к тяжелым регистрам, обращениям к внешним API (HTTP-сервисам, веб-сайтам) без таймаутов. Если внешний сервис недоступен, а таймаут не задан, клиент будет висеть, пока не отвалится по таймауту ОС (может быть до 2 минут).
  • Подписки на события. Если в базе зарегистрированы подписки на события, которые срабатывают при чтении метаданных на старте, они могут «вешать» открытие.
  • Доработки и расширения. Проверьте, не подключено ли к тормозящей базе какое-то специфическое Расширение (Extension), которого нет в первой базе.

3. Проблема с кэшем сервера 1С

Иногда кэш метаданных на сервере 1С для конкретной базы «битый».

Решение:

Остановите службу сервера 1С (или отключите базу в консоли кластера). Удалите содержимое каталога c:\Program Files\1cv8\srvinfo\snCPh\ (или аналогичного, где лежит кэш вашего кластера). Запустите службу. При следующем подключении кэш пересоздастся.


4. Технологический журнал (ТЖ)

Если визуально ничего не понятно, включите ТЖ на сервере 1С только для проблемной базы.
Настройте в файле logcfg.xml вывод событий EXCP (исключения), SDBL (работа с СУБД) и DBMSSQL / DBPOSTGRES.
Посмотрите логи в момент «зависания». Обычно там видно, на каком именно запросе или действии система останавливается.




ЭТАП 3. Если базы работают в ФАЙЛОВОМ варианте

Если обе базы лежат на сетевом диске (или одна локально, а вторая на шаре), диагностика идет по другому пути.

1. Блокировки файла .1CD.

Проверьте, нет ли в папке с базой файла 1Cv8.1CD (или 1Cv8.lck). Если база «висит» при открытии, возможно, другой пользователь или «зависший» процесс (например, фоновый антивирус или служба индексации Windows) заблокировал файл.

2. Проблемы сетевого стека (SMB).

Если первая база локальная, а вторая на сетевом диске, проблема в сети. Протокол SMB очень чувствителен к задержкам (latency).

Решение:

Проверьте пинг до файлового сервера. Убедитесь, что сетевая карта и свитчи работают на гигабитных скоростях без ошибок. Отключите «Медленный режим» (Slow Link) в групповых политиках Windows.

3. Повреждение файла базы.

Файловая база могла повредиться (сбой питания, обрыв сети при записи).

Решение:

Сделайте копию папки с базой. Запустите утилиту chdbfl.exe (идет в комплекте с платформой 1С) и попробуйте «вылечить» файл .1CD.


ЭТАП 4. Алгоритм действий «прямо сейчас»

Чек-лист:

  1. Откройте консоль администрирования серверов 1С. Посмотрите, есть ли активные сеансы во второй базе. Если есть «висящие» сеансы с длительным временем активности — принудительно завершите их.
  2. Зайдите в первую (быструю) базу, откройте «Замер производительности» (если позволяет конфигурация) или «Все функции» -> v8:toolPerformance. Сравните время выполнения стандартных запросов (например, Запрос("Выбрать * Из Справочник.Номенклатура")) в первой и второй базе. Если во второй запрос выполняется в 10 раз дольше — проблема в СУБД (индексы/блокировки).
  3. Попробуйте открыть вторую базу в режиме «Тонкий клиент» или через веб-клиент, если он настроен. Если там открывается быстро, проблема в кэше толстого клиента на конкретной рабочей машине (удалите кэш клиента на ПК пользователя через %localappdata%\1C\1Cv8).
  4. Посмотрите Журнал регистрации второй базы. Нет ли там массовых ошибок подключения к СУБД или ошибок выполнения запросов в последние часы.

Мы делимся этой технической информацией, чтобы помочь вам в решении задач — используйте её с пониманием. Статья носит рекомендательный характер, поэтому, пожалуйста, применяйте описанные методы осмотрительно.


Статью подготовил: Аверко Денис Сергеевич @Nymexis г. Омск (специалист по ЗИ)

Комментарии

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