Проблема производительности PostgreSQL при работе с «1С:Предприятие» на операционной системе Windows является одной из самых обсуждаемых тем среди системных администраторов. Часто наблюдается ситуация, когда на одном и том же оборудовании Microsoft SQL Server показывает значительно лучшие результаты в синтетических тестах (например, в тесте Гилева), чем PostgreSQL. В этой статье мы подробно разберем, почему так происходит, и как максимально сблизить показатели этих двух СУБД, правильно настроив конфигурационные файлы и параметры операционной системы.
Для начала разберем фундаментальную причину разницы в производительности. PostgreSQL исторически разрабатывался под POSIX-совместимые системы (Linux, Unix). В этих системах СУБД использует модель процессов: каждое новое подключение порождает отдельный процесс в ОС. В Windows создание процесса — это ресурсозатратная операция по сравнению с созданием потока (thread), который использует MSSQL. Кроме того, механизмы работы с общей памятью и файловым кэшем в Windows реализованы иначе, чем в Linux.
Проанализируем ситуацию: если на Linux PostgreSQL может использовать до 40% оперативной памяти под shared_buffers, то на Windows установка этого параметра выше 512 МБ – 1 ГБ часто приводит к деградации производительности. Это связано с тем, что PostgreSQL на Windows в значительной степени полагается на системный кэш ОС, и «двойное кэширование» (в СУБД и в ОС) на этой платформе работает неэффективно.
Рассмотрим основные параметры, которые напрямую влияют на «попугаи» в тесте Гилева и реальную скорость проведения документов. Начнем с самых критичных для Windows.
1. Синхронизация записи данных
Самый важный параметр для однопоточного теста — это synchronous_commit. По умолчанию он включен (on), что заставляет СУБД ждать физического подтверждения записи транзакции на диск. Для теста Гилева это критично. Если мы выставим:
synchronous_commit = off
СУБД будет подтверждать транзакцию сразу после записи в лог транзакций в оперативной памяти. Это может поднять результат теста в 2–3 раза. Важно: это несет риск потери данных последних нескольких секунд при внезапном отключении питания, поэтому использование ИБП обязательно.
2. Работа с дисковой подсистемой
Поскольку современные серверы 1С почти всегда используют SSD, параметры стоимости доступа к страницам по умолчанию (рассчитанные на HDD) неактуальны. Выясним причину: планировщик будет избегать использования индексов, считая, что случайное чтение слишком дорогое. Скорректируем это:
random_page_cost = 1.1 (или 1.0 для NVMe)
effective_io_concurrency = 200 (для SSD)
3. Настройка памяти
Для системы с 16 ГБ ОЗУ, как в нашем примере, рассмотрим следующие настройки:
shared_buffers = 512MB (на Windows больше — не всегда лучше)
work_mem = 128MB (влияет на скорость сложных запросов и сортировок)
maintenance_work_mem = 512MB (ускоряет очистку и создание индексов)
temp_buffers = 64MB (важно для временных таблиц 1С)
Для корректной и быстрой работы с платформой 1С необходимо убедиться в наличии специфических настроек, которые часто отсутствуют в «стандартных» конфигах для веб-серверов. Разберем их по шагам:
jit. Для 1С, генерирующей огромное количество мелких запросов, время на компиляцию плана запроса часто превышает время самого выполнения. Рекомендуем выключить: jit = off.standard_conforming_strings = off и escape_string_warning = off. Это необходимо для корректной обработки строковых литералов в запросах 1С.max_locks_per_transaction до 250 или 500, так как 1С активно использует блокировки при проведении документов в сложных конфигурациях (ERP, КА).Часто проблема кроется не в самой СУБД, а в окружении. Проанализируем настройки сервера:
План электропитания: Проверьте, что в Windows установлен режим «Максимальная производительность». По умолчанию Windows может динамически снижать частоту ядер процессора (Core Parking), что увеличивает задержки (latency) при обработке транзакций. Это критично для PostgreSQL, так как он чувствителен к задержкам одного ядра.
Антивирус и защитник Windows: Это «тихий убийца» производительности. Обязательно добавьте в исключения:
postgres.exe и rphost.exe.data в Postgres).Кэширование записи диска: В диспетчере устройств для вашего SSD можно включить опцию «Отключить очистку буфера кэша записей». Это даст существенный прирост, но помните о рисках при сбое питания.
Как показывает практика, более новые версии не всегда работают быстрее на Windows. Посмотрим на пример из опыта коллег: при переходе с версии 9.6 на 10.8 на той же конфигурации железа время выполнения тяжелых операций (например, ANALYZE или построение дерева спецификаций в ERP) может увеличиться.
Рекомендуем использовать специализированные сборки от «1С» или Postgres Professional (Standard-версия). Они содержат патчи для:
Рассмотрим пример правильного блока настроек для файла postgresql.conf на сервере с 16 ГБ ОЗУ и SSD:
max_connections = 150
shared_buffers = 1GB
effective_cache_size = 12GB
work_mem = 64MB
maintenance_work_mem = 512MB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 20s
synchronous_commit = off
jit = off
Если после всех манипуляций результат в тесте Гилева все еще не дотягивает до MSSQL, важно понимать, что это может быть пределом архитектуры Windows. На том же самом железе при переходе на Linux (например, Ubuntu или CentOS) PostgreSQL обычно прибавляет 20–30% к производительности «из коробки» за счет более эффективной работы ядра с процессами и дисковым стеком.
Однако для Windows-сервера ключевыми факторами успеха остаются: отключение synchronous_commit, ограничение shared_buffers до разумных пределов, настройка random_page_cost под SSD и полное исключение влияния антивирусного ПО на процессы СУБД.