Почему в 1С аварийно завершается рабочий процесс фонового задания и как это исправить?

← На главную

Переход на новые версии платформы 1С:Предприятие — это всегда ответственный шаг, который нередко сопровождается непредвиденным поведением системы. Одной из наиболее коварных и труднодиагностируемых ошибок является внезапное прерывание длительных операций с формулировкой «Аварийно завершился рабочий процесс фонового задания». При этом в Журнале регистрации мы видим лишь лаконичную запись Сеанс.Завершение без каких-либо подробностей и стека ошибок.

Особенно ярко эта проблема проявляется на платформе версии 8.3.16.1063 в конфигурациях на управляемых формах, таких как 1С:Управление нашей фирмой (УНФ). Ситуация часто усугубляется сопутствующими графическими аномалиями (так называемый баг «Vanish», когда элементы интерфейса или гиперссылки окрашиваются в ярко-розовый цвет или исчезают). В этой статье мы подробно разберем внутренние механизмы платформы 1С, приводящие к подобным сбоям, проанализируем влияние настроек СУБД и кластера 1С, а также предоставим пошаговое руководство по устранению этой проблемы.

Почему фоновые задания падают с определенной периодичностью?

Рассмотрим ситуацию, когда регламентное задание (например, «Удаление помеченных объектов» или любая другая тяжелая процедура, длящаяся более 20 минут) стабильно падает примерно каждые 24 минуты. Для того чтобы понять физику этого процесса, нам необходимо обратиться к архитектуре кластера серверов 1С:Предприятия.

В платформе 8.3 реализован встроенный механизм автоматического управления рабочими процессами (rphost.exe). Его задача — поддерживать оптимальное количество активных процессов в зависимости от нагрузки и расхода оперативной памяти. Этот механизм работает по следующим правилам:

Определение устаревших процессов (Obsolete Processes): Сервер 1С регулярно анализирует пул рабочих процессов. Если суммарное количество активных соединений снижается ниже лимитов, заданных в параметрах «Количество соединений на процесс» и «Количество ИБ на процесс», наименее загруженный процесс rphost помечается системой как «устаревший». По умолчанию этот цикл анализа запускается каждые 15–20 минут.
Параметр «Выключенные процессы останавливать через»: После того как процесс получил статус устаревшего, кластер перестает направлять на него новые соединения. Однако на нем могут оставаться активные сеансы, включая длительно выполняющиеся фоновые задания. Кластер запускает таймер обратного отсчета (время жизни выключенного процесса).
Принудительное уничтожение процесса: Из-за программных ошибок в ранних релизах ветки 8.3.16 (включая сборку 1063) менеджер кластера принудительно завершает («убивает») устаревший рабочий процесс по истечении таймаута, даже если на нем в данный момент выполняется тяжелое регламентное задание. Это мгновенно приводит к аварийному завершению фонового процесса в ОС, а пользователь получает ошибку в интерфейсе.

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

Влияние утечек памяти и багов платформы 8.3.16

Релиз 1С 8.3.16.1063 вошел в историю как один из самых нестабильных с точки зрения управления ресурсами сервера и отрисовки графики. Разберем основные уязвимости этой версии:

Конфликт GDI и баг «Vanish». Розовые гиперссылки и исчезающие шрифты — это прямое следствие утечки дескрипторов графического интерфейса (GDI handles) на стороне сервера и клиента при активном взаимодействии управляемых форм с сервером приложений. Платформа некорректно кэширует графические элементы, что приводит к исчерпанию лимитов дескрипторов в Windows и последующему крашу графической подсистемы. В серверном варианте это также влияет на стабильность процессов, так как утечки накапливаются внутри сессий rphost.exe.

Неконтролируемый рост потребления ОЗУ фоновыми заданиями. При выполнении сложных запросов или обработке больших массивов данных в памяти (например, при поиске ссылок перед удалением объектов) платформа 1С:Предприятие версии 8.3.16.1063 не освобождает оперативную память вовремя. Если в настройках кластера задан лимит «Допустимый объем памяти», процесс принудительно перезапускается менеджером кластера при превышении порога, прерывая активные задачи.

Как настроить параметры кластера серверов 1С для предотвращения сбоев

Если у вас нет возможности немедленно обновить платформу 1С, мы можем минимизировать вероятность падения процессов с помощью изменения параметров кластера в консоли Администрирования серверов 1С:Предприятия. Выполним следующие шаги:

