При администрировании серверов 1С на базе PostgreSQL часто возникает задача создания тестовой среды на том же физическом или виртуальном сервере, где находится рабочая база. Основные сложности здесь связаны с разделением ресурсов, выбором метода копирования данных и пониманием того, как СУБД взаимодействует с оперативной памятью Linux. Разберем пошагово, как организовать эффективную работу нескольких экземпляров баз данных и оптимизировать их производительность.
Рассмотрим ситуацию, когда использование одного инстанса (кластера) для рабочей и тестовой баз становится неудобным. Основная проблема заключается в том, что инструменты типа pg_basebackup работают на уровне всего кластера, копируя все базы сразу. Чтобы изолировать тестовую среду, мы рекомендуем создать второй инстанс (кластер) PostgreSQL.
Вопреки распространенному заблуждению, в дистрибутивах на базе Ubuntu/Debian (включая Postgres Pro) для этого не нужно собирать СУБД из исходников. Проанализируем стандартный механизм управления кластерами:
pg_createcluster. Она позволяет создать новый независимый экземпляр СУБД с собственным каталогом данных и конфигурационными файлами.Для создания нового кластера версии 15 выполним команду в терминале:
sudo pg_createcluster 15 test --port=5433 --datadir=/var/lib/postgresql/15/test
Это позволит нам останавливать, перезапускать и даже обновлять тестовый сервер, не затрагивая работу основного приложения 1С.
Выясним, какой способ переноса данных из рабочей базы в тестовую является наиболее надежным. Традиционный pg_dump иногда вызывает ошибки в 1С из-за специфических расширений (например, mchar) или особенностей индексов. Проанализируем доступные альтернативы:
1. Использование pg_probackup. Поскольку мы работаем с Postgres Pro, логично использовать их фирменную утилиту. В отличие от pg_basebackup, она позволяет восстанавливать конкретную базу или использовать инкрементальное резервное копирование, что значительно экономит место на диске.
2. Выгрузка и загрузка через файл .dt. Рассмотрим этот метод как самый «чистый» с точки зрения логики 1С. Выгрузка из консоли администрирования или конфигуратора гарантирует, что структура данных будет перестроена корректно. Это особенно актуально, если рабочая база имеет большой объем (более 30–50 Гб), так как при загрузке .dt происходит автоматическое сжатие и переиндексация.
3. Копирование на уровне файловой системы (ZFS/LVM). Если ваша ОС поддерживает снапшоты (мгновенные снимки), это самый быстрый способ. Мы делаем snapshot тома с данными рабочей базы и монтируем его для тестового инстанса. Это занимает секунды вне зависимости от размера базы.
Часто системные администраторы, перешедшие с MS SQL Server, пугаются, когда видят, что процесс postgres занимает всего 500 МБ при размере базы в 30 Гб. Разберем причину такого поведения. В отличие от MS SQL, который старается забрать всю доступную память под свой Buffer Pool, PostgreSQL использует архитектуру двойного кэширования.
Shared Buffers — это собственная память PostgreSQL, куда он загружает наиболее часто используемые страницы данных. Если в postgresql.conf этот параметр установлен в небольшое значение, процесс будет потреблять мало памяти в top или htop.
OS Page Cache — это системный кэш Linux. PostgreSQL намеренно полагается на операционную систему для кэширования файлов данных. Таким образом, если на сервере 64 Гб RAM, а под shared_buffers выделено 8 Гб, остальные гигабайты Linux автоматически использует для кэширования файлов базы. Эта память отображается как «cached» или «buff/cache» в системе, а не как занятая процессом СУБД.
Проанализируем ключевые параметры в файле postgresql.conf, которые критически важны для стабильной работы 1С. Стандартные скрипты автонастройки часто упускают специфику платформы 1С:
off, так как 1С не поддерживает этот механизм и он может вызывать ошибки доступа.Пример настройки важных параметров:
# Основные параметры оптимизации
shared_buffers = 8GB
work_mem = 64MB
max_locks_per_transaction = 256
escape_string_warning = off
standard_conforming_strings = off
row_security = off
Для создания тестовой среды на одном сервере с рабочей базой наиболее грамотным подходом будет развертывание второго инстанса через pg_createcluster. Это обеспечит надежную изоляцию и гибкость управления. Что касается оперативной памяти — не стоит ориентироваться только на потребление процесса postgres; следите за общим показателем свободного кэша в Linux. Правильная настройка shared_buffers и специфических для 1С параметров позволит добиться производительности, сравнимой или превосходящей MS SQL Server.