- Почему отчёт «План-факт бюджета» работал нестабильно
- В чём была причина проблемы
- Как удалось оптимизировать формирование отчёта
- Параллельная обработка данных: как устроено решение
- Результаты тестирования
- Что изменилось для бизнеса
- Какие выводы стоит сделать разработчикам 1С
В любой информационной системе есть отчёты, которые формируются за несколько секунд, и те, для которых приходится ждать несколько минут. Пока объём данных небольшой, это может быть незаметно. Но по мере роста базы даже привычный отчёт способен превратиться в серьёзную проблему: выполнение замедляется, сервер начинает испытывать нехватку ресурсов, а пользователь вместо результата получает сообщение об ошибке.
Именно с такой ситуацией мы столкнулись в 1С:ERP. Отчёт «План-факт бюджета» должен был показывать сопоставление плановых и фактических показателей, однако его формирование происходило нестабильно. Иногда результат удавалось получить, иногда выполнение занимало слишком много времени, а иногда отчёт завершался ошибкой нехватки оперативной памяти на сервере.
Решение оказалось не в изменении настроек отчёта или переписывании всей логики расчёта. Мы оптимизировали одну процедуру, изменив способ получения данных: вместо обработки всего годового периода за один раз организовали расчёт по месяцам с использованием фоновых заданий.
В результате удалось добиться стабильного формирования отчёта. По итогам тестирования ускоренный вариант успешно отработал во всех пяти запусках, а среднее время формирования данных за год по одной крупной статье бюджета составило 7–8 минут.
Почему отчёт «План-факт бюджета» работал нестабильно
На первый взгляд, отчёт представлял собой обычную таблицу с показателями, строками, колонками и итоговыми значениями. Однако за привычным интерфейсом скрывалась достаточно сложная обработка данных.
Отчёт использовал широкую свёртку по месяцам и сценариям, глубокую иерархию статей бюджета и значительный объём фактических данных за год. Всё это увеличивало нагрузку на сервер при формировании результата.
Пользователь мог запустить отчёт с привычными настройками, но получить совершенно разный результат: от длительного ожидания до полного завершения сеанса с ошибкой.
В журнале регистрации появлялось сообщение:
Фоновое задание. Ошибка выполнения
Выполнение отчета: ПланФактСравнение_1000
На сервере недостаточно памяти для выполнения задания.Проблема заключалась не просто в том, что отчёт работал медленно. В определённых условиях серверу не хватало памяти для выполнения задания, поэтому пользователь вообще не получал результат.
Для финансового и управленческого учёта это особенно чувствительно. Отчёт «План-факт бюджета» нужен для анализа исполнения бюджета, а значит, его доступность напрямую влияет на работу сотрудников, принимающих решения на основе плановых и фактических показателей.
Требовалось найти способ уменьшить пиковую нагрузку, не меняя привычную логику работы отчёта.
Журнал регистрации - линейный вариант отчёта
В чём была причина проблемы
Первым шагом стало сравнение двух вариантов отчёта при одинаковых условиях.
В обоих случаях использовались одна база 1С:ERP, одинаковая настройка отчёта, одна и та же схема компоновки данных и последовательный запуск одним пользователем.
Таким образом, различия в результатах нельзя было объяснить настройками пользователя или изменением структуры отчёта.
Причина оказалась в способе получения фактических данных.
В первоначальной версии процедура ОборотыФакт вызывала метод БюджетированиеСервер.ФактПоСтатьямБюджетов один раз за весь выбранный период. При формировании годового отчёта система пыталась обработать большой объём данных за один проход.
После этого данные участвовали в дальнейшей обработке средствами системы компоновки данных (СКД), где выполнялась свёртка по месяцам, сценариям и статьям бюджета.
В результате возникал высокий пик потребления оперативной памяти. Если доступных ресурсов оказывалось недостаточно, фоновое задание завершалось ошибкой.
Иными словами, проблема была связана не столько с самим объёмом данных, сколько с тем, как этот объём обрабатывался.
Основная идея оптимизации — не загружать весь годовой объём факта за один раз, а разбить обработку на небольшие независимые периоды.
Как удалось оптимизировать формирование отчёта
В ускоренной версии была изменена только одна процедура — ОборотыФакт. Бизнес-логика расчёта, схема СКД, запросы и настройки формы остались прежними.
Вместо единовременного получения фактических данных за весь период система стала разбивать его на месяцы. Для каждого месяца создавалось отдельное фоновое задание, которое рассчитывало данные и помещало результат во временное хранилище.
После обработки нескольких месяцев результаты объединялись в общую таблицу, которая затем использовалась в прежнем финальном запросе ЗапросОборотыФакт.
Таким образом, изменился механизм выполнения вычислений, но не сам принцип формирования отчёта.
Это важный момент: при оптимизации существующей системы далеко не всегда требуется полностью переписывать сложный механизм. Иногда достаточно найти участок, создающий максимальную нагрузку, и изменить способ его работы.
В данном случае точечное изменение позволило сохранить существующую реализацию отчёта и минимизировать вмешательство в бизнес-логику.
Параллельная обработка данных: как устроено решение
В основе решения лежит использование фоновых заданий 1С. Они позволяют вынести отдельные операции в самостоятельные задачи и организовать их выполнение независимо от основного потока.
Работа ускоренной версии строится следующим образом.
- Разделение периода. Выбранный год разбивается на отдельные месяцы, для каждого из которых формируется набор параметров расчёта.
- Запуск фоновых заданий. Для обработки месячных периодов создаются задания, использующие процедуру
Деке_РегламентныеЗадания.СформироватьПланФактМногопоточно. - Обработка небольшими партиями. Задания запускаются группами по три месяца. Это позволяет ограничивать количество одновременно обрабатываемых периодов и контролировать нагрузку.
- Ожидание завершения. Перед переходом к следующей партии система ожидает окончания запущенных заданий с помощью метода
ОжидатьЗавершения(). - Сбор результатов. Полученные данные извлекаются из временного хранилища и объединяются в общую таблицу значений.
- Финальное формирование отчёта. После завершения обработки выполняется прежний запрос, использующий собранные фактические данные.
Для периодов, укладывающихся в один месяц, сохранён первоначальный линейный сценарий. В этом случае создание дополнительных фоновых заданий не требуется, поэтому система не выполняет лишних операций.
Отдельного внимания заслуживает сборка итоговой таблицы. Вместо последовательного добавления каждой строки сначала создаётся необходимое количество пустых строк, после чего они заполняются значениями соответствующих колонок.
Такой подход позволяет избежать лишних операций при обработке большого количества строк и снижает накладные расходы на формирование общей таблицы.
При этом важно учитывать, что разделение вычислений по месяцам само по себе не гарантирует ускорения любой обработки. Эффект зависит от объёма данных, особенностей запросов, доступных ресурсов сервера и накладных расходов на создание фоновых заданий. В данном случае результат подтверждён тестированием конкретного отчёта.
Результаты тестирования
Для сравнения были выполнены тестовые запуски двух вариантов отчёта. Условия оставались одинаковыми: одна база 1С:ERP, один пользователь, одинаковая настройка, один и тот же период и последовательное выполнение.
Каждый вариант проверялся пять раз.
| Показатель | Первоначальная версия | Оптимизированная версия |
|---|---|---|
| Успешные формирования | 0 из 5 | 5 из 5 |
| Формирование годового отчёта | Завершение с ошибкой нехватки памяти | В среднем 7–8 минут |
| Ошибка нехватки памяти | Возникала | Не возникала в тестовых запусках |
| Объём данных в одном задании | Фактические данные за весь год | Данные за отдельный месяц |
| Результат для пользователя | Отчёт не получен | Отчёт сформирован |
В одном из успешных запусков оптимизированной версии были зафиксированы следующие показатели:
- Начало: 21.10.2026, 09:51:46.
- Завершение: 21.10.2026, 09:58:21.
- Общее время: около 6 минут 35 секунд.
- Ошибки выполнения: отсутствовали.
По серии из пяти запусков среднее время формирования данных за год по одной крупной статье бюджета составило 7–8 минут.
Здесь важно правильно интерпретировать результат. Главный эффект оптимизации заключается не только в скорости, но и в стабильности. Первоначальная версия не завершила успешно ни один из пяти тестовых запусков, тогда как новая версия успешно отработала во всех пяти случаях.
При этом речь идёт о результатах конкретного тестирования, а не о гарантированном времени выполнения для любой базы, статьи бюджета или конфигурации сервера.
Что изменилось для бизнеса
На первый взгляд, изменение одной процедуры — небольшая техническая доработка. Однако её эффект проявляется в повседневной работе пользователей.
1. Отчёт стал доступен для использования.
Вместо завершения сеанса с ошибкой пользователь получает сформированный результат и может продолжать работу с данными.
2. Нагрузка на сервер стала более предсказуемой.
Обработка разделена на небольшие периоды. Вместо одного задания, которому требуется удерживать большой объём данных за год, система выполняет расчёты по месяцам.
3. Снизился риск отказа из-за пикового потребления памяти.
Каждое задание работает с ограниченным временным срезом данных. В протестированных сценариях это позволило избежать ошибки нехватки памяти.
4. Существующая бизнес-логика осталась нетронутой.
Оптимизация затронула одну процедуру. Не потребовалось заново проектировать отчёт, менять настройки компоновки данных или перестраивать пользовательский интерфейс.
5. Сохранился привычный сценарий работы.
Пользователь продолжает работать с тем же отчётом и теми же настройками. Изменения происходят на уровне внутреннего механизма обработки данных.
Для бизнеса это означает более предсказуемую работу инструмента бюджетного контроля без необходимости масштабной переработки существующей системы.
Какие выводы стоит сделать разработчикам 1С
Этот пример показывает, что при анализе производительности важно смотреть не только на запросы, настройки СКД и объём исходных данных, но и на стратегию выполнения вычислений.
Даже если отчёт настроен правильно, способ получения и обработки данных может создавать чрезмерную нагрузку на сервер.
При работе с подобными ситуациями стоит учитывать несколько практических рекомендаций.
- Разделяйте большие периоды на небольшие интервалы. Для годовых отчётов с большим объёмом факта помесячная обработка может оказаться эффективнее единовременной загрузки всего периода.
- Контролируйте количество фоновых заданий. Параллельная обработка не означает, что нужно запускать все задачи одновременно. Чрезмерная конкуренция за процессор, память и ресурсы информационной базы способна создать новые проблемы.
- Продумывайте механизм объединения результатов. При больших объёмах данных накладные расходы на сборку общей таблицы тоже могут быть существенными.
- Сохраняйте исходную бизнес-логику, если проблема локализована. Точечная оптимизация зачастую проще в сопровождении и безопаснее масштабной переработки.
- Проверяйте результат в одинаковых условиях. Сравнение должно учитывать не только время выполнения, но и успешность завершения, ошибки и потребление ресурсов.
При реализации подобной схемы также необходимо учитывать корректность обработки граничных дат, передачу параметров фоновых заданий, обработку ошибок отдельных задач и гарантированное завершение всех запущенных вычислений. Эти аспекты важны для надёжной эксплуатации решения.
Итог
Оптимизация отчёта «План-факт бюджета» в 1С:ERP — пример того, как изменение внутреннего механизма обработки способно решить проблему, которую невозможно устранить одними настройками.
Вместо единовременной обработки годового объёма фактических данных была реализована помесячная обработка с использованием фоновых заданий и последующим объединением результатов.
В результате оптимизированная версия успешно завершила все пять тестовых запусков, а среднее время формирования данных за год по одной крупной статье бюджета составило 7–8 минут. При этом структура отчёта, настройки и бизнес-логика остались прежними.
Главный вывод: если отчёт в 1С работает нестабильно, причина не всегда заключается в сложности самого запроса. Иногда решающее значение имеет то, как организовано выполнение обработки и какой объём данных система пытается удерживать в памяти одновременно.
Грамотная диагностика и точечная оптимизация позволяют повысить надёжность существующих решений без необходимости полностью переделывать работающую систему.