Почему Postgres Pro 1C показывает лучшие результаты в тестах, чем MSSQL, и как правильно оптимизировать работу СУБД

В сообществе администраторов и разработчиков 1С долгое время доминировало мнение, что Microsoft SQL Server является безальтернативным лидером по производительности для систем на платформе 1С:Предприятие. Однако с выходом специализированных сборок Postgres Pro 1C ситуация начала меняться. Рассмотрим случай, когда в однопоточном тесте (так называемом «тесте Гилева») Postgres Pro обошел MSSQL на операционной системе Windows, и разберем технические причины этого явления, а также подводные камни, с которыми можно столкнуться при эксплуатации.

Анализ результатов тестирования на «домашнем» железе

Проанализируем ситуацию: на процессоре Intel Core i5-11600K с быстрым NVMe-накопителем Samsung 980 Pro СУБД Postgres Pro 14.4 показала результат в 49 «попугаев», в то время как настроенный по рекомендациям ИТС Microsoft SQL Server 2019 выдал лишь 36. Почему это происходит?

Разберем основные причины превосходства Postgres Pro в синтетических тестах:

1. Специфические патчи сборки 1C: В отличие от стандартного PostgreSQL, версия Postgres Pro 1C содержит оптимизации, разработанные совместно с инженерами «1С». Это касается в первую очередь работы с временными таблицами, которые 1С использует очень интенсивно. В MSSQL создание временных таблиц — операция довольно «дорогая» с точки зрения системных ресурсов tempdb.
2. Накладные расходы MSSQL: Microsoft SQL Server — это мощная промышленная система, ориентированная на параллельную обработку огромных массивов данных. На «бытовом» железе и в однопоточных задачах его внутренние механизмы управления (планировщик потоков, управление памятью) создают избыточный оверхед (overhead), который снижает скорость в простых тестах.
3. Агрессивность планировщика: Postgres в версии 14 и выше стал гораздо быстрее строить планы для простых запросов, в то время как MSSQL тратит больше времени на попытку найти «идеальный» план выполнения.

Влияние настроек параллелизма (MAXDOP)

Выясним роль настроек многопоточности. Для MSSQL стандартной рекомендацией ИТС является установка параметра MAXDOP = 1 (ограничение параллелизма для одного запроса), чтобы избежать блокировок и взаимного влияния запросов в высоконагруженных системах. В Postgres Pro по умолчанию настройки могут позволять планировщику задействовать больше ядер для выполнения операций (например, max_parallel_workers_per_gather).

Однако, как показывает практика, простое изменение MAXDOP в MSSQL редко позволяет догнать Postgres в однопоточном тесте, так как проблема кроется в самой архитектуре обработки запросов 1С. Рассмотрим подробнее, как Postgres работает на Windows: в этой ОС он эмулирует процессы через потоки, что исторически считалось менее эффективным, чем в Linux, но последние версии Postgres Pro нивелировали это отставание для задач 1С.

Проблема износа NVMe и механизм записи логов

Важным аспектом при выборе Postgres Pro является его взаимодействие с дисковой подсистемой. Разберем предупреждение о «качестве жизни» SSD. Postgres использует механизм WAL (Write Ahead Logging). При неправильной настройке возникает эффект Write Amplification (усиление записи).

Чтобы ваш NVMe-накопитель не исчерпал ресурс за считанные месяцы, проанализируем следующие параметры в postgresql.conf:

• max_wal_size: Увеличение этого параметра позволяет реже выполнять контрольные точки (checkpoints).
• checkpoint_completion_target: Установите значение 0.9, чтобы «размазать» запись данных на диск и избежать пиковых нагрузок на контроллер SSD.
• full_page_writes: Хотя отключение этого параметра ускоряет тесты, делать это в рабочей базе категорически нельзя, так как это приведет к потере данных при сбое питания.

Оптимизация кода запросов при переходе на Postgres

Если в тестах Postgres лидирует, то в реальных тяжелых отчетах пользователи часто жалуются на замедление. Выясним причину: планировщик запросов Postgres гораздо чувствительнее к качеству написания кода 1С, чем MSSQL.

Проанализируем типичные ошибки и способы их решения:

1. Многоуровневые циклы в выборках: Как было замечено в обсуждении, сложные вложенные запросы могут приводить к выбору плана Nested Loop (вложенные циклы), который работает крайне медленно на больших объемах данных.
2. Индексация временных таблиц: В MSSQL отсутствие индекса на временной таблице часто компенсируется мощным кэшированием. В Postgres для эффективного соединения таблиц обязательно создавайте индексы в коде 1С:

// Пример оптимизации в 1С
МенеджерВТ = Новый МенеджерВременныхТаблиц;
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = МенеджерВТ;
Запрос.Текст = "ВЫБРАТЬ ... ПОМЕСТИТЬ ВТ_Данные ИЗ ... ;
                ИНДЕКСИРОВАТЬ ПО ВТ_Данные.ПолеКлюч"; // Критически важно для Postgres!
Запрос.Выполнить();

3. Неявные преобразования типов: Проанализируем ситуацию, когда в условии соединения типов данных 1С (например, СправочникСсылка и Строка) происходит неявное приведение. MSSQL может «простить» это, но Postgres выполнит полное сканирование таблицы (Seq Scan) вместо использования индекса.

Скейлинг и работа в многопользовательском режиме

Рассмотрим вопрос масштабируемости. Существует мнение, что после 30–50 активных пользователей Postgres начинает уступать MSSQL. Это связано с тем, что в Postgres каждое подключение — это отдельный процесс ОС. При большом количестве сессий затраты на переключение контекста процессора становятся критическими.

Для решения этой проблемы при работе с 1С рекомендуется использовать PGBouncer (пулер соединений). Он позволяет эффективно переиспользовать открытые сессии к базе данных, снижая нагрузку на CPU и память сервера. MSSQL имеет встроенный пул потоков, поэтому он кажется более стабильным «из коробки» при росте числа пользователей.

Итоги и рекомендации

Подведем итог нашему анализу. Победа Postgres Pro 1C в синтетических тестах на Windows — это не случайность, а результат глубокой оптимизации движка под метаданные 1С. Однако для успешной эксплуатации в «продакшене» необходимо выполнить следующие шаги:

1. Оптимизировать код 1С: Пересмотреть тяжелые запросы, использовать временные таблицы с индексами и избегать сложных соединений, которые планировщик Postgres может интерпретировать неверно.
2. Настроить ОС и СУБД: На Windows Server обязательно добавьте процессы Postgres и файлы данных в исключения антивируса и Defender. Настройте параметры WAL для защиты ресурса SSD.
3. Рассмотреть переход на Linux: Несмотря на хорошие результаты на Windows, Postgres работает нативным образом именно в Linux-среде, что дает дополнительный прирост производительности и стабильности за счет эффективного управления процессами.

Таким образом, выбор между MSSQL и Postgres Pro сегодня зависит не только от стоимости лицензий, но и от готовности команды разработчиков 1С уделять внимание качеству кода и тонкой настройке окружения.