Периодическая недоступность сервера 1С — одна из самых коварных проблем для системного администратора. Ситуация, когда сервер «зависает» без видимых причин несколько раз в месяц или даже в неделю, требует комплексного подхода к диагностике. В данной статье мы разберем конкретный кейс, связанный с платформой 8.3.11, ОС Windows Server 2012 R2 и базой PostgreSQL, а также рассмотрим универсальные методы стабилизации кластера.
Прежде чем приступать к активным действиям, проанализируем исходные данные. Типичная конфигурация, при которой возникают сбои: сервер приложений 1С на Windows, сервер БД на Ubuntu, около 15–20 информационных баз и небольшое количество активных пользователей. Казалось бы, нагрузка невелика, но именно большое количество баз (даже если 90% из них — редко используемые копии) может стать причиной нестабильности.
Выясним причину: каждый раз, когда пользователь пытается подключиться к базе, менеджер кластера 1С (rmngr.exe) и рабочий процесс (rphost.exe) обращаются к конфигурационным файлам и выделяют ресурсы. Если эти ресурсы не освобождаются вовремя или доступ к файлам заблокирован, сервер перестает отвечать на новые запросы.
Рассмотрим первый и самый простой шаг — настройку регламентного перезапуска рабочих процессов. В платформе 1С предусмотрены механизмы самоочистки. Если процессы rphost.exe работают неделями, в них неизбежно накапливаются утечки памяти, связанные с фрагментацией адресного пространства.
Разберем, как это настроить в консоли администрирования кластеров:
Однако, как показывает практика, одного перезапуска часто бывает недостаточно, если проблема кроется в правах доступа или сетевых тайм-аутах.
Когда сервер «ложится» без объяснения причин, единственным достоверным источником информации становится Технологический журнал (ТЖ). Рассмотрим, как его правильно включить, чтобы поймать ошибку, не перегрузив при этом дисковую подсистему.
Создадим файл logcfg.xml в каталоге C:\Program Files\1cv8\conf\ (для 64-битной версии) со следующим содержанием:
<config xmlns="http://v8.1c.ru/7.4/config/log">
<log location="C:\LOGS\1C" history="24">
<event>
<eq property="name" value="EXCP"/>
</event>
<event>
<eq property="name" value="PROC"/>
</event>
<property name="all"/>
</log>
</config>
Этот конфиг будет собирать только исключительные ситуации (EXCP) и информацию о стартах/остановках процессов (PROC). Проанализируем полученные логи. Часто там можно встретить ошибку следующего вида:
Ошибка доступа к файлу: 'C:\ProgramData\1C\1cv8\1cv8conn.pfl' : Access is denied.
Выясним, что это за файл. 1cv8conn.pfl — это профиль подключений, в котором сервер хранит информацию о соответствии информационных баз и рабочих процессов. При каждом новом подключении сервер пытается обновить этот файл или создать его временную копию 1cv8connO.pfl.
Почему возникает ошибка доступа (Access is denied)?
C:\ProgramData\1C\1cv8\ в исключения.ProgramData.1C:Enterprise 8.3 Server Agent, имеет полные права на папку C:\ProgramData\1C\1cv8\. Иногда временным решением является запуск службы под доменным администратором, но с точки зрения безопасности лучше корректно настроить права на уровне NTFS.Проанализируем ситуацию с большим количеством баз. По умолчанию кластер 1С может пытаться запустить слишком много процессов или, наоборот, заставить один процесс обслуживать слишком много соединений. Для 16 баз и небольшого числа пользователей рекомендуется следующая стратегия:
rphost.exe.Рассмотрим нюансы работы Windows Server 2012 R2 в связке с PostgreSQL на Linux. Часто причиной недоступности становятся сетевые «затыки»:
Проблема IPv6: Система может пытаться разрешить имя сервера через протокол IPv6, что приводит к задержкам. Рекомендуется явно прописать IP-адрес сервера PostgreSQL в файле hosts на Windows-сервере или полностью отключить IPv6 в настройках сетевого адаптера.
Параметры TCP KeepAlive: Если соединение между 1С и базой данных простаивает (например, ночью), сетевые экраны или сама ОС могут оборвать «залипшую» сессию. В настройках postgresql.conf на стороне Ubuntu стоит проверить параметры tcp_keepalives_idle. Уменьшение этого значения заставит сервер чаще проверять активность соединения, не давая ему закрыться по тайм-ауту.
Если ваш сервер 1С работает внутри виртуальной машины, обратим внимание на два критических фактора:
1. Динамическая память: Технология Dynamic Memory (особенно в Hyper-V) категорически не рекомендуется для серверов 1С. Когда 1С запрашивает память, а гипервизор пытается «отдать» ее из резервов хоста, возникают микрозадержки, которые сервер приложений 1С воспринимает как критический сбой. Используйте только Static RAM.
2. Режим электропитания: По умолчанию в Windows Server может стоять «Сбалансированный» режим. Проанализируем это: при снижении нагрузки процессор сбрасывает частоту. Когда поступает резкий запрос от 1С, процессору требуется время на «пробуждение» ядер, что вызывает тайм-ауты в кластере. Установим режим «Высокая производительность» (High Performance).
Подведем итог нашему исследованию. Для стабилизации сервера 1С 8.3.11 выполним следующие шаги:
C:\ProgramData\1C\1cv8\ и добавим её в исключения антивируса.EXCP.rphost).Применение этих мер в комплексе позволяет практически полностью исключить непредсказуемые падения сервера и обеспечить комфортную работу пользователей.