В процессе эксплуатации клиент-серверных версий «1С:Предприятие» системные администраторы и разработчики часто сталкиваются с загадочным поведением системы: пользователь запускает тяжелую операцию (например, формирование проводок, закрытие месяца или проведение документов), которая выполняется в фоновом режиме, а через некоторое время после завершения фонового задания клиентское приложение 1С просто закрывается (вылетает) без видимых ошибок. При этом в журнале регистрации фиксируется обычное завершение сеанса.
Особенно остро эта проблема проявляется на платформе 1С 8.2 и ранних версиях 8.3 при использовании обычного приложения и режима толстого клиента. В этой статье мы подробно разберем, почему происходит аварийное завершение сеанса, как настроить диагностику и какие шаги предпринять для устранения этой неисправности.
Для того чтобы понять природу проблемы, рассмотрим жизненный цикл сеанса при работе с фоновыми заданиями. Когда пользователь нажимает кнопку на форме (например, «Сформировать проводки»), толстый клиент инициирует фоновое задание на сервере приложений 1С. Фоновое задание выполняется в контексте отдельного рабочего процесса rphost.exe.
После того как фоновое задание успешно выполнило свою работу и записало проводки в регистры, управление должно вернуться обратно на клиент (в сессию пользователя) для завершения транзакции и записи документа с признаком «Проведен». Однако именно в этот 20-секундный интервал происходит сбой. Выделим основные технические причины такого поведения:
rphost из-за лимитов памяти. Фоновые задания по проведению документов потребляют значительный объем оперативной памяти на сервере. Если в настройках кластера 1С установлены жесткие лимиты расхода памяти на один рабочий процесс, менеджер кластера rmngr принудительно останавливает перегруженный процесс rphost. При этом процессу дается определенное время (по умолчанию те самые 20–30 секунд) на завершение активных вызовов и перенос сеансов. Тонкий клиент обычно успешно мигрирует на другой «здоровый» процесс, а вот толстый клиент на обычных формах часто не справляется с миграцией и аварийно завершается.0xc0000005). Процесс rphost мгновенно завершается, «утягивая» за собой сеанс толстого клиента.snccntx). Потеряв связь с сеансом-владельцем, сервер уничтожает его, что приводит к закрытию клиентского приложения у пользователя.Для детальной диагностики нам понадобится настроить сбор логов технологического журнала 1С. Это единственный надежный способ зафиксировать, что именно происходит на сервере в момент падения сессии. Нам необходимо отследить падения рабочих процессов, ошибки исключений и работу сеансов.
Создадим или отредактируем файл конфигурации технологического журнала logcfg.xml на сервере приложений 1С. Этот файл должен располагаться в каталоге установки платформы (например, C:\Program Files\1cv8\conf\ или в соответствующем каталоге версии платформы).
Запишем в файл logcfg.xml следующие настройки:
<config xmlns="http://v8.1c.ru/v8/tech-journal">
<log location="C:\v8_logs\tech_journal" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="SESN"/>
</event>
<event>
<eq property="Name" value="PROC"/>
</event>
<event>
<eq property="Name" value="CONN"/>
</event>
<event>
<eq property="Name" value="ADMIN"/>
</event>
<event>
<eq property="Name" value="CLSTR"/>
</event>
<property name="all"/>
</log>
</config>
Разберем подробнее, что отслеживают эти события:
EXCP — фиксирует все исключительные ситуации и аварийные завершения процессов (включая падения rphost).SESN — логирует действия с сеансами пользователей (создание, завершение, переподключение к процессам).PROC — регистрирует события запуска и остановки процессов операционной системы (в первую очередь rphost и rmngr).CONN — отслеживает установку и разрыв сетевых соединений между клиентом и сервером.ADMIN — логирует административные действия в кластере 1С.CLSTR — предоставляет информацию о работе кластера серверов 1С и распределении нагрузки.После сохранения файла logcfg.xml платформа автоматически начнет вести логирование (перезапуск службы сервера 1С не требуется, но создание целевой папки C:\v8_logs\tech_journal на сервере обязательно). Нам нужно дождаться очередного вылета пользователя, зафиксировать точное время и сопоставить его с логами ТЖ.
Параллельно с анализом технологического журнала 1С крайне важно изучить системные логи операционной системы на сервере приложений 1С. Проанализируем журнал событий Windows:
Application Error или 1C:Enterprise.rphost.exe с кодом исключения 0xc0000005 (ошибка нарушения прав доступа к памяти) и указанием сбойного модуля (например, frame.dll, dbeng8.dll или gdiplus.dll), значит, имеет место баг платформы 1С или некорректная передача тяжелых объектов данных между сервером и клиентом.Если анализ логов ТЖ и системных событий показал, что перед вылетом пользователя происходила перезагрузка рабочего процесса rphost, нам необходимо оптимизировать настройки расхода памяти в консоли администрирования серверов 1С:
Выполним следующие регулировки параметров кластера:
rphost в случае планового выключения старого процесса.Для того чтобы локализовать проблему на уровне встроенного языка 1С и понять, доходит ли выполнение кода фонового задания до самого конца, добавим логирование событий в контрольных точках. Разберем пример реализации записи логов в Журнал регистрации непосредственно перед возвратом управления на клиентскую сторону:
// В модуле, где выполняется процедура фонового задания
Процедура ВыполнитьФормированиеПроводокНаСервере(ПараметрыЗадачи) Экспорт
НачатьТранзакцию();
Попытка
// Здесь выполняется основной код записи проводок в регистры
// ...
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
ЗаписьЖурналаРегистрации(
"ФормированиеПроводок.Ошибка",
УровеньЖурналаРегистрации.Ошибка,
,,
ОписаниеОшибки()
);
ВызватьИсключение;
КонецПопытки;
// Важнейшая точка логирования перед возвратом управления клиенту
ЗаписьЖурналаРегистрации(
"ФормированиеПроводок.Успех",
УровеньЖурналаРегистрации.Информация,
,,
"Фоновое задание успешно завершило транзакцию записи проводок. Передаем управление на клиент."
);
КонецПроцедуры
Если запись с событием "ФормированиеПроводок.Успех" появляется в Журнале регистрации, а сеанс пользователя все равно падает через 20 секунд — это гарантирует, что проблема кроется в транспортном слое платформы (передаче данных обратно на клиент), сетевых таймаутах или в аварийном закрытии процесса rphost менеджером кластера, но не в самом коде проведения транзакции.
Если фоновое задание выполняется длительное время (более 5–10 минут), а сетевое оборудование принудительно разрывает соединение, выполним следующие настройки на сервере приложений 1С и клиентских машинах:
regedit) и перейдем по пути: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters.KeepAliveTime (тип DWORD) со значением 300000 (5 минут в миллисекундах) или ниже.KeepAliveInterval (тип DWORD) со значением 1000 (1 секунда).Таким образом, мы детально рассмотрели проблему падения сеансов, настроили технологический журнал, оптимизировали параметры кластера 1С и внесли отладочный код для контроля выполнения фоновых заданий. Комплексный подход к диагностике позволит быстро локализовать и устранить сбой в работе системы.