Как ускорить 1С: от настроек СУБД до кода конфигурации

Начните не с настроек, а с замера: откройте замер производительности и найдите, где именно теряются секунды — на запросе к СУБД, на ожидании блокировки или в коде. Крутить параметры сервера вслепую бесполезно: один узкий блок способен свести на нет любой апгрейд железа.

Оптимизировать 1С можно на четырёх уровнях — СУБД, кластер серверов , код конфигурации и дисковая подсистема. Ниже — по каждому: что замерить, что настроить и какие числа считаются нормой. Все пути даны для платформы 8.3 (интерфейс «Такси») в клиент-серверном варианте.

Сначала измеряем: где именно тормозит база

Пока не знаете причину — не трогаете настройки. Диагностику ведут тремя инструментами.

• 📊 Технологический журнал (logcfg.xml) — пишет длительные запросы, блокировки, ошибки. Включается на короткий интервал, потом разбирается.
• 🔍 Центр управления производительностью (КИП/ЦУП) — показатель APDEX по ключевым операциям, «долгие» вызовы, таймауты.
• 🧰 Профайлер и планы запросов СУБД — для MS SQL Server это SQL Profiler / Extended Events и план выполнения; для PostgreSQL — EXPLAIN (ANALYZE) и расширение auto_explain.

Порядок простой. Сначала APDEX покажет, какие операции пользователи ждут дольше всего. Потом по конкретной операции смотрите в технологическом журнале события DBMSSQL (время запроса) и TLOCK/TDEADLOCK (ожидания блокировок). И только найдя тяжёлый запрос или частую блокировку, переходите к правкам.

Типичная ошибка на этом шаге — чинить то, что не болит. Апгрейд процессора не поможет, если 90% времени база ждёт блокировку от соседнего сеанса. Замер отделяет реальную проблему от догадок.

Настройка СУБД: индексы, статистика и параллелизм

Основной выигрыш почти всегда даёт уровень СУБД — через неё проходит каждый запрос.

Индексы. 1С создаёт индексы для своих объектов автоматически, по описанию метаданных. Вручную добавлять индексы в таблицы 1С нельзя — они слетят при реструктуризации. Что можно и нужно — поддерживать индексы в рабочем состоянии: перестраивать при высокой фрагментации и обновлять статистику. Устаревшая статистика — частая причина того, что оптимизатор СУБД выбирает плохой план и запрос, который должен идти миллисекунды, тянется секунды.

Статистика. Для MS SQL включите AUTO_UPDATE_STATISTICS, а большие таблицы дополнительно обновляйте вручную по регламенту (см. раздел про обслуживание). Для PostgreSQL за это отвечает autovacuum с ANALYZE — его нельзя отключать на базах 1С.

Параллелизм (только MS SQL Server). 1С плохо дружит с параллельными планами. Разумная база настроек:

PostgreSQL. Используйте только сборку, патченную под 1С (обычная ванильная сборка не подойдёт). Базовые параметры подгоняют под объём ОЗУ сервера: shared_buffers — около четверти памяти, effective_cache_size — до 50-75%, work_mem — осторожно, умножается на число соединений. Тонкая настройка PostgreSQL под 1С — отдельная большая тема; начните с профиля под вашу нагрузку и объём памяти, а дальше правьте по планам запросов.

Кластер серверов 1С: рабочие процессы и память

На уровне кластера настраивают, как сервер 1С распределяет сеансы и расходует память. Открывается консолью администрирования серверов (оснастка MMC) или утилитой rac.

Рабочие процессы. В свойствах рабочего сервера задаётся, как создаются рабочие процессы (rphost): по числу соединений или информационных баз на процесс. Один тяжёлый rphost, обслуживающий всех, — узкое место; несколько процессов распределяют нагрузку по ядрам.

Полезные параметры свойств рабочего сервера:

• 🧠 Безопасный расход памяти за один вызов — если вызов превышает лимит, он аварийно завершается, но не роняет весь процесс с остальными пользователями.
• 📉 Объём памяти рабочих процессов, до которого они считаются производительными — помогает кластеру вовремя перезапускать «раздувшийся» процесс.
• ⚙️ Требования назначения функциональности — позволяют развести фоновые задания, регламентные операции и клиентскую работу по разным рабочим серверам или процессам.

Сетевой контур. Клиент обращается к агенту сервера (порт 1540), затем работает через менеджер кластера (1541) и рабочие процессы (их диапазон портов задаётся в свойствах рабочего сервера). Консоль администрирования тоже идёт через агент. Если сервер 1С и СУБД разнесены, канал между ними должен быть быстрым и с низкой задержкой — об этом в разделе про железо.

Сеансовые данные и кэш. Раздутый каталог сеансовых данных и кэш клиента тоже замедляют работу. На клиентских станциях при странных тормозах помогает запуск с очисткой кэша (/ClearCache) — но это разовая мера для конкретной машины, а не оптимизация сервера.

Для управления из командной строки хватает базовых команд rac: rac cluster list, rac session list. Если нужной подкоманды не помните — не угадывайте параметры, посмотрите rac help.

Медленные запросы и код конфигурации

Когда СУБД настроена, а операция всё равно долгая, причина — в коде. Самые дорогие ошибки разработки повторяются из базы в базу.

Запрос в цикле. Классика: запрос к базе внутри обхода коллекции. Сто строк — сто обращений к СУБД. Решение — один запрос с условием по всему списку до цикла, а в цикле только обработка результата.

