Переход на новую версию платформы 1С — это всегда ответственный шаг, который не всегда проходит гладко. Одной из часто встречающихся проблем на версии 8.3.15.1565 является периодическое аварийное завершение работы «1С:Управление производственным предприятием» (УПП). При этом более современные конфигурации, такие как ERP или ЗУП 3, работающие на тонком клиенте, могут продолжать функционировать стабильно. В этой статье мы подробно разберем, почему так происходит, как проанализировать логи технологического журнала и какие настройки сервера помогут стабилизировать систему.
Первое, на что стоит обратить внимание, — это разница в поведении тонкого и толстого клиента при нестабильности серверных процессов. В УПП основным режимом работы является толстый клиент. Он крайне чувствителен к любым кратковременным разрывам соединения с рабочим процессом сервера rphost или менеджером кластера rmngr. Если рабочий процесс перезапускается, сессия толстого клиента обрывается мгновенно.
В то же время тонкий клиент (используемый в ERP) обладает механизмом автоматического восстановления сеанса. Если серверный процесс упал, тонкий клиент может «подождать» несколько секунд и переподключиться к новому процессу без вылета пользователя. Именно поэтому руководство часто видит проблему только в УПП, хотя падает сам сервер 1С, обслуживающий все базы.
При анализе технологического журнала (ТЖ) часто встречается строка следующего вида:
RemoteInterfaceImpl.cpp(736): dd149677-3d47-4e05-a55f-4e75b13a441f: Процесс завершается. Исходящий вызов запрещен.
Важно понимать: эта ошибка в событии EXCP обычно не является первопричиной падения. Она лишь фиксирует «предсмертное» состояние процесса. Когда процесс rphost или rmngr получает команду на завершение (от ОС или из-за критического внутреннего сбоя), он блокирует все новые сетевые вызовы. Попытка какого-либо потока выполнить действие в этот момент и порождает данную запись. Чтобы найти истинную причину, нам нужно заглянуть в события ТЖ, которые происходили за несколько секунд до этой ошибки.
Для того чтобы понять, что именно убивает процесс, стандартных настроек ТЖ недостаточно. Нам необходимо расширить сбор данных. Проанализируем, какие события помогут пролить свет на ситуацию:
Пример настройки файла logcfg.xml для расширенной диагностики:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\LOGS\1C_Crash" history="48">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="PROC"/>
</event>
<event>
<eq property="Name" value="ADMIN"/>
</event>
<event>
<eq property="Name" value="MEM"/>
</event>
<property name="all"/>
</log>
</config>
Одной из наиболее вероятных причин перезапуска процессов в платформе 8.3.15 являются настройки «безопасного расхода памяти». Рассмотрим, на что влияют эти параметры в консоли кластера:
rphost считается «больным».В УПП при формировании тяжелых отчетов в толстом клиенте потребление памяти на сервере может расти очень быстро. Попробуем временно увеличить эти показатели или установить значение «0» (без ограничений) для теста, чтобы проверить, прекратятся ли вылеты. Также убедимся, что используется 64-битная версия сервера 1С, так как 32-битный процесс ограничен 2-3 ГБ памяти, что для современной УПП катастрофически мало.
Начиная с версии 8.3.15, механизмы проверки лицензий стали более строгими. Проанализируем ситуацию: если в сети происходят микро-разрывы или менеджер лицензий HASP не отвечает мгновенно, платформа может инициировать проверку, которая приведет к подвисанию или завершению процесса rmngr.
Рекомендуем проверить настройки антивируса на сервере. В исключения должны быть добавлены не только исполняемые файлы 1cv8.exe, rphost.exe, rmngr.exe, но и пути к временным файлам пользователей и системным каталогам srvinfo. Иногда антивирус блокирует внутренние «исходящие вызовы» процессов 1С друг к другу, принимая их за вредоносную активность.
Выясним, не связано ли падение с конкретными действиями пользователей. В ТЖ после настройки события EXCP стоит обратить внимание на контекст ошибки. Если перед падением всегда идет обращение к одной и той же форме или отчету, проблема может быть в зацикливании или некорректном вызове серверного метода из толстого клиента.
Рассмотрим пример анализа сеанса:
SessionID), который предшествовал записи об ошибке.CALL или SDBL. Они укажут на конкретный модуль или запрос, который выполнялся в момент сбоя.Иногда помогает простое выполнение Тестирования и Исправления (ТиИ) с включенной реструктуризацией таблиц, так как причина может крыться в нарушении физической целостности индексов БД, что приводит к критической ошибке при чтении данных платформой.
Хотя версия 8.3.15.1565 считается многими стабильной, в баг-репортах 1С для линеек 15 и 16 зафиксировано множество исправлений, связанных именно с аварийным завершением рабочих процессов. Если диагностика через ТЖ и настройка лимитов памяти не дают результата, переход на более свежую платформу (например, 8.3.17 или 8.3.22 в режиме совместимости) является наиболее рациональным решением, так как в них исправлены многие утечки памяти и ошибки взаимодействия процессов, характерные для ранних версий 8.3.