Перевод производственной или учетной базы предприятия с коммерческой СУБД Microsoft SQL Server на свободно распространяемую систему управления базами данных PostgreSQL — один из самых частых сценариев при оптимизации расходов на ИТ-инфраструктуру и лицензии. Однако применительно к тяжелым решениям прошлых поколений, таким как «1С:Управление производственным предприятием» (УПП), у администраторов и разработчиков нередко возникают опасения по поводу стабильности и быстродействия. Разберем особенности, реальный опыт эксплуатации и технические требования к работе связки 1С:УПП и PostgreSQL при одновременной работе 25 пользователей.
Проанализируем базовые условия поставленной задачи. Масштаб в 25 активных подключений для платформы 1С считается небольшой или средней нагрузкой. На практике связка УПП и PostgreSQL при таком количестве пользователей демонстрирует стабильные результаты и способна полностью закрыть потребности предприятия без потери производительности, если конфигурация сервера и параметры СУБД подобраны грамотно.
Рассмотрим ключевые аргументы в пользу такого решения:
Выясним причину, по которой нельзя просто установить стандартный дистрибутив PostgreSQL из официального репозитория операционной системы. Стандартный («ванильный») PostgreSQL не содержит специфических доработок, необходимых для механизмов платформы 1С. Для корректного взаимодействия платформы и базы данных необходимо использовать только специализированные сборки СУБД с патчами от фирмы 1С или Postgres Professional.
Обратим внимание на следующие требования к инфраструктуре:
ru_RU.UTF-8), чтобы исключить проблемы с регистрозависимостью и сортировкой строковых полей в коде конфигурации.Разберем один из главных технических нюансов, встречающихся при переносе старых конфигураций вроде УПП на PostgreSQL. В отличие от MS SQL, оптимизатор PostgreSQL может неоптимально обрабатывать прямые соединения виртуальных таблиц срезов первых и последних периодических регистров сведений, если эти таблицы достигают больших объемов.
Посмотрим, как решается эта проблема при возникновении просадок производительности:
РегистрСведений.СрезПоследних, необходимо переписать проблемный запрос, выгрузив срез во временную таблицу перед объединением с остальными данными.Посмотрим на пример рефакторинга проблемного запроса. Допустим, типовой отчет или алгоритм связывает табличную часть документа напрямую со срезом последних цен или курсов валют:
ВЫБРАТЬ
ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура,
ЦеныНоменклатурыСрезПоследних.Цена КАК Цена
ПОМЕСТИТЬ ВТ_Цены
ИЗ
РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, ) КАК ЦеныНоменклатурыСрезПоследних
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
Товары.Ссылка КАК Документ,
Товары.Номенклатура КАК Номенклатура,
ЕСТЬNULL(ВТ_Цены.Цена, 0) КАК Цена
ИЗ
Документ.РеализацияТоваровУслуг.Товары КАК Товары
ЛЕВОЕ СОЕДИНЕНИЕ ВТ_Цены КАК ВТ_Цены
ПО Товары.Номенклатура = ВТ_Цены.Номенклатура
Такой подход гарантирует, что оптимизатор PostgreSQL не уйдет в ресурсоемкое полное сканирование и построит оптимальный план выполнения через Index Scan.
Проанализируем конфигурацию самой УПП. Исторически УПП проектировалась под автоматический режим управления блокировками данных. В среде PostgreSQL автоматический режим часто провоцирует блокировки таблиц целиком при проведении документов и приводит к частым ошибкам ожидания захвата ресурсов и взаимоблокировкам (deadlocks).
Для стабильной многопользовательской работы рекомендуется:
Разберем основные параметры файла postgresql.conf, которые необходимо адаптировать под сервер для 25 пользователей:
shared_buffers: задаем на уровне 25% от общего объема оперативной памяти сервера, чтобы СУБД эффективно кэшировала страницы данных.work_mem: выделяем объем от 32MB до 128MB на каждый узел плана запроса. Это позволит выполнять сортировки в памяти без сброса промежуточных данных на медленный диск.maintenance_work_mem: устанавливаем в диапазоне 512MB–1GB для ускорения операций переиндексации и сбора статистики.random_page_cost: для SSD-накопителей снижаем параметр со стандартного значения 4.0 до 1.1–1.5, чтобы планировщик охотнее использовал индексные сканирования.temp_buffers: увеличиваем значение до 32MB, что ускорит обработку временных таблиц платформы 1С.Выясним причину, по которой база на PostgreSQL может со временем замедляться. Механизм многоверсионности (MVCC) оставляет в таблицах устаревшие версии строк при изменении или перепроведении документов. Чтобы избежать деградации базы, настраиваем следующие процессы:
autovacuum_vacuum_scale_factor = 0.05 и autovacuum_analyze_scale_factor = 0.02), чтобы «мертвые» строки вычищались непрерывно в течение дня.Таким образом, связка 1С:УПП и PostgreSQL на 25 пользователей является полностью рабочей, проверенной практикой и надежной альтернативой MS SQL Server, требующей лишь грамотной предварительной настройки СУБД и точечного контроля за проблемными запросами.