При эксплуатации клиент-серверного варианта 1С:Предприятия на базе операционных систем семейства Linux (в частности, Debian или Ubuntu) в связке с СУБД PostgreSQL администраторы нередко сталкиваются с ситуацией, когда сервер приложений внезапно перестает пускать новых пользователей. При запуске программы и выборе информационной базы окно зависает с белым экраном еще до появления формы авторизации, в то время как часть уже работающих пользователей продолжает выполнять операции. В консоли кластера при этом скапливается множество дублирующихся «мертвых» сеансов с одних и тех же компьютеров, а попытка завершить их вручную приводит к зависанию самой консоли администрирования.
Разберем по шагам ключевые причины возникновения этой проблемы и рассмотрим комплекс мер по ее полному устранению.
Проанализируем архитектуру взаимодействия компонентов, чтобы понять, из-за чего возникает данная коллизия:
Останавливать выключенные процессы и опция принудительного завершения проблемных процессов работают некорректно. При аварийном или принудительном завершении рабочего процесса rphost менеджер кластера rmngr не успевает освободить связанные сеансы. В результате образуются сеансы-«зомби», а обращение к ним через консоль администрирования вызывает взаимные блокировки (дедлоки) внутри управляющего процесса rmngr./etc/hosts или работа через протокол IPv6 приводит к задержкам на этапе первичного сетевого рукопожатия (handshake), из-за чего клиент висит на стадии открытия соединения.rphost и PostgreSQL, что приводит к периодическим «замираниям» сервера.Первоочередным и наиболее эффективным шагом является обновление сервера 1С и клиентских приложений до стабильного релиза. Ошибки управления памятью и некорректного завершения рабочих процессов кластера, приводившие к падению rmngr при очистке сеансов, были исправлены разработчиками в более поздних сборках (начиная с релизов 8.3.8 и 8.3.9+). Обновление платформы устраняет внутренние утечки и дедлоки на уровне системных библиотек 1С.
Для предотвращения зависания разорванных клиентских сессий необходимо настроить таймауты протокола TCP на уровне операционной системы. Посмотрим, как скорректировать параметры sysctl, чтобы сервер быстрее очищал брошенные соединения.
Откроем конфигурационный файл /etc/sysctl.conf и добавим следующие строки:
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 5
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
Применим изменения без перезагрузки сервера командой:
sudo sysctl -p
Данная настройка заставит стек TCP опрашивать сокет через 300 секунд (5 минут) неактивности и быстро закрывать соединение, если клиент не отвечает, что избавит кластер от скопления сеансов-призраков.
Выясним, как стабилизировать работу процессов самого кластера 1С до момента полного перехода на стабильную платформу или в условиях высокой нагрузки:
cron.Для стабильной работы СУБД PostgreSQL и рабочих процессов 1С рекомендуется отключить режим THP в операционной системе. Выполним команды в терминале:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
Чтобы данные параметры сохранялись после перезагрузки ОС, добавим их вызов в стартовые скрипты системы (например, через /etc/rc.local или конфигурацию sysfs.conf).
Убедимся, что имя сервера Linux корректно резолвится как локально, так и с клиентских рабочих мест. В файле /etc/hosts на сервере 1С имя хоста должно быть четко привязано к его реальному статическому IP-адресу в локальной сети, а не к 127.0.1.1. При необходимости на клиентских машинах под управлением Windows также можно внести статическую запись в файл hosts, чтобы исключить задержки на уровне NetBIOS или DNS-сервера при подключении к кластеру.