Почему тормозит файловая база УТ 11.5 при проведении документов и как это исправить

← На главную

Работа с современными конфигурациями на платформе 1С:Предприятие 8.3, такими как Управление торговлей 11.5, ERP 2.5 или Комплексная автоматизация 2.5, предъявляет высокие требования к ресурсам системы. Особенно остро проблема производительности встает при использовании файлового режима работы. Пользователи часто сталкиваются с ситуацией, когда аппаратная часть (процессор i5/i7, SSD-диски, большой объем ОЗУ) загружена минимально, но проведение документов «Реализация товаров и услуг» или «Заказ клиента» занимает десятки секунд.

В этой статье мы подробно разберем, почему возникают такие «глюки», проанализируем конкретный программный код, вызывающий замедление, и внедрим эффективное решение, которое ускорит работу базы в несколько раз.

Анализируем причину замедления: механизм онлайн-взаиморасчетов

Разберем ситуацию: база УТ 11.5, файловый вариант, объем данных за несколько лет (например, около 400 000 строк в регистрах). Типовые процедуры обслуживания, такие как Тестирование и исправление (ТиИ) или chkdsk, не дают результата. Проблема кроется в архитектуре онлайн-взаиморасчетов, которая была внедрена в последних версиях УТ.

При проведении практически любого документа, влияющего на расчеты с контрагентами, система выполняет сложный запрос к регистрам накопления и внутренним таблицам изменений. В файловом режиме движок SDBM (собственная СУБД 1С) не всегда эффективно строит план запроса при соединении больших таблиц, что приводит к колоссальным задержкам.

Шаг 1. Локализация проблемного участка кода

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


ВЫБРАТЬ РАЗЛИЧНЫЕ
    Таблица.ОтражаемыйДокумент КАК ОтражаемыйДокумент
ИЗ
    (ВЫБРАТЬ
        Таблица.ДокументОтгрузки КАК ОтражаемыйДокумент
    ИЗ
        ДвиженияТоварыКОтгрузкеПереотражение КАК Таблица
    ГДЕ
        (Таблица.КОформлениюИзменение <> 0
            ИЛИ Таблица.КОтгрузкеИзменение <> 0)
    
    ОБЪЕДИНИТЬ ВСЕ
    
    ВЫБРАТЬ
        РасчетыСКлиентами.ПродажаПоЗаказу КАК ОтражаемыйДокумент
    ИЗ
        РегистрНакопления.РасчетыСКлиентами КАК РасчетыСКлиентами
    ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.ОбъектыРасчетов КАК ОбъектыРасчетов
        ПО ОбъектыРасчетов.Объект = РасчетыСКлиентами.ПродажаПоЗаказу
        И НЕ ОбъектыРасчетов.ПометкаУдаления
    ВНУТРЕННЕЕ СОЕДИНЕНИЕ РасчетыСКлиентамиИзменения КАК РасчетыСКлиентамиИзменения
        ПО РасчетыСКлиентами.АналитикаУчетаПоПартнерам = РасчетыСКлиентамиИзменения.АналитикаУчетаПоПартнерам
        И РасчетыСКлиентами.ОбъектРасчетов = РасчетыСКлиентамиИзменения.ОбъектРасчетов
    ГДЕ
        РасчетыСКлиентами.ПродажаПоЗаказу <> НЕОПРЕДЕЛЕНО
        И ОбъектыРасчетов.ТипОбъектаРасчетов = ЗНАЧЕНИЕ(Перечисление.ТипыОбъектовРасчетов.Заказ)
    ) КАК Таблица;

Как показывает практика и детальный разбор ситуации, наиболее «тяжелой» частью является блок с регистром РегистрНакопления.РасчетыСКлиентами. При наличии 400 тысяч записей внутреннее соединение (ВНУТРЕННЕЕ СОЕДИНЕНИЕ) этого регистра с таблицей РасчетыСКлиентамиИзменения заставляет файловую СУБД перебирать огромные массивы данных в памяти.

Шаг 2. Оптимизация запроса для файлового режима

Проанализируем, как мы можем изменить логику, не теряя корректности данных. Основная проблема JOIN в файловой версии — попытка построить полное декартово произведение перед фильтрацией. Чтобы этого избежать, мы заменим прямое соединение на проверку существования записи во вложенном запросе (имитация оператора EXISTS в SQL).

Рассмотрим оптимизированный вариант этого блока:


