Рассмотрим достаточно распространенную и неприятную ситуацию, с которой сталкиваются администраторы баз данных и специалисты по 1С. При попытке авторизации пользователя в информационной базе система прерывает работу, выдавая следующее сообщение:
Ошибка при выполнении запроса POST к ресурсу /e1cib/login
Ошибка СУБД: server closed the connection unexpectedly. This probably means the server terminated abnormally before or while processing the request.
При этом проблема может носить "плавающий" характер: иногда вход выполняется успешно, а иногда сеанс обрывается. Проанализируем все возможные причины возникновения этой ошибки в связке платформы 1С:Предприятие и СУБД PostgreSQL, и разберем по шагам, как диагностировать и устранить неисправность.
Давайте подробно разберем механику загрузки сеанса. Ошибка с текстом о неожиданном закрытии соединения со стороны сервера СУБД часто вводит в заблуждение: кажется, что проблема кроется исключительно на сервере баз данных или в нехватке серверной оперативной памяти. Однако на практике корень проблемы часто находится на стороне клиентского рабочего места.
Посмотрим на процесс запуска. Загрузка конфигурации в сеансе происходит в оперативную память клиента. Современные типовые конфигурации (например, Бухгалтерия предприятия 3.0 и решения на ее базе) имеют внушительный объем метаданных. Если на компьютере пользователя установлено 32-битное клиентское приложение 1С, его процесс физически не способен адресовать более 2 (или 4, в зависимости от настроек ОС) гигабайт оперативной памяти.
Выясним причину обрыва: когда 32-битный клиент исчерпывает доступный ему лимит памяти при обработке тяжелого запроса на логин, процесс клиента просто "падает" или зависает. Сервер 1С (процесс rphost), не получая ответа от клиента, расценивает это как аварийное завершение и закрывает соединение. В свою очередь, обрывается и связь с PostgreSQL. При этом количество свободной оперативной памяти на самом сервере (даже если свободно 12 Гб из 32 Гб) не имеет никакого значения.
Что мы сделаем для исправления:
Проанализируем еще один важный аспект, влияющий на потребление памяти при старте. Если ваша информационная база была "снята с замка" (то есть включена возможность изменения конфигурации), механизм кэширования и загрузки метаданных меняет свое поведение.
Загружаемая конфигурация, снятая с поддержки, потребляет при инициализации сеанса примерно в два раза больше оперативной памяти по сравнению с конфигурацией на полной поддержке. Это означает, что даже относительно небольшая конфигурация может легко исчерпать лимиты 32-битного клиента, что приведет к ошибке /e1cib/login.
Чтобы точно убедиться, что проблема заключается именно в падении клиентских сеансов, а не в глобальном сбое сервера, обратимся к технологическому журналу 1С. Разберем ситуацию на примере наличия фоновых заданий.
В большинстве типовых баз постоянно работают регламентные и фоновые задания (они запускаются под системным пользователем, например, DefUser). Посмотрим в логи технологического журнала: если мы видим, что фоновые задания выполняются штатно и без обрывов, а прерываются исключительно интерактивные сеансы пользователей (при попытке логина), это стопроцентно подтверждает гипотезу о проблемах на стороне клиентского окружения или сети, а не СУБД.
Если перевод на 64-битную платформу не помог, проанализируем состояние самой СУБД. Сообщение "server closed the connection unexpectedly" напрямую генерируется PostgreSQL. Рассмотрим, почему это происходит на уровне базы данных:
/var/log/messages или /var/log/syslog), чтобы найти следы работы OOM Killer.pg_log).Очень часто проблема скрыта во внедренном программном коде. Рассмотрим влияние расширений конфигурации. При авторизации пользователя 1С инициализирует все подключенные расширения. Если расширение (особенно с назначением "Адаптация") содержит ошибки в модулях, исполняемых при старте сеанса (например, в модуле сеанса или модуле управляемого приложения), обработка запроса POST к ресурсу /e1cib/login завершится критическим сбоем. Для оперативного отключения и диагностики проблемных модулей подойдёт обработка для управления и массовых операций с расширениями 1С.
Как мы проверим эту гипотезу:
Рассмотрим внешние факторы, которые часто игнорируются администраторами.
Блокировка антивирусным ПО: Современные антивирусы с сетевыми экранами и эвристическими анализаторами перехватывают весь сетевой трафик. Процесс авторизации в 1С (POST-запрос) генерирует передачу большого объема сериализованных данных. Антивирус может посчитать такой плотный поток подозрительным и принудительно сбросить соединение на уровне сокетов. Временно отключим защиту конечной точки (Endpoint Security) на клиенте и проверим вход в базу.
Сетевые таймауты (при веб-доступе): Если информационная база опубликована через веб-сервер (IIS или Apache), между клиентом и сервером 1С возникает дополнительное звено. Если база тяжелая, а сервер нагружен, формирование ответа на логин может занять время. Прокси-серверы, балансировщики нагрузки или сам веб-сервер могут закрыть соединение по таймауту ожидания (Timeout), не дождавшись ответа от rphost. Проверим настройки таймаутов на сетевом оборудовании и в конфигурационных файлах веб-сервера.
Не исключаем вероятность повреждения структуры данных внутри самой 1С. Логические ошибки в таблицах профилей групп доступа или таблицах регистрации изменений могут вводить сервер в бесконечный цикл или вызывать фатальную ошибку при формировании контекста пользователя.
Выполним процедуру "Тестирование и исправление информационной базы" в режиме Конфигуратора. Обязательно установим галочки на проверку логической целостности и пересчет итогов. Также полезно очистить локальный кэш на рабочем месте пользователя и сеансовый кэш в кластере серверов 1С, так как поврежденные временные файлы часто являются причиной необъяснимых ошибок на этапе загрузки приложения. При обслуживании нескольких информационных баз регулярную регламентную проверку можно запускать автоматически с помощью программы для автоматического тестирования и обслуживания баз 1С.