Оптимизация СУБД под 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-нагрузки, cost threshold for parallelism, ограничение памяти сервера, tempdb в несколько файлов равного размера (по числу ядер до 8), регулярное обновление статистики с FULLSCAN по крупным таблицам, обслуживание индексов по фрагментации, Read Committed Snapshot Isolation — проверить, что включён (платформа сама переводит, но у «исторических» баз бывают сюрпризы).

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

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

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

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

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

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

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

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

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

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

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

В журнал регистрации добавлена аналитика по производительности — тайминги выполнения запросов и нагрузка на сервер. Это не замена техножурналу, но быстрые проблемные запросы теперь видно без разворачивания полного ТЖ. Порядок разбора инцидента: аналитика ЖР → ТЖ с отбором по длительности → план запроса в СУБД.

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

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

Вывод

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

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