В процессе развития ИТ-инфраструктуры предприятия администраторы часто сталкиваются с аппаратными и лицензионными ограничениями бесплатных версий проприетарного программного обеспечения. Типичный пример — использование СУБД MS SQL Server Express совместно с платформой 1С:Предприятие. Когда объем баз растет, а производительность падает, встает вопрос о переходе на альтернативные бесплатные решения, такие как PostgreSQL. Рассмотрим подробно, можно ли совмещать эти СУБД на одном сервере, с какими скрытыми проблемами можно столкнуться и как правильно настроить систему для максимальной производительности.
Начнем с главного вопроса: можно ли установить PostgreSQL на сервер, где уже запущен и активно работает MS SQL Server?
Да, совместная установка абсолютно безопасна и не вызовет прямых системных конфликтов. Обе СУБД функционируют как независимые службы операционной системы и используют разные сетевые порты по умолчанию:
1433.5432.Благодаря этому сетевые запросы к базам данных не будут пересекаться. Вы можете запустить обе службы одновременно, настроить PostgreSQL, развернуть на нем тестовые базы, проверить их работоспособность и лишь затем деактивировать или полностью удалить MS SQL Server. Однако бесконфликтность на уровне сетевых портов не означает отсутствие борьбы за ресурсы сервера (оперативную память, процессорное время и дисковую активность). Рассмотрим сопутствующие факторы, которые требуют обязательного анализа.
Проанализируем конфигурацию сервера, описанную в теме: 20 активных пользователей, базы общей сложностью более 7 ГБ (Бухгалтерия предприятия 3.0, Управление торговлей 11.4, Зарплата и управление персоналом), операционная система Windows 10, 24 ГБ оперативной памяти и бесплатный MS SQL Express. В этой схеме скрыто сразу несколько критических архитектурных ошибок:
sqlservr.exe в диспетчере задач потребляет около 4 ГБ, объясняется затратами на системные нужды (сессии пользователей, CLR, внутренние структуры), но саму базу данных в оперативной памяти он кэшировать свыше установленного лимита не может.rphost (x86) физически не способен адресовать более 4 ГБ виртуальной памяти (на практике падает при достижении 3–3.5 ГБ). Для решения проблемы обязателен переход на 64-разрядную версию сервера 1С.Переход на PostgreSQL требует детальной предварительной подготовки. Нельзя просто скачать стандартный дистрибутив с официального сайта СУБД и запустить его. Рассмотрим ключевые правила успешного развертывания:
Стандартные настройки PostgreSQL по умолчанию ориентированы на запуск СУБД на слабых компьютерах с минимальным объемом ресурсов. Если оставить конфигурацию по умолчанию, производительность 1С будет крайне низкой. Разберем основные параметры файла postgresql.conf, которые необходимо адаптировать под имеющиеся у автора 24 ГБ оперативной памяти (с учетом совместной работы ОС, сервера 1С и СУБД на одной физической машине):
Для редактирования конфигурационного файла найдем параметры и зададим следующие значения:
# Пример базовой настройки postgresql.conf для сервера с 24 ГБ ОЗУ,
# где также запущен сервер приложений 1С
listen_addresses = '*'
port = 5432
# Выделим под кэш СУБД около 25% от доступной памяти (порядка 5-6 ГБ)
shared_buffers = 6GB
# Объем памяти для сортировки и сложных запросов на одно подключение
work_mem = 64MB
# Объем памяти для сервисных операций (индексация, очистка VACUUM)
maintenance_work_mem = 1536MB
# Оценка операционной системе доступного дискового кэша (около 50-60% от ОЗУ)
effective_cache_size = 14GB
# Максимальное количество одновременных подключений
max_connections = 500
# Настройки планировщика для оптимизации запросов 1С
random_page_cost = 1.1
effective_io_concurrency = 200 # только если базы находятся на SSD
Разберем назначение этих настроек подробнее:
shared_buffers — определяет объем оперативной памяти, используемый PostgreSQL для совместного кэширования данных. Слишком высокое значение на Windows может ухудшить работу из-за двойного кэширования (СУБД и ОС). Оптимально держать его в пределах 20-25% от общего объема памяти.work_mem — объем памяти, выделяемый для выполнения одной операции сортировки или группировки внутри одного запроса. Если запросу не хватает этого объема, данные начинают сбрасываться на медленный диск. Но будьте осторожны: если у вас 20 активных пользователей и каждый запустит сложный отчет с множеством подзапросов, потребление памяти умножится на количество активных сессий. Значение 64MB является безопасным стартовым балансом.effective_cache_size — подсказка для планировщика запросов о том, сколько оперативной памяти доступно под кэширование файлов в самой операционной системе. Помогает планировщику принимать решение о целесообразности использования индексов.random_page_cost — коэффициент стоимости произвольного чтения страниц с диска. По умолчанию равен 4.0 (оптимально для медленных HDD). Поскольку базы переносятся на быстрый SSD, этот параметр необходимо снизить до 1.1–1.5. Это заставит планировщик чаще и эффективнее использовать индексы.Скорость дисковой подсистемы напрямую определяет общую отзывчивость баз 1С. Перенос баз данных на быстрый твердотельный накопитель (SSD) является обязательным условием комфортной работы.
В MS SQL Server критически важную роль играет база временных таблиц tempdb. В PostgreSQL аналогом выступают временные таблицы, создаваемые непосредственно в рабочих базах, а ключевой точкой дисковой нагрузки становится каталог журналов транзакций (предварительной записи) — pg_wal (Write-Ahead Logging).
Для достижения максимального быстродействия СУБД PostgreSQL рекомендуется разделять дисковые потоки чтения и записи по шагам:
pg_wal вынесите на отдельный физический накопитель или создайте для него символическую ссылку (Symlink) на выделенный скоростной диск. Это позволит разгрузить основной накопитель с базой данных от постоянных синхронных операций записи транзакций.Важнейшее предупреждение участников форума: «Резервное копирование и восстановление на PG обязательно отработайте в сторонке. Это вам не MS SQL». Действительно, в MS SQL Express резервные копии настраиваются через планировщик Windows простым скриптом резервного копирования баз. В PostgreSQL подход к бэкапам отличается.
Категорически не рекомендуется использовать штатную выгрузку баз в формат .dt средствами конфигуратора 1С для ежедневного автоматического бэкапа рабочей базы. Этот процесс полностью блокирует работу пользователей, монополизирует ресурсы процессора и часто завершается аварийными ошибками на базах объемом более 5–10 ГБ.
Для резервного копирования баз на PostgreSQL мы можем использовать два основных инструмента:
@echo off
SET PG_ENV_VAR_CHECK=TRUE
SET PGPASSWORD=ВашПарольПользователяPostgres
"C:\Program Files\PostgresPro\15\bin\pg_dump.exe" -h localhost -p 5432 -U postgres -F c -b -v -f "D:\Backup\UT_backup.backup" ИмяБазыДанных1С
Перед переносом рабочей базы обязательно проведите тестовое восстановление бэкапа на другом компьютере, чтобы убедиться в целостности архивов и правильности выполнения скриптов.
Резюмируя все вышесказанное, составим четкий алгоритм действий по переходу на новую СУБД:
5432).postgresql.conf, внесите изменения в параметры памяти (shared_buffers, work_mem, effective_cache_size) и перезапустите службу PostgreSQL..dt..dt (Администрирование -> Загрузить информационную базу...).pg_dump.