← На главную

При тестировании производительности одной и той же конфигурации 1С на двух разных СУБД (MS SQL Server и PostgreSQL) часто наблюдается характерное поведение: первый запуск длительной обработки или отчета занимает примерно одинаковое время, однако при повторных запусках MS SQL демонстрирует ощутимое ускорение (на 20–50%), а PostgreSQL выполняет задачу за то же время, что и в первый раз. Проанализируем, с чем связано такое поведение, использует ли PostgreSQL кэш 1С и какими настройками можно оптимизировать работу СУБД.

Взаимосвязь между кэшем 1С и движком СУБД

Прежде всего разберем распространенное заблуждение о «кэше 1С». Кэш платформы 1С:Предприятие — это файлы, создаваемые самой платформой во временных каталогах пользователя или сервисных папках сервера приложений (например, кэш метаданных, кэш объектов). Сервер СУБД (будь то MS SQL или PostgreSQL) ничего не знает о существовании этих локальных файлов 1С и никак их не использует.

СУБД работает исключительно со своей оперативной памятью, дисковым пространством и собственными структурами данных. Повторное ускорение запросов в MS SQL достигается за счет механизмов самой СУБД, а не благодаря платформе 1С.

За счет чего ускоряется MS SQL при повторных запусках

Проанализируем работу MS SQL Server при повторном вызове тяжелых запросов:

1. Процедурный кэш (Procedure Cache): MS SQL сохраняет скомпилированные планы выполнения запросов. При повторном вызове аналогичного запроса СУБД не тратит время на повторный анализ синтаксиса и построение плана, а сразу берет готовый план из памяти.
2. Буферный пул (Buffer Pool): По умолчанию MS SQL стремится захватить всю доступную оперативную память сервера. При первом чтении таблиц страницы данных загружаются с диска в ОЗУ. Если при повторном запуске данные все еще находятся в буферном пуле, считывание происходит мгновенно из оперативной памяти без обращения к медленному диску.

Почему PostgreSQL не дает прироста при повторном запуске

В архитектуре PostgreSQL кэширование и управление памятью устроены иначе. Рассмотрим основные причины, почему повторный запуск обработки в PostgreSQL выполняется без видимого ускорения:

1. Консервативные настройки памяти по умолчанию: В отличие от MS SQL, PostgreSQL по умолчанию использует минимальные объемы оперативной памяти. Если параметры буферов не настроены под рабочую нагрузку, данные не удерживаются в памяти СУБД.
2. Зависимость от файлового кэша операционной системы: PostgreSQL выделяет сравнительно небольшой собственный буфер (shared_buffers), а для кэширования остальных данных полагается на кэш страниц (Page Cache) операционной системы. При работе PostgreSQL под управлением ОС Windows механизмы сброса данных на диск (fsync) и взаимодействия с системным кэшем работают менее эффективно, чем в среде Linux. Из-за этого при каждом прогоне СУБД заново выполняет физические операции чтения с диска.
3. Нехватка памяти под операции сортировки (work_mem): Сложные отчеты и обработки 1С активно используют соединение таблиц и сортировки. Если выделенный объем work_mem меньше объема обрабатываемых данных, PostgreSQL сбрасывает промежуточные результаты во временные файлы на диск (spill files), что сводит на нет выигрыш от повторного вызова.
4. Отсутствие актуальной статистики по временным таблицам: Временные таблицы 1С создаются в процессе выполнения скрипта и удаляются после завершения транзакции. Фоновые процессы сбора статистики (autovacuum) не обрабатывают локальные временные таблицы сессий. В результате оптимизатор PostgreSQL строит план выполнения «вслепую», исходя из зашитых значений по умолчанию (например, оценивая размер таблицы в 1000 строк). Из-за неоптимального плана соединения временных таблиц скорость работы остается низкой при каждом запуске.

Как настроить PostgreSQL для максимальной производительности 1C

Чтобы заставить PostgreSQL эффективно использовать оперативную память и ускорить выполнение сложной бизнес-логики 1С, выполним базовую донастройку конфигурационного файла postgresql.conf.

1. Оптимизируем выделение памяти:

1. shared_buffers: Зададим значение на уровне 25% от общей оперативной памяти сервера (например, 8GB или 16GB). Это позволит СУБД удерживать горячие таблицы в собственном кэше.
2. work_mem: Увеличим объем памяти для операций сортировки и объединения на одно соединение (например, от 64MB до 256MB). Это предотвратит сброс промежуточных данных во временные файлы на диск.
3. temp_buffers: Увеличим буфер для временных объектов сессии (например, до 32MB или 64MB), так как 1С активно использует временные таблицы.
4. effective_cache_size: Укажем планировщику суммарный объем памяти, доступный для кэширования (обычно 50–75% от общего объема ОЗУ сервера). Это помогает оптимизатору выбирать более быстрые индексы вместо последовательного сканирования таблиц.

2. Обеспечим сбор статистики по временным таблицам:

Убедимся, что используется актуальная версия платформы 1С:Предприятие (начиная с 8.3.13), где платформенный механизм автоматически отправляет команду вызова статистики ANALYZE после заполнения временных таблиц. При использовании специальных сборок PostgreSQL для 1С (например, от Postgres Pro) убедимся, что включен модуль online_analyze.

3. Выбор операционной системы:

Для достижения максимального быстродействия PostgreSQL в связке с 1С рекомендуется разворачивать сервер СУБД на дистрибутивах Linux (Astra Linux, Ubuntu, RedHat/Alt Linux). Нативная работа PostgreSQL с дисковой подсистемой и файловым кэшем в Linux обеспечит скорость работы, сравнимую или превосходящую MS SQL Server.