Оптимизация СУБД под 1С:Предприятие 8.5: полный чек-лист от железа до запросов

С выходом 8.5 многие ждут прироста производительности «из коробки» — 1С заявляет улучшения производительности, стабильности и масштабируемости в версии 8.5.1. Но платформа не вытащит базу, у которой не настроена СУБД. Пройдёмся по всем уровням.

1. Уровень ОС и железа

• SSD/NVMe под данные — обязательный минимум; журналы транзакций и tempdb — на отдельные диски;
• Linux под PostgreSQL: отключить Transparent Huge Pages, настроить классические huge pages под shared_buffers, vm.swappiness = 1–10;
• планировщик I/O: none/mq-deadline для NVMe;
• проверить энергосбережение CPU — governor performance, а не powersave: «плавающие» тормоза часто отсюда;
• сеть между сервером 1С и СУБД — 10 Гбит или размещение на одном хосте; латентность здесь важнее пропускной способности.

2. PostgreSQL: параметры, которые чаще всего забыты

• shared_buffers — 25% ОЗУ (не больше 40%);
• effective_cache_size — 50–75% ОЗУ;
• work_mem — 64–256 МБ: мало = сортировки на диске, много = риск OOM;
• random_page_cost = 1.1–1.2 для SSD, иначе планировщик избегает индексов;
• max_parallel_workers_per_gather = 0 для OLTP-профиля 1С (параллелизм оставляем для копии под отчёты);
• autovacuum агрессивнее: autovacuum_vacuum_scale_factor = 0.01–0.02 для крупных таблиц регистров;
• checkpoint_timeout = 15–30 мин, max_wal_size увеличить — реже checkpoint-штормы;
• регулярный REINDEX/pg_repack распухших таблиц итогов.

3. MS SQL: старая классика

Здесь два взаимоисключающих сценария, выбирать нужно один.

MAXDOP = 1 — рекомендация ИТС для чистого OLTP-профиля 1С. Платформа генерирует много коротких запросов, параллельные планы дают CXPACKET-ожидания и нестабильность планов. При этом значении cost threshold for parallelism не имеет смысла — параллелизм отключён на уровне сервера целиком.

MAXDOP по числу ядер в NUMA-узле, но не больше 8, плюс cost threshold for parallelism = 50–150 — вариант для смешанной нагрузки. Значение порога по умолчанию (5) откалибровано под железо середины 90-х: на современных серверах в параллель уходят даже тривиальные запросы. MAXDOP = 1 предсказуем в OLTP, но заметно растягивает закрытие месяца и тяжёлые отчёты.

Если сервер один и разнести нагрузку некуда — на SQL Server 2016+ MAXDOP задаётся не на инстансе, а на уровне базы: ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = N. Рабочая база — 1, база под отчёты или реплика — 4–8.

4. Кластер серверов 1С

СУБД — лишь половина связки:

• Рабочие процессы: не один гигантский, а несколько с ограничением памяти на процесс и автоперезапуском при превышении;
• Вынести фоновые задания на отдельный рабочий сервер через требования назначения функциональности;
• Лицензирование, журнал регистрации и полнотекстовый поиск не должны конкурировать с пользовательскими сеансами за диск;
• Проверить интервал перезапуска рабочих процессов — утечки памяти в долгоживущих процессах никто не отменял.

5. Индексы и структура данных

• Добавить индексы измерениям регистров, по которым реально фильтруют отчёты (флаг «Индексировать» в конфигураторе или расширении);
• Проверить неиспользуемые индексы (pg_stat_user_indexes / sys.dm_db_index_usage_stats) — каждый лишний индекс замедляет запись;
• Пересчёт и установка границы рассчитанных итогов регистров — ежемесячно регламентом;
• Отключить неиспользуемые механизмы: версионирование объектов «на всё», полнотекстовый поиск, если им никто не пользуется, историю данных без необходимости;
• Свёртка базы, если в рабочем контуре лежит 10+ лет документов.

6. Оптимизация запросов — самый дешёвый прирост

Никакой конфиг не спасёт от плохого кода:

• Запросы в цикле → один запрос с временной таблицей;
• Соединения с виртуальными таблицами (ОстаткиИОбороты и пр.) → сначала выгрузка во временную таблицу с индексом;
• ПОДОБНО "%..." и функции над полями в условиях убивают использование индексов;
• РЛС (ограничения на уровне записей) — частый скрытый убийца производительности: проверяйте итоговый текст запроса;
• Динамические списки: произвольный запрос + основная таблица, без соединений в условиях отбора.

7. Архитектурные приёмы

• Тяжёлую отчётность — на копию базы (механизм копий данных / логическая репликация PostgreSQL): OLTP и OLAP на одной базе — вечный конфликт;
• Отложенное проведение и разнесение тяжёлых движений по времени;
• Очереди вместо синхронных обменов в пиковые часы.

8. Что даёт именно 8.5

    Полезное для диагностики — HTTP-интерфейс метрик кластера серверов, расширенный в 8.5.3–8.5.4: показатели рабочих процессов, менеджера кластера и рабочих серверов отдаются наружу и снимаются любым внешним мониторингом без сторонних обвязок на COM/RAS. Журнал регистрации в 8.5 развивали в другую сторону — аудит прав и отказоустойчивый сервис ЖР; таймингов запросов там нет, за ними по-прежнему идём в техножурнал и в средства СУБД.

Тайминги запросов — где их брать на самом деле:

1. ТЖ с отбором по длительности. Дешевле, чем кажется, если не включать всё подряд. conf/logcfg.xml:

xml

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\tj" history="24">
    <event><eq property="name" value="DBPOSTGRS"/><ge property="duration" value="3000000"/></event>
    <event><eq property="name" value="DBMSSQL"/><ge property="duration" value="3000000"/></event>
    <event><eq property="name" value="TLOCK"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <property name="all"/>
  </log>
</config>

duration в микросекундах, 3000000 = 3 с. Файл подхватывается без перезапуска сервера, обычно в течение минуты.

2. Замеры времени БСП («Оценка производительности»). Включается в разделе «Администрирование → Оценка производительности», данные копятся в регистре сведений «Замеры времени», дальше APDEX по ключевым операциям. Это то, что реально стоит показывать заказчику как «до/после».

3. Уровень СУБД. PostgreSQL — pg_stat_statements плюс log_min_duration_statement; MS SQL — Query Store или Extended Events. Здесь тайминги честнее всего, потому что видно и план, и частоту вызова.

9. Методика вместо шаманства

APDEX по ключевым операциям до и после, одна итерация = одно изменение = один замер. Иначе через месяц никто не вспомнит, что именно помогло.

Вывод

Производительность 1С — это слоёный пирог: железо → ОС → СУБД → кластер → структура данных → код. Ковырять только один слой бессмысленно. Переход на 8.5 — хороший повод пройти весь чек-лист сверху вниз.

Сталкивались с нюансами на 8.5 — делитесь в комментариях, соберём статистику по релизу.