Почему 1С самопроизвольно завершает сеансы пользователей и как это исправить?

Ситуация, когда стабильно работавший годами сервер 1С начинает внезапно «выкидывать» пользователей, является одной из самых сложных в диагностике. Особенно характерным является симптом, когда перед закрытием программы интерфейс замирает на 3–5 секунд, после чего появляется ошибка связи или окно Authenticate(). В этой статье мы подробно разберем, как выявить причину такого поведения и какие настройки сервера помогут стабилизировать работу системы.

Проанализируем симптомы и определим стратегию

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

Шаг 1. Изоляция рабочих процессов rphost

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

Разберем, как настроить кластер для повышения отказоустойчивости:

1. Откроем консоль «Администрирование серверов 1С Предприятия».
2. Перейдем в ветку Кластеры — Рабочие серверы.
3. Откроем свойства центрального сервера.
4. Настроим параметры:
   • Количество информационных баз на процесс: установите значение 1.
   • Количество соединений на процесс: установите ограничение (например, 5–10 соединений). Это заставит систему создавать несколько процессов rphost.
5. Параметр Безопасный расход памяти за один вызов: проверьте, чтобы здесь не стояло слишком маленькое значение, которое может обрывать сеанс при формировании крупных отчетов.

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

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

Чтобы точно узнать, почему происходит падение, нам нужно «заглянуть под капот» платформы. Обычный журнал регистрации здесь не поможет, нам понадобится Технический журнал. Он позволяет зафиксировать события исключений (EXCP), которые предшествуют вылету.

Создадим в папке с установленной платформой (обычно C:\Program Files\1cv8\conf) файл logcfg.xml со следующим содержанием:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\Logs\1C_EXCP" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Важно: убедитесь, что у пользователя, от имени которого запущена служба 1С, есть права на запись в папку C:\Logs\1C_EXCP. Проанализировав логи в этой папке после очередного вылета, мы сможем увидеть конкретную ошибку (например, нарушение прав доступа или критическую ошибку СУБД).

Шаг 3. Оптимизация работы MSSQL Server

Зависание на несколько секунд перед вылетом часто связано с тем, что SQL Server блокирует ресурсы или не успевает обработать запрос. Рассмотрим критические настройки для 1С:

1. Ограничение памяти (Max Server Memory): Никогда не оставляйте значение по умолчанию. Если на сервере 32 ГБ ОЗУ, выделите SQL серверу около 20–22 ГБ, оставив 10 ГБ для операционной системы и процессов rphost. Это предотвратит ситуацию, когда SQL «вытесняет» рабочие процессы 1С в файл подкачки, что и вызывает тормоза.
2. Параметр MAXDOP (Max Degree of Parallelism): Для баз 1С рекомендуется устанавливать значение 1 (или 2/4 для очень мощных многоядерных систем). Значение "0" позволяет SQL серверу использовать все ядра для одного тяжелого запроса, что может привести к микро-фризам всей базы данных и обрыву сессий 1С по таймауту.

Шаг 4. Укрощение журнала регистрации (.lgd)

В современных версиях платформы журнал регистрации хранится в формате SQLite (файл 1Cv8.lgd). При достижении размера в 10–20 ГБ и более, запись в такой журнал становится крайне медленной из-за особенностей блокировок SQLite. Когда пользователь проводит документ, 1С пытается записать событие в лог; если запись длится слишком долго, сеанс может закрыться с ошибкой.

Выясним причину чрезмерного роста и исправим её:

• Остановите службу 1С.
• Переместите старые файлы 1Cv8.lgd в архив.
• Запустите службу (создастся новый пустой файл).
• В конфигураторе настройте сокращение журнала регистрации, чтобы он очищался автоматически или разделялся по периодам.

Шаг 5. Сетевые настройки и «тихие» разрывы

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

Рассмотрим, что нужно отключить на сетевых картах сервера:

• TCP Chimney Offload
• Receive Side Scaling (RSS)
• NetDMA

Для этого воспользуемся командами в командной строке (CMD) от имени администратора:

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global netdma=disabled

Также полезно настроить параметры KeepAliveTime в реестре Windows, чтобы система чаще проверяла состояние соединения и не давала сетевому оборудованию закрывать порт по таймауту неактивности. Путь в реестре: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. Рекомендуется установить KeepAliveTime в значение 60000 (в десятичной системе, это 60 секунд).

Резюме

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