ВЫБРАТЬ
    РасчетыСКлиентами.ПродажаПоЗаказу КАК ОтражаемыйДокумент
ИЗ
    РегистрНакопления.РасчетыСКлиентами КАК РасчетыСКлиентами
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РасчетыСКлиентамиИзменения КАК РасчетыСКлиентамиИзменения
    ПО РасчетыСКлиентами.АналитикаУчетаПоПартнерам = РасчетыСКлиентамиИзменения.АналитикаУчетаПоПартнерам
    И РасчетыСКлиентами.ОбъектРасчетов = РасчетыСКлиентамиИзменения.ОбъектРасчетов
ГДЕ
    РасчетыСКлиентами.ПродажаПоЗаказу <> НЕОПРЕДЕЛЕНО
    И ИСТИНА В (
        ВЫБРАТЬ ПЕРВЫЕ 1
            ИСТИНА
        ИЗ
            Справочник.ОбъектыРасчетов КАК ОбъектыРасчетов
        ГДЕ
            ОбъектыРасчетов.Объект = РасчетыСКлиентами.ПродажаПоЗаказу
            И ОбъектыРасчетов.ТипОбъектаРасчетов = ЗНАЧЕНИЕ(Перечисление.ТипыОбъектовРасчетов.Заказ)
            И НЕ ОбъектыРасчетов.ПометкаУдаления
    )

Почему это работает быстрее? В данном случае платформа 1С при выполнении запроса в файловом режиме прекращает поиск в справочнике ОбъектыРасчетов сразу после нахождения первого совпадения для каждой строки из левой части. Это избавляет систему от необходимости строить огромную временную таблицу со всеми возможными комбинациями соединений.

Шаг 3. Дополнительные настройки системы

Помимо правки запроса (которую можно внедрить через Расширение конфигурации), выясним, какие еще настройки влияют на скорость работы в УТ 11.5.

Режим распределения расчетов: Перейдем в раздел НСИ и администрирование — Казначейство. Найдем пункт Задания по распределению расчетов. Если установлено значение «Выполнять расчеты при записи документов», система будет тормозить при каждом нажатии кнопки «Провести». Рекомендуем переключить этот режим на «По регламентному заданию». В этом случае тяжелые расчеты будут выполняться в фоне, не блокируя работу пользователя.
Очистка таблиц изменений: Таблицы вида ...Изменения (например, РасчетыСКлиентамиИзменения) заполняются механизмом регистрации изменений. Если в базе настроена синхронизация, которая давно не запускалась, или есть «зависшие» узлы планов обмена, эти таблицы могут раздуваться до огромных размеров. Проверьте Планы обмена и удалите неиспользуемые регистрации.
Актуальность итогов: Несмотря на выполнение ТиИ, убедитесь через Управление итогами, что итоги рассчитаны по текущую дату. В файловом режиме «разлет» итогов на несколько месяцев назад заставляет систему при каждом проведении пересчитывать остатки с начала времен.

Шаг 4. Работа с антивирусом и аппаратные нюансы

Выясним причину, почему даже на SSD база может «задумываться». Файловая база 1С активно использует временные файлы в папке профиля пользователя (%TEMP%). Проанализируем следующие моменты:

Добавьте расширение *.1CD и *.1CL в исключения антивируса.
Добавьте папку с самой информационной базой и папку %LOCALAPPDATA%\1C в список исключений Windows Defender.
Если база работает через IIS или Apache (публикация на веб-сервере), убедитесь, что у пользователя, под которым запущен пул приложений, есть полные права на папку с базой.

Резюме

Проблема низкой производительности УТ 11.5 в файловом режиме чаще всего связана с неэффективным планированием сложных запросов к механизму взаиморасчетов. Рассмотрим основные шаги к «выздоровлению» базы:

Используем замер производительности для поиска самого долгого запроса.
Оптимизируем запрос через расширение, заменяя тяжелые соединения на конструкцию ГДЕ ИСТИНА В (ВЫБРАТЬ ПЕРВЫЕ 1...).
Переносим расчет взаиморасчетов в фоновое задание (регламентный режим).
Следим за размером таблиц регистрации изменений и актуальностью итогов.

Эти действия позволяют сократить время проведения документов с 20-30 секунд до вполне приемлемых 1-2 секунд, что делает работу в файловой УТ 11.5 комфортной даже на средних по мощности компьютерах.