Переход на импортонезависимый стек, такой как Astra Linux и Postgres Pro, — это не просто смена одной СУБД на другую. Это смена парадигмы работы с данными. В отличие от MS SQL Server, PostgreSQL требует более тонкой настройки как самой базы данных, так и операционной системы. Разберем основные нюансы производительности, с которыми сталкиваются специалисты при миграции 1С.
Проанализируем первый важный аспект: выбор ОС. PostgreSQL исторически разрабатывался под Unix-подобные системы. На практике работа СУБД на Linux показывает прирост производительности в 1.4–2 раза по сравнению с Windows на том же железе. Это связано с тем, как Linux управляет процессами и файловой системой. В частности, Linux эффективнее работает с огромным количеством мелких файлов, которые создает PostgreSQL (каждая таблица и индекс — это отдельный файл, а иногда и несколько).
Важный нюанс: в Windows работа с памятью и дисковым кэшем организована иначе, что часто приводит к деградации производительности при высокой нагрузке на запись. Поэтому для промышленной эксплуатации 1С связка с Linux является обязательной.
Рассмотрим шаги по подготовке операционной системы. Стандартные настройки «из коробки» не подходят для высоконагруженной СУБД. Выясним, какие параметры ядра критичны:
deadline или none. Это минимизирует накладные расходы на сортировку запросов ввода-вывода.Посмотрим на ключевые настройки самого postgresql.conf. Планировщик Postgres сильно отличается от MS SQL — он опирается на стоимостную модель. Если параметры стоимости заданы неверно, система решит, что прочитать всю таблицу целиком (Sequential Scan) быстрее, чем использовать индекс.
Разберем основные параметры:
random_page_cost: Для современных SSD установите значение 1.1 (вместо стандартных 4.0). Это скажет планировщику, что случайное чтение почти так же эффективно, как последовательное.jit: В новых версиях (11+) включена JIT-компиляция. Для 1С её лучше отключить (jit = off), так как время на компиляцию коротких запросов 1С часто превышает время их выполнения.autovacuum: PostgreSQL использует механизм MVCC (многоверсионность). При изменении данных старые версии строк остаются в базе. Если autovacuum не успевает их вычищать, база «раздувается» и замедляется. Настройте агрессивную очистку для таблиц с интенсивным обновлением.Выясним, почему типовые запросы могут работать медленно. PostgreSQL чувствителен к структуре метаданных 1С. Разберем основные «болевые точки»:
PostgreSQL не всегда эффективно обрабатывает соединения с подзапросами или сложными виртуальными таблицами (СрезПоследних, Остатки). Рассмотрим пример: в MS SQL запрос к срезу последних на каждую строку основного запроса может отработать быстро, но в Postgres это может привести к катастрофическому замедлению.
Решение: заменяйте подзапросы на временные таблицы. Проанализируем правильный подход:
// Плохо: соединение с виртуальной таблицей в одном запросе
ВЫБРАТЬ
Продажи.Номенклатура,
Цены.Цена
ИЗ
РегистрНакопления.Продажи КАК Продажи
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, ) КАК Цены
ПО Продажи.Номенклатура = Цены.Номенклатура
// Хорошо: сначала выгружаем срез во временную таблицу
ВЫБРАТЬ
Цены.Номенклатура,
Цены.Цена
ПОМЕСТИТЬ ВТ_Цены
ИЗ
РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, ) КАК Цены;
ВЫБРАТЬ
Продажи.Номенклатура,
ВТ_Цены.Цена
ИЗ
РегистрНакопления.Продажи КАК Продажи
ЛЕВОЕ СОЕДИНЕНИЕ ВТ_Цены КАК ВТ_Цены
ПО Продажи.Номенклатура = ВТ_Цены.Номенклатура
Важно помнить, что начиная с PostgreSQL 15 и последних релизов платформы 1С, работа с временными таблицами стала эффективнее благодаря ведению онлайн-статистики. Однако их все равно нужно индексировать, если планируется дальнейшее соединение.
Автор вопроса упоминал блокировки на всю таблицу. В современных версиях 1С и Postgres при использовании управляемых блокировок эта проблема практически нивелирована. PostgreSQL использует row-level locking (блокировку на уровне строк). Однако, если ваша конфигурация все еще использует автоматический режим блокировок, конфликтов будет значительно больше, чем в MS SQL. Переход на управляемые блокировки — обязательное условие комфортной работы.
В отличие от MS SQL, где достаточно настроить rebuild index, в Postgres критически важна актуальность статистики. Планировщик Postgres принимает решение о методе выполнения запроса на основе данных ANALYZE. Если данные в таблице сильно изменились (например, после массовой загрузки), а статистика не обновилась, запрос может «повиснуть».
Рекомендуем настроить регламентное задание 1С или скрипт на уровне ОС, который будет выполнять ANALYZE для наиболее нагруженных таблиц несколько раз в день, не дожидаясь ночного обслуживания.
Если вы используете версию Postgres Pro Enterprise, обратите внимание на специфические инструменты:
Transaction ID Wraparound, которая в обычном Postgres может привести к остановке базы для профилактики.Подводя итог, можно сказать: связка 1С и PostgreSQL абсолютно работоспособна и стабильна при условии, что системный администратор настроил ОС (отключил THP, поправил swappiness), а разработчик оптимизировал тяжелые запросы, отказавшись от вложенных соединений в пользу временных таблиц с индексами.