При эксплуатации крупных информационных систем нередко возникает ситуация, называемая в среде администраторов «зоопарком»: когда один сервер приложений 1С вынужден одновременно обслуживать базы данных, работающие на разных системах управления базами данных (СУБД) — например, Microsoft SQL Server (MSSQL) и PostgreSQL. Рассмотрим ситуацию, когда после добавления базы PostgreSQL в кластер, работающий с MSSQL, пользователи начинают жаловаться на «мертвые» зависания системы, которые устраняются только перезапуском службы. Выясним причины этого явления и разберем по шагам, как правильно настроить сервер, чтобы обеспечить стабильность обеих систем.
Разберем ситуацию с точки зрения архитектуры платформы 1С. Когда в рамках одного рабочего процесса rphost обслуживаются базы разных типов, этот процесс вынужден одновременно загружать в свою адресную память разные клиентские библиотеки (драйверы): sqlncli.dll для работы с MSSQL и libpq.dll для работы с PostgreSQL. Проанализируем, почему это приводит к проблемам:
Самый быстрый, но компромиссный способ — это разнесение баз по разным рабочим процессам. По умолчанию 1С стремится распределить нагрузку равномерно, и в один rphost могут попасть сеансы как от MSSQL, так и от PG. Мы можем принудительно ограничить это поведение.
Рассмотрим, как это сделать через консоль администрирования кластера:
rphost.Внимание: У этого метода есть существенный минус — потребление оперативной памяти. Каждый процесс rphost потребляет значительный объем ОЗУ при старте. Если у вас десятки баз, серверу может просто не хватить ресурсов. Также помните об ограничениях лицензии уровня ПРОФ (не более 12 ядер процессора на один сервер приложений).
Наиболее надежный и профессиональный метод — это запуск нескольких независимых экземпляров службы 1С (сервисов Windows) на одном физическом сервере. Разделим базы по типам СУБД: одну службу выделим под MSSQL, вторую — под PostgreSQL.
Для создания второй службы выполним следующие шаги:
sc create или специализированные скрипты для регистрации нового экземпляра ragent.exe.-d, чтобы указать отдельный путь к реестру кластера (например, "C:\Program Files\1cv8\srvinfo_pg"). Это исключит пересечение кэшей и настроек.Пример строки запуска для второй службы в реестре или через командную строку:
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\ragent.exe" -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d "C:\Program Files\1cv8\srvinfo_custom"
Такой подход гарантирует, что любые проблемы (утечки памяти, зависания драйвера), возникшие в «мире PostgreSQL», физически не смогут затронуть рабочие процессы, обслуживающие MSSQL, так как они будут управляться разными процессами ragent и rmngr.
В ходе обсуждения выяснилось, что лишнюю нагрузку и память может потреблять встроенный механизм — Дата-акселератор (DBDA). Это In-Memory СУБД, которая часто включена по умолчанию в настройках кластера, но фактически не используется без лицензий КОРП и специальных настроек.
Выясним, как снизить нагрузку:
Если вы не используете механизм копий баз и аналитические отчеты на базе акселератора, рекомендуется отключить этот компонент. Сделать это можно либо при установке платформы (сняв галочку с соответствующего модуля), либо через файл конфигурации conf.cfg, ограничив запуск лишних процессов. В высоконагруженных системах «чистота» запущенных модулей — залог стабильности.
Проанализируем ситуацию с выбором ОС для PostgreSQL. В сообществе 1С-администраторов считается аксиомой, что PostgreSQL на ОС Windows работает менее стабильно и медленнее, чем на Linux. Рассмотрим основные причины:
Совет: Если есть возможность, вынесите PostgreSQL на отдельный сервер под управлением Linux. Это снимет нагрузку с основного Windows-сервера и решит проблему конфликтов драйверов на уровне сервера приложений 1С.
Подведем итог нашему разбору. «Зоопарк» из СУБД в одном кластере 1С жить может, но требует ручной настройки и разделения ресурсов. Чтобы избежать зависаний:
rphost для одновременного обслуживания MSSQL и PostgreSQL.