Соединение с виртуальными таблицами. Соединения (ЛЕВОЕ СОЕДИНЕНИЕ) с виртуальными таблицами остатков и оборотов в одном запросе резко утяжеляют план. Там, где можно, разносите по временным таблицам с индексацией.

Получение данных через точку в цикле. Обращение Ссылка.Реквизит внутри цикла — это неявный запрос на каждой итерации. Нужные реквизиты читайте пакетом заранее.

Временные таблицы и индексы в запросе. Крупные промежуточные выборки складывайте в ПОМЕСТИТЬ с индексом по полям соединения — оптимизатор СУБД получит план лучше.

Выборка лишних данных. ВЫБРАТЬ * и чтение всей таблицы, когда нужны две колонки и отбор по периоду, грузят и СУБД, и сеть. Берите только нужные поля и всегда ставьте условие по периоду и организации — так запрос попадает в индекс, а не сканирует всю таблицу движений.

Автоматические блокировки от неоптимального запроса. Запрос без подходящего индекса заставляет СУБД блокировать больше строк, чем нужно. То есть медленный запрос и лишние блокировки — часто одна и та же проблема, и лечатся они вместе: правильным индексом и условием отбора.

Простой пример обратного обхода коллекции при удалении элементов — чтобы не сбить нумерацию:

Для Сч = 1 По Строки.Количество() Цикл
    Элемент = Строки[Строки.Количество() - Сч];
    // обработка элемента
КонецЦикла;

Планы запросов снимайте в СУБД: для MS SQL — фактический план выполнения, для PostgreSQL — EXPLAIN (ANALYZE, BUFFERS). Сканирование таблицы (Seq Scan / Table Scan) там, где ожидался поиск по индексу, — прямой сигнал к пересмотру запроса или статистики.

Блокировки и взаимоблокировки: снижаем ожидания

Если пользователи жалуются на «зависания» при одновременной работе, дело чаще в блокировках, а не в скорости запросов.

Режим управления блокировками. В свойствах конфигурации должен стоять управляемый режим блокировки данных. Автоматический режим на уровне СУБД даёт более грубые, длинные блокировки. Типовые конфигурации (БП 3.0, ЗУП 3.1, УТ 11) работают в управляемом режиме — проверьте, что ваша доработанная конфигурация его не потеряла.

RCSI на стороне MS SQL (см. выше) снимает конфликт «чтение против записи» — для большинства баз это самый быстрый способ сократить ожидания.

Длинные транзакции. Блокировка держится до конца транзакции. Проведение документа, которое внутри делает долгий запрос или ждёт ввода пользователя, блокирует данные всё это время. Проверьте тяжёлые обработчики проведения и фоновые задания, идущие в часы пик.

Диагностика ожиданий — по событиям техжурнала:

Взаимоблокировки (TDEADLOCK) разбирают по паре конфликтующих транзакций: смотрят, какие ресурсы каждая заняла и в каком порядке. Часто лечится выравниванием порядка обращения к объектам в коде.

Железо и дисковая подсистема

Апгрейд оправдан, когда софт уже выжат. Но у 1С свои приоритеты, и они не всегда очевидны.

• 💾 Диски — быстрее всего окупаются. Под базу СУБД и tempdb нужен SSD, лучше NVMe. HDD под рабочую базу 1С — главный тормоз, который не лечится настройками. Логи транзакций желательно вынести на отдельный быстрый том.
• ⚡ Частота ядра важнее числа ядер. 1С выполняет пользовательскую операцию в один поток, поэтому процессор с высокой частотой на ядро даст больше, чем многоядерный, но медленный. Это важно и для сервера 1С, и для SQL Server.
• 🧠 Память — чтобы база помещалась в кэш. Цель — чтобы «горячие» данные жили в оперативной памяти СУБД, а не читались с диска. Нехватка ОЗУ видна по высокому дисковому чтению на сервере СУБД.
• 🌐 Сеть между 1С и СУБД. Если серверы разнесены, канал должен быть быстрым (10 Гбит/с) и с минимальной задержкой. Высокая латентность между сервером приложений и СУБД убивает производительность запросов. Небольшие базы часто выигрывают от размещения 1С и СУБД на одной машине.

Не наращивайте число ядер в надежде ускорить проведение документов — одна операция 1С всё равно идёт в один поток.

Регламентное обслуживание и чистка базы

Производительность деградирует со временем: индексы фрагментируются, статистика устаревает, база распухает. Регламент удерживает скорость на уровне.

Обслуживание индексов и статистики (по расписанию, ночью):

1. Обновление статистики по большим таблицам.
2. Перестроение или дефрагментация индексов при высокой фрагментации.
3. Для PostgreSQL — контроль autovacuum, при необходимости ручной VACUUM ANALYZE.

Тестирование и исправление. Штатное «Тестирование и исправление информационной базы» в конфигураторе чинит логические и ссылочные ошибки. Для файловой базы есть утилита chdbfl.exe. Запускают в монопольном режиме — на время теста база недоступна пользователям.

Чистка данных:

• 🗑️ Удаление помеченных объектов по расписанию — помеченные записи продолжают занимать место и утяжелять запросы.
• 📦 Свёртка базы — сворачивает старые периоды в остатки, резко уменьшая объём. Делается строго на копии, с проверкой результата, и только когда старые данные больше не нужны для оперативной работы.
• 🧾 Контроль разделителей и фоновых заданий — зависшие или дублирующиеся регламентные задания сами по себе создают нагрузку.

Эти операции ставят в ночное технологическое окно и мониторят: обслуживание, которое не укладывается до начала рабочего дня, само становится проблемой.

Частые вопросы