Зависание пользовательских сеансов в среде 1С:Предприятие — это комплексная техническая проблема, которая редко имеет одну единственную причину. Часто администраторы сталкиваются с ситуацией, когда ресурсы сервера (процессор, SSD, оперативная память) кажутся свободными, но пользователи жалуются на "замирание" интерфейса, а в консоли администрирования сеансы помечаются как активные, хотя работа в них не ведется. Разберем по шагам, как диагностировать и устранить эти задержки, опираясь на настройки платформы, СУБД и операционной системы.
Первым делом проанализируем настройки самой информационной базы. В консоли администрирования кластера серверов 1С существуют параметры, регулирующие поведение неактивных пользователей. Рассмотрим их подробнее:
1200 — 1800 секунд (20–30 минут).86400 секунд или одни сутки), сервер будет накапливать "фантомные" сеансы, которые занимают место в таблицах сеансов и могут приводить к зависаниям. Рекомендуется устанавливать значение не более 3600 — 7200 секунд.Важно понимать разницу между активным сеансом и длительной операцией. Выясним причину: если в сеансе выполняется фоновое задание или строится тяжелый отчет, 1С считает этот сеанс активным, и механизмы засыпания на него не подействуют. Зависания же чаще всего касаются именно интерактивных сеансов, потерявших связь с сервером.
Рабочие процессы rphost могут накапливать ошибки в кэше или иметь утечки памяти, что напрямую влияет на стабильность сеансов. Проанализируем настройки рабочего сервера:
Перезапуск рабочих процессов: настроим автоматический регламентный перезапуск. В свойствах рабочего сервера установим интервал перезапуска (например, 86400 секунд). Это позволит системе плавно переводить пользователей на новые, "чистые" процессы rphost, не дожидаясь их деградации.
Допустимый объем памяти: ограничим аппетиты процессов. Установив "Безопасный расход памяти за один вызов", мы предотвратим ситуацию, когда один некорректный запрос пользователя (например, попытка выгрузить миллион строк в Excel) парализует работу всего рабочего процесса и всех пользователей, "сидящих" на нем.
Часто "зависание" сеанса в 1С — это лишь симптом ожидания ответа от SQL Server. Рассмотрим настройки СУБД, которые помогут избежать блокировок:
Параметр MAXDOP (Maximum Degree of Parallelism): по умолчанию SQL Server пытается распараллелить выполнение одного запроса на все доступные ядра процессора. Для 1С это часто вредно. Рекомендуется установить MAXDOP = 1 для небольших систем или не более 4 для высоконагруженных. Это предотвратит ситуацию, когда один тяжелый отчет захватывает все ресурсы процессора, заставляя другие сеансы "висеть" в ожидании.
Ограничение памяти (Memory Limit): SQL Server стремится занять всю доступную оперативную память. Если на одном физическом сервере (или виртуальной машине) стоят и 1С, и SQL, необходимо жестко ограничить Max Server Memory. Оставим ОС и процессам 1С минимум 4–8 ГБ, иначе система начнет использовать файл подкачки на диске, что приведет к катастрофическому падению производительности и зависаниям.
Cost Threshold for Parallelism: увеличим это значение со стандартных 5 до 50. Это заставит SQL Server использовать параллелизм только для действительно "дорогих" запросов, не тратя ресурсы на дробление мелких операций.
Иногда сеансы "висят", потому что сервер не знает, что клиент уже отключился (например, пропал интернет или захлопнули крышку ноутбука). Разберем, как ускорить обнаружение "мертвых" соединений:
В реестре Windows по пути HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters полезно проверить или создать параметр KeepAliveTime. Сокращение этого времени (например, до 10-15 минут) заставит операционную систему чаще проверять состояние TCP-соединений и вовремя закрывать "повисшие" сеансы на уровне сети.
Также проверим схему электропитания сервера. Выберем режим "Высокая производительность". Режимы экономии энергии могут вносить микро-задержки в работу процессора и дисковой подсистемы, которые платформа 1С воспринимает крайне болезненно.
Если вышеуказанные меры не помогли, перейдем к "тяжелой артиллерии" — Технологическому журналу (ТЖ). Это встроенный механизм 1С для детальной фиксации всех событий. Создадим файл logcfg.xml в папке настроек 1С (обычно C:\Program Files\1cv8\conf) и настроим сбор событий EXCP (исключения) и DBMSSQL (длительные запросы к SQL).
Пример структуры файла для отслеживания долгих запросов:
<config xmlns="http://v8.1c.ru/7.4/config/log">
<log location="C:\LOGS\1C" history="24">
<event>
<eq property="Name" value="DBMSSQL"/>
<gt property="Duration" value="10000000"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
</log>
</config>
Проанализируем полученные логи: если в момент зависания в ТЖ фиксируются события с большой длительностью (Duration), мы увидим конкретный SQL-запрос или программный код, который вызвал затык. Это позволит понять: проблема в неоптимальном коде, в блокировках на уровне таблиц БД или в аппаратных мощностях.
Даже если базы находятся на SSD, производительность может упираться в дисковые операции. Посмотрим на очередь к диску через монитор ресурсов. Если очередь стабильно выше 1-2, значит, диск не справляется. Проверьте:
.ldf) на отдельный физический диск от самих данных (.mdf)?Комбинируя эти методы — от простых настроек времени жизни сеанса до глубокого анализа Технологического журнала — мы сможем создать стабильную рабочую среду и избавиться от "зависающих" пользователей.