По опыту администраторов 1С значительная часть жалоб на производительность связана не с кодом конфигурации и не с железом, а с тем, что СУБД работает на настройках по умолчанию. И PostgreSQL, и MS SQL Server из коробки выдают приемлемые цифры на универсальных задачах, но настройка PostgreSQL для 1С и параметры MS SQL для 1С — это отдельная тема, в которой дефолты дают потерю 40–60% скорости.
Дальше разберем, какие параметры PostgreSQL и MS SQL обязательны к изменению, что делать с индексами 1С и статистикой и где чаще всего ломаются конфигурации в продакшене.
Почему дефолтные настройки СУБД не подходят для 1С
Любая универсальная СУБД настраивается на максимально безопасный сценарий: умеренное потребление памяти, консервативные планы запросов, никакой агрессии в обслуживании. 1С в клиент-серверном режиме — это другой профиль: десятки тысяч коротких транзакций в секунду, высокая конкуренция за блокировки, постоянная работа с временными таблицами.
Когда такой профиль попадает на дефолтные настройки PostgreSQL, база занимает четверть выделенной памяти, постоянно перегружает диск, а планы запросов уходят в параллельный режим — и каждый отчет в бухгалтерии начинает спорить за процессор сам с собой.
В MS SQL Server похожая история. Параметр MAXDOP, отвечающий за параллелизм, по умолчанию открыт — а 1С почти всегда работает короткими запросами, для которых параллельный план тратит больше времени на согласование, чем на саму выборку. Реальная цена такого «дефолта» — потеря 40–60% производительности на типовых задачах учета: проведение документа идет вдвое медленнее, закрытие месяца уходит в ночь.
Что выбрать: PostgreSQL, Postgres Pro или MS SQL Server
Сегодня для 1С реально используются три варианта СУБД. MS SQL Server — зрелый продукт со встроенными инструментами диагностики (Query Store, Resource Governor). Минус — лицензии и санкционные ограничения, затрудняющие легальное обновление в РФ.
Сообщество PostgreSQL — бесплатный вариант, который под 1С ставится только со специальной сборкой с патчами 1С. Поднимается быстро, обходится дешево, но требует умения работать с pg_stat_statements и EXPLAIN. Postgres Pro — российский форк с теми же патчами плюс корпоративные возможности (CFS-сжатие, ptrack), реестром российского ПО и сертификатом ФСТЭК. Под импортозамещение серверов в государственном секторе — практически безальтернативный выбор.
Ключевые параметры PostgreSQL для 1С
Настройки PostgreSQL для 1С 8.3 начинаются с нескольких параметров, которые требует сама платформа: max_locks_per_transaction = 256, standard_conforming_strings = off, escape_string_warning = off, row_security = off. Без этих значений 1С либо не запустится, либо будет периодически ломаться на больших транзакциях — это первое, что нужно проверить в файле postgresql.conf на новом сервере.
Дальше идет память. Параметр 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 — они выравнивают рост файлов и убирают конкуренцию за служебные страницы.
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 под 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 пуленных, а память на каждое соединение экономится в разы.
Postgres Pro — это то же самое, что обычный PostgreSQL?
Не совсем. Postgres Pro — это российский форк PostgreSQL с патчами 1С в основной поставке, дополнительными корпоративными возможностями (CFS-сжатие, ptrack), сертификатом ФСТЭК и присутствием в реестре российского ПО. Для государственного сектора это сегодня основной выбор; для коммерческой компании на безсанкционной инфраструктуре подходит и обычный PostgreSQL со сборкой 1С.
Как быстро понять, что СУБД — узкое место?
Снять Apdex с инструмента gilev.ru. Если показатель ниже 0,85 и в технологическом журнале 1С видны долгие блокировки — почти наверняка проблема в СУБД. Дальше смотрят утилизацию диска и количество ожиданий: pg_stat_statements в PostgreSQL и sys.dm_os_wait_stats в MS SQL дают исчерпывающую картину.
