Тяжёлые отчёты в 1С: почему тормозят и что помогает

Почему отчёт идёт минутами

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

• Нет отбора по периоду. Отчёт тянет все документы за всю историю, а нужен один месяц.
• Неподходящий источник. Данные собираются по документам вместо регистров — это всегда медленнее.
• Избыточные соединения и вычисления. Расчёты в цикле по строкам выборки, лишние соединения таблиц.
• Настройки СКД. Детальные записи вместо итогов, отсутствие свёртки, «все группировки сразу».
• Объёмы. База выросла в разы, а отчёт писали под прежние размеры.

Документы или регистры: главная разница

Самая частая причина медленных отчётов — источник данных. Когда отчёт собирает показатели по документам, платформа вынуждена читать и разбирать каждую строку каждого документа. Регистры хранят уже свёрнутые данные, поэтому отчёт по регистрам считается в разы быстрее на тех же объёмах.

Настройки СКД

Иногда проблема вообще не в запросе, а в настройках: включены детальные записи, выведены все группировки, нет свёртки и итогов. Включение свёртки и итогов уменьшает объём данных, который платформа передаёт и отображает, — иногда это даёт ускорение без единой строки кода.

Что можно поправить без доработки

• Проверить, не снят ли отбор по периоду и организации в самом отчёте.
• Включить свёртку и итоги в настройках СКД, убрать неиспользуемые группировки.
• Настроить регламентное задание: тяжёлые отчёты удобнее готовить заранее, а не ждать в момент сдачи.
• Проверить индексы и регламентные операции обслуживания базы (пересчёт итогов, реиндексация).

Когда нужна доработка

• Отчёт собирается по регистрам, а не по документам.
• Нужны собственные «итоги» или промежуточные таблицы, чтобы не считать одно и то же каждый раз.
• Требуется выгрузка в Excel и автообновление по расписанию.
• Отчёт нужен в разрезах, которых нет в типовом (по менеджерам, по маржинальности, по срокам поставки).

Как понять, где узкое место

Гадание тут не помогает. Работает замер: выполнить отчёт на копии базы, замерить время, посмотреть план запроса и технологический журнал. После этого видно, что именно менять — запрос, индексы или логику отчёта. Правки без замера обычно дают «ускорилось вроде бы».

Что показывает замер

• План запроса — где именно платформа тратит время и какие операции самые дорогие.
• Технологический журнал — блокировки, долгие вызовы, влияние фоновых заданий.
• Замер на копии — «до» и «после», а не ощущения.

Сколько занимает ускорение

Как формулировать задачу на ускорение

Лучший формат — измеримый: «отчёт по марже должен считаться не дольше 10 секунд за месяц по всем организациям на копии базы». Тогда есть критерий приёмки, и понятно, когда работа закончена. Подробнее — в заметке «Как описать задачу по 1С».

Частые ошибки

• Править без замера. Тогда непонятно, что именно помогло и помогло ли вообще.
• Тюнинговать сервер вместо запроса. «Дадим больше памяти» не лечит плохой запрос.
• Ошибиться с источником. Отчёт по документам останется медленным, как его ни настраивай.
• Запускать тяжёлый отчёт в часы пик. Блокировки замедляют работу всей базы.
• Не проверять результат на реальных данных. Ускоренный отчёт должен выдавать те же цифры.

Как это выглядит на практике

Пример из типовой ситуации: отчёт по марже за месяц считался около четырёх минут и запускался по несколько раз в день. Причина оказалась двойной — данные собирались по документам, а в СКД были включены детальные записи.

Что сделали: перевели расчёт на регистры, добавили отбор по периоду и включили свёртку с итогами. Результат — около восьми секунд на тех же данных, цифры сходятся с прежними. Никакого «железа» не добавляли.

Такие истории — не про магию, а про последовательность: замер, поиск узкого места, точечная правка, повторный замер.

Как проходит работа над ускорением

1. Получаю копию базы и воспроизвожу медленный отчёт.
2. Замеряю время и смотрю план запроса: где тратится основное время.
3. Определяю, что даст результат: настройки, запрос, перенос на регистры или всё вместе.
4. Вношу правки на копии и замеряю «до и после».
5. Проверяю, что цифры совпадают с прежними, и выкатываю на рабочую базу.

Порядок замера

Замер имеет смысл, когда он воспроизводим: одна и та же копия базы, один период, одни организации. Иначе «до» и «после» несравнимы, и любые выводы превращаются в догадки.

Сначала фиксируем текущее время, затем смотрим план запроса и только после этого меняем что-то одно. Так видно, что именно дало эффект.

Что обычно не помогает

Ошибочные способы, которые только откладывают решение:

• Добавить памяти и процессоров. Плохой запрос останется плохим на любом железе.
• Разбить отчёт на несколько мелких. Часто становится только дольше: появляются повторные обращения к данным.
• Править «на глаз», без замера. Непонятно, что помогло, а что нет.
• Переносить тяжёлый отчёт на ночь без пересмотра логики. Проблема остаётся, просто не мешает днём.
• Игнорировать обслуживание базы. Пересчёт итогов и реиндексация часто дают эффект без правок кода.

Почему «дадим больше памяти» не работает

Ресурсы помогают, когда в них действительно упираются: например, не хватает памяти под временные таблицы. Но если проблема в том, что отчёт читает документы вместо регистров, дополнительные гигабайты ничего не изменят — изменится только счёт за сервер.

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