Переход на новые версии платформы и смену СУБД (например, с MS SQL на PostgreSQL) часто инициируют из-за требований современных конфигураций, таких как ERP Управление предприятием или Комплексная автоматизация. Однако нередко после обновления администраторы сталкиваются с критической нестабильностью: пользователей массово выбрасывает из системы с ошибкой "На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто". Проанализируем причины этой ситуации и разберем пошаговое решение проблемы на основе практического опыта.
Рассмотрим ситуацию системно. Ошибка "неисправимая ошибка" является общей и может быть вызвана целым пластом проблем: от некорректных настроек кластера 1С до аппаратных ограничений дисковой подсистемы при работе с PostgreSQL. В ходе анализа выясним, что основными факторами падения рабочих процессов rphost являются:
Проанализируем влияние ключа -debug. На рабочих базах использование отладки может приводить к нестабильности связи между клиентом и сервером. Разберем ситуацию: если после отключения отладки частота вылетов сократилась, значит, механизм блокировок или передачи контекста отладчику конфликтовал с нагрузкой. Рекомендуется запускать службу сервера 1С без параметров -debug в рабочее время.
После миграции между СУБД в каталогах кластера могут остаться "фантомные" записи о сеансах или кэшированные метаданные. Рассмотрим скрипт для полной очистки временных файлов сервера. Перед выполнением обязательно остановим службу 1C:Enterprise 8.3 Server Agent.
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
sc stop %SERVICE_1C_NAME%
timeout 10
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
set CNTX_PATH="C:\srvinfo\reg_1541"
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F /S "C:\Windows\Temp\*.*"
sc start %SERVICE_1C_NAME%
Обратите внимание на удаление файлов snccntx* (контекст сеансов). Часто именно повреждение этих файлов приводит к ошибке SeanceContextException в технологическом журнале.
Выясним одну из самых скрытых причин падения процесса rphost. Многие типовые конфигурации используют общий макет КомпонентаПечатиШтрихкодов. В платформе 8.3.15 старые версии этой компоненты могут некорректно работать с памятью в 64-битных процессах. Посмотрим на решение: необходимо заменить макет в конфигурации на актуальный из последних версий БСП (Библиотека стандартных подсистем) или БПО (Библиотека подключаемого оборудования). Это устраняет Access Violation, который мгновенно закрывает рабочий процесс при попытке формирования печатной формы.
Проанализируем разницу в архитектуре СУБД. В отличие от MS SQL, который предпочитает работу с несколькими большими файлами, PostgreSQL создает множество мелких файлов для таблиц и индексов. Это создает колоссальную нагрузку на произвольное чтение/запись (IOPS). Если база ERP размером более 100 Гб работает на классических HDD (пусть даже в RAID 10), возникнет очередь к диску, что приведет к таймаутам и вылетам 1С.
Решение: перенос файлов базы данных на скоростные NVMe SSD. После этого скорость работы системы возрастает в разы, а вероятность падения процессов из-за ожидания данных снижается до минимума.
Рассмотрим критически важные параметры postgresql.conf, которые необходимо изменить при использовании SSD для 1С:
random_page_cost = 1.1. Это укажет планировщику, что случайный доступ к страницам теперь дешевый, и он будет чаще использовать индексы.effective_io_concurrency = 200 (для SSD).autovacuum более агрессивно, чтобы временные таблицы 1С вовремя очищались: autovacuum_vacuum_scale_factor = 0.01.Важно: Не используйте fsync = off на рабочих серверах, это может привести к полной потере данных при сбое питания. Вместо этого используйте synchronous_commit = off для ускорения записи.
В релизах платформы 8.3.15 была замечена ошибка: при выполнении регламентного задания "Обновление агрегатов" оборотного регистра накопления процесс rphost мог аварийно завершаться. Посмотрим, есть ли у вас активные агрегаты. Если вылеты происходят в моменты минимальной активности пользователей, попробуйте временно отключить использование агрегатов для проблемных регистров или само регламентное задание.
Таким образом, мы проанализировали основные причины нестабильности. Сочетание перехода на SSD, обновления внешних компонент и тонкой настройки кластера позволяет добиться стабильной работы 1С 8.3.15 на PostgreSQL даже при большом количестве пользователей в нагруженных конфигурациях.