Откроем утилиту «Администрирование серверов 1С Предприятия».
Перейдем к свойствам нашего кластера (по умолчанию Локальный кластер).
Проанализируем и скорректируем ключевые параметры:
- Интервал перезапуска процессов: Установим значение в 0 (отключает плановый перезапуск рабочих процессов, который также может прерывать задания).
- Выключенные процессы останавливать через: По умолчанию там может стоять небольшое значение (например, 180 секунд). Увеличим этот параметр до 3600 или даже 7200 секунд (1–2 часа). Это даст длительным фоновым заданиям гарантированное время на завершение своей работы до того, как процесс будет уничтожен.
- Допустимый объем памяти: Если сервер располагает достаточным объемом ОЗУ, временно увеличим этот показатель или установим значение 0 (без ограничений), чтобы избежать жесткого убийства процессов по лимиту памяти.

Такая настройка позволит «законсервировать» выключенные рабочие процессы на длительное время, позволяя фоновым заданиям штатно завершить свои транзакции.

Проблема конкуренции за память между 1С и MS SQL Server

Часто сервер приложений 1С и СУБД MS SQL Server развернуты на одном физическом или виртуальном сервере. Это стандартная практика для небольших и средних баз данных, однако она требует жесткого разграничения ресурсов.

По умолчанию MS SQL Server настроен так, чтобы использовать всю доступную оперативную память хоста под свой кэш (Buffer Pool). Если не установить верхний лимит:

SQL Server постепенно заберет под себя до 95-98% физической памяти.
При запуске тяжелого регламентного задания серверу 1С (процессу rphost.exe) резко потребуется дополнительная память для обработки таблиц значений и объектов метаданных.
Операционная система Windows, пытаясь выделить память для 1С, столкнется с ее дефицитом. В результате произойдет аварийное завершение процесса rphost.exe с кодом ошибки Out of Memory или нарушением прав доступа к памяти (Access Violation).

Решение: Ограничим аппетиты SQL Server. Откроем SQL Server Management Studio (SSMS), перейдем в свойства сервера на вкладку Memory (Память) и установим параметр Maximum server memory (Максимальный размер памяти сервера) таким образом, чтобы операционной системе и процессам 1С оставалось как минимум 20-30% общей оперативной памяти сервера (но не менее 4-8 ГБ для нужд ОС и кластера).

Диагностика сбоя с помощью Технологического журнала

Поскольку Журнал регистрации в режиме «Предприятие» при падении процесса фиксирует только событие закрытия сеанса, нам необходимо настроить детальное логирование на уровне платформы. Для этого используется механизм Технологического журнала (ТЖ) 1С.

Разберем, как настроить сбор информации по аварийным завершениям. Создадим в каталоге установки шаблонов конфигурации ТЖ (обычно это C:\Program Files\1cv8\conf\ или аналогичный путь для вашей разрядности платформы) файл с именем logcfg.xml со следующим содержимым:


<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log history="24" location="C:\1C_Logs\Crashes">
        <event>
            <eq property="Name" value="EXCP"/>
        </event>
        <event>
            <eq property="Name" value="PROC"/>
        </event>
        <property name="all"/>
    </log>
</config>

Рассмотрим, что именно делает эта конфигурация:

Параметр history="24" указывает платформе хранить собранные логи в течение 24 часов, автоматически удаляя более старые файлы, чтобы не переполнять дисковое пространство.
Событие EXCP (Exception) фиксирует все исключительные ситуации, аварийные завершения процессов и системные ошибки, происходящие в недрах платформы. Именно здесь мы сможем увидеть конкретную библиотеку (например, backend.dll, dbeng8.dll или системную ntdll.dll), вызвавшую падение.
Событие PROC логирует запуск, остановку и параметры работы самих процессов rphost, rmngr и ragent, что позволит сопоставить время падения задания с действиями менеджера кластера.

После создания файла logcfg.xml служба сервера 1С автоматически (в течение одной минуты) применит настройки без необходимости перезапуска всего сервера. При следующем падении фонового задания проанализируем файлы логов в папке C:\1C_Logs\Crashes.

Обслуживание Полнотекстового поиска (ППД) как частая причина крашей

Еще один скрытый источник регулярных падений рабочих процессов — повреждение индекса полнотекстового поиска. Регламентное задание «Обновление индекса ППД» запускается очень часто. Если файлы индекса на диске повреждены или их размер превышает допустимые лимиты для 32-разрядных версий процессов, rphost.exe аварийно завершает работу.

Выясним, как исправить эту проблему шаг за шагом:

Запустим информационную базу в режиме «1С:Предприятие» под учетной записью с правами администратора.
Перейдем в раздел Администрирование — Поддержка и обслуживание — Полнотекстовый поиск.
Нажмем кнопку Очистить индекс. Это действие удалит все временные и поврежденные файлы поискового индекса с диска сервера.
После успешной очистки нажмем кнопку Обновить индекс. Система заново переиндексирует все объекты базы данных. Этот процесс может занять значительное время в зависимости от объема базы данных, но он гарантирует целостность структуры ППД.