Разберем распространенную ситуацию в клиент-серверном варианте работы «1С:Предприятия». Периодически администраторы сталкиваются с картиной, когда в консоли администрирования кластера у ряда активных сеансов внезапно очищаются значения колонок Сервер, Порт, Процесс и Соединение. При этом пользователи продолжают видеть открытую программу, однако любая попытка провести документ, записать элемент справочника или выполнить действие вызывает ошибку разрыва связи либо ошибку транзакции. После перезапуска службы сервера проблема временно уходит, но через определенный интервал повторяется снова.
Проанализируем архитектуру взаимодействия компонентов платформы, выясним первопричину такого поведения и пошагово рассмотрим способы устранения сбоя.
В архитектуре клиент-серверной системы «1С:Предприятие» за учет пользовательских сеансов отвечает менеджер кластера (rmngr), а за фактическое выполнение программного кода, запросов к базе данных и обработку логики — рабочие процессы (rphost). Сеанс регистрируется в менеджере кластера, а соединение открывается внутри конкретного рабочего процесса.
Если в консоли кластера у сеанса исчезают данные о сервере, порте и процессе, это свидетельствует о том, что рабочий процесс rphost, к которому было привязано соединение данного пользователя, аварийно завершил свою работу (упал) либо был принудительно прерван менеджером кластера по таймауту. Сам сеанс при этом продолжает числиться в оперативной памяти rmngr в статусе «потерянного». Когда пользователь пытается зафиксировать транзакцию, клиентское приложение отправляет вызов несуществующему процессу, что и приводит к критическим ошибкам.
Выясним, какие факторы приводят к аварийному завершению рабочих процессов с периодичностью раз в неделю или несколько дней:
rphost аппаратно ограничен адресным пространством приблизительно в 2 ГБ. В процессе интенсивной работы, выполнения тяжелых отчетов или постепенной фрагментации памяти лимит исчерпывается. При попытке выделить очередной непрерывный блок памяти процесс мгновенно аварийно падает, не успевая зафиксировать ошибку в системном журнале.rphost. Ошибка доступа к памяти (Access Violation) внутри любой внешней библиотеки неминуемо обрушивает весь процесс rphost со всеми подключенными пользователями.rmngr и rphost. Если внутренний пинг между процессами превышает критический порог, менеджер кластера считает рабочий процесс зависшим и принудительно его завершает.srvinfo) антивирусом при попытке сканирования «на лету» приводит к сбою обмена служебными сообщениями и падению служб.Чтобы точно определить причину крушения rphost, настроим сбор дампов аварийного завершения. Рассмотрим базовую конфигурацию файла logcfg.xml, который необходимо поместить в каталог настроек платформы (например, C:\Program Files\1cv8\conf\):
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump location="C:\dumps" type="2" />
<log location="C:\v8logs" history="72">
<event>
<eq property="name" value="EXCP" />
</event>
<event>
<eq property="name" value="PROC" />
</event>
<property name="all" />
</log>
</config>
Разберем параметры конфигурации подробнее:
location тега dump указывает путь к каталогу, куда система сохранит дамп памяти при падении процесса.type="2" предписывает формировать мини-дамп с информацией о стеке вызовов.EXCP регистрирует системные исключения платформы, а событие PROC отслеживает запуск и остановку процессов кластера.Если падение происходит без создания дампа через платформу, настроим Windows Error Reporting (WER). Для этого в ветке системного реестра HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps создадим подраздел с именем rphost.exe, внутри которого установим строковый параметр DumpFolder со значением пути к дампу и параметр DumpType типа DWORD со значением 2.
Посмотрим на настройки свойств кластера в консоли администрирования. Если используется 32-разрядная платформа или наблюдаются постепенные утечки памяти, зададим пределы перезапуска процессов:
30 секунд). Если процесс превышает заданный порог, кластер плавно запускает новый процесс rphost, перенаправляет новые сеансы на него, а старый завершает без потери сессий после завершения текущих вызовов.rphost падение одного из них затронет только часть пользователей, а не всю информационную базу.Проанализируем сетевой стек сервера. Механизмы аппаратной разгрузки сети в Windows Server могут вызывать микроразрывы соединений. Отключим их через командную строку, запущенную от имени администратора:
netsh int tcp set global chimney=disabled
netsh int ip set global taskoffload=disabled
Для корректного отслеживания активности клиентских подключений и предотвращения их блокировки межсетевыми экранами настроим интервалы проверки TCP. В ветке реестра HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters установим параметры:
KeepAliveTime (тип DWORD) — значение 300000 (5 минут в миллисекундах). По умолчанию этот параметр в Windows равен двум часам, из-за чего обрыв сетевой сессии выявляется сервером слишком поздно.KeepAliveInterval (тип DWORD) — значение 1000 (1 секунда).Также рекомендуется отключить неиспользуемый стек IPv6, задав параметр DisabledComponents со значением 0xff (тип DWORD) в ветке HKLM\SYSTEM\CurrentControlSet\Services\TCPIP6\Parameters, после чего перезагрузить операционную систему.
В качестве оперативной стабилизирующей меры на время детального анализа дампов настроим регламентный ночной перезапуск службы ragent по расписанию:
Пример команд для пакетного файла:
net stop "1C:Enterprise 8.2 Server Agent"
timeout /t 30 /nobreak
net start "1C:Enterprise 8.2 Server Agent"
Обратите внимание, что точное имя службы зависит от версии платформы и указано в диспетчере служб операционной системы.
Убедимся, что процессы сервера и каталоги данных не подвергаются фоновому сканированию. Добавим в доверенную зону и исключения антивируса:
ragent.exe, rmngr.exe, rphost.exe.srvinfo (по умолчанию C:\Program Files\1cv8\srvinfo).%TEMP% и %APPDATA%).Комплексная реализация описанных настроек позволяет устранить аварийные падения рабочих процессов, защитить соединения пользователей от обрывов и ликвидировать ошибки блокировки транзакций.