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

← На главную

Ситуация, когда в конфигуратор 1С вход выполняется без проблем, а при запуске пользовательского сеанса программа наглухо зависает сразу после ввода логина и пароля, является распространенной проблемой в клиент-серверном варианте работы. Характерный симптом — временное исчезновение проблемы после восстановления базы из резервной копии SQL с последующим возвратом зависаний при авторизации или проведении документов. Разберем по шагам, почему возникает такое поведение информационной базы и как полностью устранить неисправность.

1. Проверка на уровне кода и динамического обновления

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

Замер производительности при старте системы: запустим конфигуратор, перейдем в меню Отладка, включим режим Замер производительности и запустим пользовательский сеанс клавишей F5. Если в модуле управляемого приложения или в модуле обычного приложения (в процедурах ПриНачалеРаботыСистемы, ПередНачаломРаботыСистемы) выполняется тяжелый циклический запрос или обращение к заблокированной таблице, замер покажет строку с наибольшим временем выполнения.
Очистка кэша конфигурации после динамических обновлений: если база обновлялась «динамически», в таблицах метаданных SQL могут возникнуть несоответствия версий. Рекомендуется выполнить перезагрузку конфигурации из файла .cf: сохраним конфигурацию в файл через Конфигурация - Сохранить конфигурацию в файл, снимем признак изменений и загрузим его обратно через Конфигурация - Загрузить конфигурацию из файла.
Тестирование и исправление: перед процедурой обязательно создадим полную резервную копию базы. В конфигураторе перейдем в меню Администрирование - Тестирование и исправление, выберем режимы проверки логической и ссылочной целостности, реиндексацию таблиц и пересчет итогов.

2. Настройка регламентных процедур MS SQL Server

Если восстановление базы из бэкапа SQL временно решает проблему, но через несколько часов или дней база снова виснет при входе и проведении документов, первопричина почти всегда кроется в механизмах СУБД. При восстановлении бэкапа кэш планов запросов SQL Server очищается. По мере работы накапливается неактуальная статистика, что приводит к эффекту Parameter Sniffing: SQL Server выбирает катастрофически неэффективный план выполнения (например, полное сканирование таблицы Table Scan вместо поиска по индексу Index Seek).

Для исправления ситуации выполним регламентные процедуры на стороне СУБД:

Обновление статистики: настроим регулярное регламентное задание в SQL Server Agent для обновления статистики по всем таблицам базы. В экстренных случаях выполним принудительное обновление статистики с полным сканированием:
```
USE [Имя_Базы_1С];
EXEC sp_updatestats;
```
Реорганизация и перестроение индексов: фрагментация таблиц итогов регистров накопления и сведений приводит к деградации производительности при старте сеанса и проведении документов. Настроим еженедельный ребилд (Rebuild) индексов для таблиц с фрагментацией выше 30% и реорганизацию (Reorganize) при фрагментации от 10% до 30%.
Проверка целостности базы на уровне СУБД: убедимся, что на дисковых страницах базы нет физических повреждений, выполнив команду в среде SQL Server Management Studio: DBCC CHECKDB ('Имя_Базы_1С') WITH NO_INFOMSGS, ALL_ERRORMSGS;

3. Диагностика взаимоблокировок и зависших транзакций

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

Проанализируем блокировки в момент зависания входа:

Проверка сессий в SQL Server: выполним запрос к динамическим административным представлениям для поиска сессии-источника блокировки (Head Blocker):


SELECT 
    r.session_id,
    r.blocking_session_id,
    r.wait_type,
    r.wait_time,
    r.wait_resource,
    t.text AS QueryText
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.blocking_session_id <> 0 OR r.session_id IN (SELECT blocking_session_id FROM sys.dm_exec_requests);

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

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

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


<config xmlns="http://v8.1c.ru/v8/tech-log">
  <dump create="false"/>
  <log location="C:\1C_Logs\HangDump" history="4">
    <event>
      <eq property="name" value="SDBL"/>
    </event>
    <event>
      <eq property="name" value="TLOCK"/>
    </event>
    <event>
      <eq property="name" value="CALL"/>
      <ge property="Duration" value="5000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Запустим сеанс пользователя, дождемся зависания на этапе ввода пароля и выдержим паузу в 3–5 минут. В собранных логах проанализируем события TLOCK (управляемые блокировки) и CALL с длительностью более 5 секунд, чтобы увидеть конкретный контекст встроенного языка и текст SQL-запроса, на котором останавливается выполнение.

5. Оптимизация параметров сервера и инфраструктуры

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

Настройка базы tempdb: разделим базу данных tempdb на несколько файлов данных одинакового размера (по количеству физических ядер процессора, но не более 8), чтобы исключить конкуренцию потоков при формировании временных таблиц 1С.
Параметры автоувеличения файлов: отключим автоувеличение в процентах для файлов .mdf и .ldf. Установим фиксированный шаг расширения (например, 512 МБ или 1024 МБ), чтобы исключить зависания при росте журнала транзакций.
Исключения антивируса: добавим процессы ragent.exe, rmngr.exe, rphost.exe, sqlservr.exe и рабочий каталог кластера srvinfo в список исключений антивирусного монитора для предотвращения блокировки дескрипторов файлов сеансов.