← На главную

Одной из наиболее неприятных проблем при администрировании серверов 1С на базе PostgreSQL является внезапное прерывание работы пользователей с ошибкой «Сеанс отсутствует или удален». В данной статье мы разберем, как локализовать и устранить эту неисправность, опираясь на практический опыт сопровождения серверной инфраструктуры.

Анализ ситуации

Когда вы сталкиваетесь с ошибкой ID=c0ff7e31-e7d1-401e-a2c0-104b86d4d0ce, File=src\ClusterDistribImpl.cpp(1587), это означает, что рабочий процесс rphost, который должен был выполнять вызов, внезапно потерял связь с сеансом пользователя. Чаще всего это происходит из-за принудительного разрыва соединения со стороны сервера или из-за истечения тайм-аутов.

Решение проблемы через параметры информационной базы

Первым делом, прежде чем переустанавливать серверное ПО или глубоко анализировать сетевой трафик, рекомендуем проверить настройки самой информационной базы. Как показывает практика, причиной ошибки может стать некорректное значение «времени жизни» сеанса.

1. Откройте Конфигуратор информационной базы от имени администратора.
2. Перейдите в меню Администрирование, а затем выберите пункт Параметры информационной базы.
3. В открывшемся окне обратите внимание на поле Время завершения спящего сеанса.
4. Если данное значение установлено слишком малым, система может принудительно «отстреливать» сеансы, которые по каким-то причинам стали неактивными на короткий промежуток времени. Попробуйте увеличить это значение до приемлемого (например, до 3600 секунд или более), чтобы дать пользователям и фоновым заданиям запас по времени на выполнение операций.

Дополнительные факторы, требующие внимания

Если настройка тайм-аута сеанса не помогла, необходимо комплексно проанализировать состояние инфраструктуры. Рассмотрим, что еще может приводить к сбоям:

1. Конфликт регламентных заданий и планировщика

Часто в консоли администрирования 1С видно, что активны процессы «Планировщика заданий». Если в это время тяжелые регламентные операции (например, обновление полнотекстового поиска или расчеты по закрытию месяца) пересекаются с активной работой пользователей, возникают длительные блокировки таблиц базы данных. В таких случаях сервер 1С может завершить сеанс, чтобы предотвратить зависание всей системы.

2. Ограничения ресурсов оперативной памяти

Рабочий процесс rphost очень чувствителен к лимитам памяти. Если в настройках кластера серверов 1С параметры «Безопасный расход памяти за один вызов» или «Объем памяти рабочих процессов до перезапуска» установлены слишком жестко, процесс будет постоянно «падать» и перезапускаться, что мгновенно аннулирует все текущие сеансы.

3. Сетевое взаимодействие

Если вы используете связку 1С и PostgreSQL на разных физических серверах, любые микро-разрывы сетевого соединения или высокая задержка (latency) будут критичны. Платформа 1С ожидает стабильного ответа от СУБД, и если время ожидания превышено, сеанс помечается как удаленный.

Как диагностировать причину с помощью технологического журнала?

Чтобы точно понять, что происходит в момент ошибки, настройте Технологический журнал. Проанализируйте события EXCP (исключения) и CONN (соединения). В логах вы сможете найти стек вызовов, который укажет на конкретную точку отказа: будь то ошибка доступа к файлу, нехватка памяти или ошибка выполнения конкретного SQL-запроса на стороне сервера PostgreSQL.

Рекомендация: Всегда следите за соответствием версии СУБД PostgreSQL (особенно специфических сборок для 1С) версии вашей платформы 1С:Предприятие. Использование устаревших или несовместимых версий — одна из самых частых скрытых причин нестабильной работы кластера серверов.

Начните с простого — проверки настроек спящих сеансов в конфигураторе, и только при отсутствии результата переходите к анализу логов и оптимизации ресурсов сервера.