Часто в практике системного администрирования 1С возникает ситуация, когда ресурсы ограничены, а задачи растут. Например, когда текущая база работает на лицензионном MS SQL Server, но для новых проектов (таких как переход на 1С:ERP 2.x) лицензий не хватает, и рассматривается вариант использования бесплатного PostgreSQL. В этой статье мы подробно разберем, насколько жизнеспособна схема "все на одной тачке", какие риски она несет и как правильно настроить такой "зоопарк", чтобы сервер не превратился в "тыкву".
Начнем с главного: технически запустить 1С:Предприятие, MS SQL Server и PostgreSQL на одной операционной системе Windows вполне возможно. Эти службы используют разные порты по умолчанию (1433 для MS SQL и 5432 для PostgreSQL), поэтому конфликтов на уровне сетевых соединений не возникнет. Однако основная проблема кроется не в портах, а в беспощадной борьбе за ресурсы: оперативную память, процессорное время и дисковые операции.
Рассмотрим ситуацию, когда у нас уже есть работающая связка 1С и MS SQL 2008. Автор темы планирует добавить PostgreSQL для новой базы ERP 2.x. Здесь важно понимать, что современные версии ERP требуют актуальных платформ (например, 8.3.24 и выше), которые могут иметь ограниченную совместимость с устаревшим MS SQL 2008. Использование второй СУБД кажется логичным выходом, но оно требует "ювелирной" настройки.
Проанализируем поведение СУБД. По умолчанию MS SQL Server спроектирован так, чтобы захватить всю доступную оперативную память сервера под свой Buffer Pool. Если на этой же машине запущен PostgreSQL, он также будет пытаться использовать кэш операционной системы для работы с данными. В результате возникнет ситуация, когда одна СУБД вытесняет другую в файл подкачки (Swap), что приводит к катастрофическому падению производительности.
Выясним, как это предотвратить. Нам необходимо жестко ограничить аппетиты MS SQL Server. Разберем по шагам:
Maximum server memory (in MB). Например, если у сервера 128 ГБ ОЗУ, мы можем выделить 48 ГБ под MS SQL, 48 ГБ под PostgreSQL, а остальное оставить для ОС и рабочих процессов rphost.Для PostgreSQL ситуация на Windows сложнее. В отличие от Linux, PostgreSQL под Windows не может эффективно работать с очень большими значениями shared_buffers. Опытным путем установлено, что для Windows-версий оптимально выделять под shared_buffers от 512МБ до 2ГБ, так как PostgreSQL в этой ОС больше полагается на системный кэш файлов. Это означает, что Windows будет пытаться кэшировать файлы базы Postgres в той памяти, которая "свободна" от MS SQL.
Когда две тяжелые СУБД и сервер 1С начинают одновременно выполнять сложные запросы (например, расчет себестоимости в ERP), планировщик Windows может не справиться с оптимальным распределением нагрузки. Посмотрим, как можно изолировать ресурсы процессора.
В настройках MS SQL Server можно задать Affinity Mask, чтобы СУБД использовала только определенные ядра процессора. Аналогично, если запустить несколько экземпляров сервера 1С, их можно "привязать" к разным ядрам через диспетчер задач или специализированные утилиты. Рассмотрим пример логического разделения на 16-ядерном процессоре:
rmngr, rphost) и нужды ОС.Это самый критичный момент. Использование одного физического SSD (и тем более HDD) для двух разных СУБД приведет к огромным очередям диска. У MS SQL и PostgreSQL разные алгоритмы записи логов транзакций и данных. Проанализируем ситуацию: если обе базы начнут активно писать логи на один диск, производительность упадет в разы.
Рекомендация: Используйте как минимум разные физические (не логические!) диски для:
tempdb для MS SQL и временные файлы 1С).Разберем опасения автора по поводу ERP 2 и MS SQL 2008. Хотя платформа 1С официально поддерживает MS SQL 2005 SP3 и выше, работа тяжелой конфигурации ERP 2.5 на MS SQL 2008 — это рискованное занятие. Современные механизмы запросов 1С оптимизированы под более новые версии SQL (2016+), которые умеют лучше работать с индексами и планами запросов. Использование PostgreSQL в данном случае может быть оправдано, так как свежие версии Postgres Pro (адаптированные для 1С) работают гораздо эффективнее с новыми метаданными платформы 8.3.
Посмотрим на конфигурацию кластера. Чтобы разные базы работали на разных СУБД, нам не обязательно ставить два разных сервера 1С. В консоли администрирования 1С:Предприятие при создании новой информационной базы мы просто указываем тип СУБД. Например:
MS SQL Server, сервер — localhost.PostgreSQL, сервер — localhost.Если же вы решите использовать разные версии платформы 1С для этих баз, придется устанавливать несколько служб Агент сервера 1С. Разберем, как это сделать через командную строку:
sc create "1C:Enterprise 8.3.24 Server" binPath= "\"C:\Program Files\1cv8\8.3.24.1150\bin\ragent.exe\" -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d \"C:\1C_Data\8.3.24\""
Здесь важно использовать разные порты (например, стандартные 1540, 1541 и альтернативные 1640, 1641), чтобы службы не конфликтовали.
Не забывайте, что "зоопарк" СУБД требует двойного обслуживания. Для MS SQL вам понадобятся планы обслуживания (Maintenance Plans) или скрипты для дефрагментации индексов и обновления статистики. Для PostgreSQL критически важно настроить VACUUM и ANALYZE, иначе база 1С быстро раздуется и начнет тормозить.
Рассмотрим важный нюанс: PostgreSQL под Windows чувствителен к антивирусам. Обязательно добавьте каталоги данных обеих СУБД и процессы postgres.exe, sqlservr.exe, rphost.exe в исключения сканирования.
Подводя итог, можно сказать: схема рабочая, если у вас есть избыток ресурсов (минимум 64-128 ГБ ОЗУ и быстрые NVMe накопители). Однако, как правильно заметили специалисты в обсуждении, лучше выбрать одну СУБД, которую вы умеете "готовить". Если MS SQL уже есть и его ресурсов хватает, возможно, проще обновить его версию. Если же лицензионные ограничения непреодолимы — настраивайте жесткую изоляцию ресурсов для каждой СУБД, как мы разобрали выше.