По опыту администраторов 1С значительная часть жалоб на производительность связана не с кодом конфигурации и не с железом, а с тем, что СУБД работает на настройках по умолчанию. И PostgreSQL, и MS SQL Server из коробки выдают приемлемые цифры на универсальных задачах, но настройка PostgreSQL для 1С и параметры MS SQL для 1С — это отдельная тема: настройки по умолчанию не рассчитаны на профиль нагрузки 1С, поэтому ряд параметров нужно изменить.
Дальше разберем, какие параметры PostgreSQL и MS SQL обязательны к изменению, что делать с индексами 1С и статистикой и где чаще всего ломаются конфигурации в продакшене.
Почему дефолтные настройки СУБД не подходят для 1С
Любая универсальная СУБД настраивается на максимально безопасный сценарий: умеренное потребление памяти, консервативные планы запросов, никакой агрессии в обслуживании. 1С в клиент-серверном режиме — это другой профиль: десятки тысяч коротких транзакций в секунду, высокая конкуренция за блокировки, постоянная работа с временными таблицами.
Когда такой профиль попадает на дефолтные настройки PostgreSQL, база занимает четверть выделенной памяти, постоянно перегружает диск, а планы запросов уходят в параллельный режим — и каждый отчет в бухгалтерии начинает спорить за процессор сам с собой.
В MS SQL Server похожая история. Параметр MAXDOP, отвечающий за параллелизм, по умолчанию открыт — а 1С почти всегда работает короткими запросами, для которых параллельный план тратит больше времени на согласование, чем на саму выборку. Поэтому MAXDOP для 1С меняют одним из первых, вместе с памятью и настройками tempdb.
Что выбрать: PostgreSQL, Postgres Pro или MS SQL Server
Сегодня для 1С реально используются три варианта СУБД. MS SQL Server — зрелый продукт со встроенными инструментами диагностики (Query Store, Resource Governor). Минус — лицензии и санкционные ограничения, затрудняющие легальное обновление в РФ.
Платформа 1С работает только со сборками PostgreSQL с патчами для 1С. Бесплатны «PostgreSQL с патчем от 1С» (выпускает фирма «1С») и сборка «PostgreSQL для 1С» от Postgres Professional. Платные варианты: Postgres Pro для 1С, Postgres Pro Standard и Enterprise, Tantor, а также MS SQL Server. Обычного (ванильного) PostgreSQL в списке поддерживаемых СУБД нет. Бесплатные сборки поднимаются быстро, но требуют умения работать с pg_stat_statements и EXPLAIN. Postgres Pro добавляет корпоративные возможности (CFS-сжатие, ptrack), присутствие в реестре российского ПО и сертифицированные ФСТЭК редакции (Postgres Pro Certified), поэтому под импортозамещение в государственном секторе его выбирают чаще всего. Насколько PostgreSQL уступает MS SQL на реальных нагрузках 1С, показывает сравнение «PostgreSQL и MS SQL: реальная разница в производительности».
Ключевые параметры PostgreSQL для 1С
Параметры PostgreSQL, которые требует 1С
Настройки PostgreSQL для 1С 8.3 начинаются с четырех параметров, которые требует сама платформа. Их проверяют в postgresql.conf первыми на любом новом сервере:
- Параметр standard_conforming_strings = off;
- Параметр escape_string_warning = off;
- Параметр row_security = off;
- Параметр max_locks_per_transaction = 256.
Первые два параметра задают обработку обратной косой черты в строковых литералах так, как на это рассчитывает платформа. Третий отключает политики защиты на уровне строк, которые 1С не использует.
Значение max_locks_per_transaction требует отдельного объяснения. 1С создает много временных таблиц, и при закрытии соединения PostgreSQL удаляет их все в одной транзакции. На каждую таблицу нужна блокировка, и если блокировок больше лимита, возникает ошибка out of shared memory, а временные таблицы остаются в базе. Поэтому значение по умолчанию поднимают до 256.
Дальше идет память. Параметр shared_buffers — это разделочный стол повара: маленький стол вынуждает постоянно убирать, большой освобождает руки. Для 1С его ставят в 25% от оперативной памяти сервера. Параметр effective_cache_size показывает планировщику, на сколько кэша операционной системы можно рассчитывать — обычно 75% от RAM. work_mem (память для одной операции сортировки) для 1С хватает 64–128 мегабайт, maintenance_work_mem (память на VACUUM и индексы) — 1–2 гигабайта. max_connections для типового внедрения 200–400 соединений; больше — только через PgBouncer.
Журнал предзаписи и контрольные точки настраиваются под нагрузку коротких транзакций: wal_buffers ставят 16 мегабайт, checkpoint_timeout растягивают до 15 минут. Autovacuum для 1С обязательно включен, но параметр autovacuum_vacuum_scale_factor стоит снизить с дефолтных 0,2 до 0,05 — иначе вакуум начинает работать слишком редко и таблицы пухнут от мертвых строк. Под сам PostgreSQL разумно выделить отдельный сервер баз данных с собственным быстрым хранилищем под журнал и временные данные (ВД).
Ключевые параметры MS SQL Server для 1С
Параметры MS SQL для 1С тоже сводятся к нескольким принципиальным значениям. Min Server Memory — 4 гигабайта, Max Server Memory — 60–80% от оперативной памяти узла, чтобы операционной системе осталось чем дышать. MAXDOP для 1С ставится в 1 — это отключает параллельные планы запросов, которые на коротких операциях платформы только мешают. Cost Threshold for Parallelism — 50 на случай отдельного длинного запроса.
Отдельная история — tempdb, временная база, в которой SQL Server считает промежуточные результаты для отчетов и группировок. Под нее делают несколько файлов данных (по числу процессорных ядер, до восьми) и выносят на отдельный быстрый диск (NVMe или серверный SSD). Трассировочные флаги 1117 и 1118, которые выравнивают рост файлов и убирают конкуренцию за служебные страницы, нужны только на SQL Server 2014 и старше. С SQL Server 2016 они не действуют: это поведение задают параметры AUTOGROW_ALL_FILES и MIXED_PAGE_ALLOCATION.
Recovery Model для продуктивной базы — только Full с регулярными бэкапами журнала; Simple допустим только для тестовых стендов. Auto Update Statistics включен по умолчанию и менять его не надо. На все это лучше планировать сервер для 1С с памятью с запасом 30–40% над расчетной — это главный способ избежать ситуации, когда SQL Server упирается в потолок и тормозит всю систему.
Индексы и статистика: что добавлять, что не трогать
Индексы 1С — это отдельный мир. Платформа сама создает обширный набор индексов под свои регистры, документы и справочники, и трогать их вручную нельзя: при следующем обновлении конфигурации 1С спокойно их пересоздаст и затрет ваши изменения. Если индекс по полю реально нужен бизнес-логике, его правильно добавлять через конфигуратор: помечается реквизит как индексируемый, и платформа сама создает индекс с привязкой к своей метаданным.
Ручные индексы непосредственно в СУБД допустимы только в крайнем случае и с пониманием, что их придется перенакатывать после каждого обновления. Реальный кейс из практики: добавление одного грамотно подобранного составного индекса на регистр накопления ускоряет закрытие месяца в три-пять раз — но и просто пересборка существующих индексов раз в неделю и обновление статистики дают значимый эффект.
В PostgreSQL для регулярной реиндексации удобна утилита pg_repack — она работает без блокировки таблиц. В MS SQL похожую задачу решает встроенный Maintenance Plan. План запроса смотрят через EXPLAIN (PostgreSQL) или Activity Monitor и Query Store (MS SQL); долгие блокировки ловят через pg_stat_activity или sys.dm_exec_requests.
Типичные ошибки конфигурации СУБД для 1С
Самая частая ошибка для PostgreSQL — поставить shared_buffers больше 40% от оперативной памяти. Здесь работает не «больше — лучше», а тонкий баланс с кэшем операционной системы: при перекосе ОС начинает выгружать страницы базы в swap, и при первой пиковой нагрузке срабатывает OOM-killer — служба PostgreSQL просто умирает.
Вторая частая ошибка — оставленный включенным JIT-компилятор в PostgreSQL. Под 1С с ее короткими запросами JIT часто тратит больше времени на компиляцию плана, чем на его выполнение. Для PostgreSQL версий 12–15 параметр jit рекомендуется выставлять в off — там накладные расходы JIT на коротких запросах 1С особенно заметны.
Для PostgreSQL 16 и выше поведение JIT улучшилось, влияние на короткие запросы заметно снизилось — здесь не отключайте сразу, а сначала проверьте на своей нагрузке через тестовое отключение и сравнение Apdex до и после.
В MS SQL чаще всего встречается tempdb на одном файле и Recovery Model Simple на продуктивной базе. И то, и другое — мина замедленного действия: первая упирается в конкуренцию за служебные страницы при росте нагрузки, вторая лишает возможности восстановиться на момент сбоя. Под нагруженные базы 1С разумно сразу планировать сервер под SQL с правильно нарезанными томами под основные данные, журнал и tempdb на отдельных физических устройствах.
Сравнительная таблица: ключевые параметры PostgreSQL и MS SQL для 1С
Чтобы было проще держать рядом значения для двух СУБД, основные параметры собрали в таблице.
| Параметр | PostgreSQL для 1С | MS SQL Server для 1С |
|---|---|---|
| Память под кэш базы | shared_buffers = 25% RAM | Max Server Memory = 60–80% RAM |
| Память на одну сортировку | work_mem = 64–128 МБ | определяется планировщиком |
| Память на обслуживание | maintenance_work_mem = 1–2 ГБ | — |
| Параллелизм | — | MAXDOP = 1, Cost Threshold = 50 |
| Временные данные | работа с tempdb-аналогом через temp_tablespaces | tempdb: N файлов по числу ядер, TF 1117/1118 только до SQL Server 2014 |
| Соединения | max_connections = 200–400, далее PgBouncer | без отдельного пулера |
| Обслуживание | autovacuum, autovacuum_vacuum_scale_factor = 0,05 | Maintenance Plan, Auto Update Statistics on |
| Что отключить | jit = off на 12–15, на 16+ проверять под нагрузкой | параллельные планы для коротких запросов |
Из таблицы видно, что суть настройки одна и та же: дать СУБД достаточно памяти под рабочие данные, отключить параллельные планы для коротких запросов, развести нагрузку по дискам и обеспечить регулярное обслуживание. Различаются только имена параметров.
Заключение
Оптимизация PostgreSQL для 1С и MS SQL под 1С — это не про экзотические настройки, а про последовательную работу по чек-листу. Сначала закрываются обязательные параметры платформы и базовая конфигурация памяти. Потом разводится нагрузка по дискам и убираются параллельные планы.
На третьем шаге настраивается обслуживание (вакуум и реиндексация) и подключается мониторинг по Apdex и плану запроса. Конкретный шаг — провести аудит ИТ-инфраструктуры и снять текущие показатели Apdex, чтобы понять, какие из параметров СУБД дадут на вашей базе максимальный прирост.
Часто задаваемые вопросы о настройке СУБД для 1С
Сколько RAM выделить SQL Server под 1С?
Стандартное правило — 60–80% от оперативной памяти сервера в Max Server Memory, минимум 4 гигабайта в Min Server Memory. Для активной базы на 50 пользователей разумный минимум — 64 гигабайта оперативной памяти на узле, под крупные внедрения — 128 и выше.
Можно ли ставить PostgreSQL и сервер 1С на один сервер?
Технически можно, но на любой реальной нагрузке это плохая идея. Платформа 1С и СУБД будут конкурировать за процессор и память, а tempdb-аналог в PostgreSQL — за диски с журналом транзакций. Стандартная схема — отдельный сервер базы данных и отдельный сервер 1С, связанные быстрой сетью.
Чем PgBouncer полезен для 1С?
PgBouncer — это пулер соединений: он держит небольшое число постоянных подключений к PostgreSQL и распределяет между ними подключения от приложения. Под 1С это снимает нагрузку на сам PostgreSQL: вместо 200 живых сеансов база видит 50 пуленных, а память на каждое соединение экономится в разы. Режимы пула и требования к железу для больших инсталляций разбирает статья «PgBouncer и архитектура PostgreSQL для 500+ подключений».
Postgres Pro — это то же самое, что обычный PostgreSQL?
Нет. Postgres Pro — коммерческая СУБД Postgres Professional на основе PostgreSQL с корпоративными возможностями (CFS-сжатие, ptrack), сертифицированными ФСТЭК редакциями (Postgres Pro Certified) и присутствием в реестре российского ПО, и Postgres Pro для 1С тоже продается по лицензиям. Бесплатная сборка «PostgreSQL для 1С» от той же компании — это не Postgres Pro, а PostgreSQL с патчами для 1С. Для коммерческой компании без требований импортозамещения обычно хватает бесплатной сборки от фирмы «1С» или от Postgres Professional.
Как быстро понять, что СУБД — узкое место?
Снять APDEX по ключевым операциям, в типовых конфигурациях его собирает подсистема «Оценка производительности». Если показатель ниже 0,85 и в технологическом журнале 1С видны долгие блокировки — почти наверняка проблема в СУБД. Дальше смотрят утилизацию диска и количество ожиданий: pg_stat_statements в PostgreSQL и sys.dm_os_wait_stats в MS SQL дают исчерпывающую картину. Порядок разбора по шагам показывает статья о том, как диагностировать тормоза 1С по логам СУБД.