Каждый практикующий специалист сталкивался с ситуацией, когда пользователи начинают массово жаловаться на медленную работу программы при формировании определенных документов или отчетов. Особенно остро эта проблема проявляется при подготовке регламентированной отчетности или тяжелых аналитических форм. В данной статье мы детально разберем одну из самых частых и неприятных проблем: долгое формирование документа Акт сверки взаиморасчетов в программе 1С:Предприятие 8.3 на примере конфигурации Бухгалтерия государственного учреждения 2.0 (БГУ 2.0).
Представим типовой сценарий: в компании активно работают около 50 пользователей. На сервере развернута база данных, рабочие места подключены локально, и в целом система функционирует стабильно. Однако, как только бухгалтер пытается запустить Акт сверки, программа буквально «зависает» на 25 минут и более. Давайте разберем по шагам, почему возникает эта проблема, как провести глубокую диагностику и какие конкретные технические шаги помогут радикально ускорить систему.
Для начала проанализируем архитектуру и логику работы системы. Медленная генерация Акта сверки редко связана с каким-то одним фактором. Как правило, это комплексная проблема, складывающаяся из нескольких критических уязвимостей:
1Cv8.1CD), то при количестве активных пользователей более 10–15 человек неизбежно возникают постоянные взаимные блокировки таблиц. Файловая СУБД обрабатывает транзакции последовательно. Когда один пользователь запускает тяжелый расчет, требующий сканирования миллионов строк, вся остальная база фактически блокируется для записи и чтения. Попытка решить проблему простой публикацией базы на веб-сервере IIS решает лишь вопрос каналов связи, но никак не увеличивает скорость расчетов внутри самого файла СУБД.LINT или Микос РП) могут перехватывать стандартные обработчики проведения или заполнения табличных частей (через аннотации &Вместо, &Перед, &После), накладывая неоптимальные циклы или дополнительные ресурсоемкие запросы к базе данных.Прежде чем приступать к оптимизации кода или модернизации инфраструктуры, мы должны точно локализовать "узкое горлышко" (bottleneck). Для этого воспользуемся встроенным инструментом платформы 1С — Замером производительности.
Рассмотрим по шагам, как правильно выполнить профилирование:
-debug.Перед нами откроется таблица со списком всех выполненных строк кода. Отсортируйте таблицу по колонке % времени. Проанализируем полученные результаты. Если наибольший процент времени занимает выполнение метода ВыполнитьПакет() или Выполнить() у объекта Запрос, проблема кроется в СУБД и индексах. Если же время тратится на строки вывода областей макета, например, Вывести() или Присоединить(), дело в графике или медленном рендеринге.
Если база данных работает в файловом режиме, регулярное обслуживание жизненно необходимо. Выполним комплекс регламентных процедур. Важно: все действия выполняются строго в монопольном режиме, когда все пользователи вышли из системы, и после создания резервной копии базы данных.
Сначала проверим физическую целостность базы данных с помощью утилиты chdbfl.exe, которая находится в каталоге установки платформы (например, C:\Program Files\1cv8\8.3.XX.XXXX\bin\chdbfl.exe). Запустите утилиту, укажите путь к файлу 1Cv8.1CD, установите флаг "Исправлять обнаруженные ошибки" и выполните проверку.
После этого запустим логическое восстановление структуры через встроенный механизм 1С. Откроем Конфигуратор и перейдем в меню Администрирование -> Тестирование и исправление. Установим следующие флаги:
Также рекомендуется очистить локальный кэш конфигурации на компьютерах пользователей. Кэш часто забивается устаревшими метаданными форм, что приводит к задержкам при их отрисовке.
Как показывает практика, очень часто Акт сверки тормозит из-за некорректно сверстанного макета печатной формы. Если в макет внедрена картинка (логотип, печать, факсимиле) методом простого копирования из буфера обмена (например, из Word), то внутри XML-структуры макета создается огромный неоптимальный двоичный объект. При формировании многостраничного документа память сервера быстро переполняется.
Чтобы исправить это, откройте макет печатной формы в Конфигураторе, удалите проблемный рисунок. Сохраните логотип как обычный файл формата PNG или JPG с минимальным разрешением (достаточным для печати, например, 150 DPI) и вставьте его в макет через меню: Таблица -> Рисунки -> Вставить картинку....
Еще одна неочевидная проблема кроется в способе передачи сформированного табличного документа с сервера на клиент. Если код формирует тяжелый отчет на сервере и напрямую возвращает его на клиент, происходит длительная сериализация объекта. Проанализируем правильный паттерн передачи через временное хранилище:
// Неоптимальный вариант:
&НаСервере
Функция СформироватьПечатнуюФормуНаСервере()
ТабДок = Новый ТабличныйДокумент;
// ... Заполнение документа данными ...
Возврат ТабДок; // Передается напрямую, вызывая тормоза при больших объемах данных
КонецФункции
// Оптимальный вариант:
&НаСервере
Функция СформироватьПечатнуюФормуЧерезХранилищеНаСервере()
ТабДок = Новый ТабличныйДокумент;
// ... Заполнение документа данными ...
АдресХранилища = ПоместитьВоВременноеХранилище(ТабДок, УникальныйИдентификатор);
Возврат АдресХранилища;
КонецФункции
&НаКлиенте
Процедура СформироватьИВывести()
Адрес = СформироватьПечатнуюФормуЧерезХранилищеНаСервере();
ТабДокКлиент = ПолучитьИзВременногоХранилища(Адрес);
ТабДокКлиент.Показать();
КонецПроцедуры
Использование ПоместитьВоВременноеХранилище позволяет избежать избыточной нагрузки на сетевой стек и оперативную память при передаче больших объемов данных между контекстом сервера и клиента.
Если в системе подключены сторонние расширения, такие как LINT или Микос РП, они могут напрямую влиять на алгоритмы сбора данных для Акта сверки. Чтобы проверить эту гипотезу, выполните следующие действия в копии базы данных:
Если без расширений отчет формируется быстро (например, за 10–15 секунд вместо 25 минут), значит, одно из расширений содержит неоптимальный обработчик события, который перехватывает процедуру заполнения. В таком случае программисту необходимо детально исследовать модули расширений, обращая внимание на аннотации &Вместо, переопределяющие запросы к базе данных.
Если в базе данных одновременно работают 50 сотрудников, то никакие локальные оптимизации запросов и чистка кэша не дадут долгосрочного эффекта в файловом режиме работы. Файловая СУБД 1С просто физически не рассчитана на параллельную работу такого количества пользователей.
Единственным надежным решением является переход на клиент-серверный вариант работы. Для этого потребуется развернуть:
В клиент-серверной архитектуре все тяжелые вычисления, построение временных таблиц и расчеты остатков для Акта сверки будут выполняться непосредственно на мощном сервере СУБД с использованием транзакционного механизма блокировок на уровне строк, а не таблиц целиком. Клиентские компьютеры будут получать только готовый результат для отображения, что полностью исключит зависания программы.
Также не забывайте своевременно обновлять платформу 1С:Предприятие. Устаревшие релизы платформы (например, ветка 8.3.12) содержат известные проблемы с утечкой памяти и неоптимальной работой с индексами. Рекомендуется обновить платформу до актуальных поддерживаемых релизов (ветки 8.3.21, 8.3.22 или выше) и установить свежий релиз конфигурации БГУ 2.0, в котором разработчики 1С уже применили множество патчей для ускорения расчета взаиморасчетов.
Для быстрого и эффективного устранения зависаний при формировании Акта сверки мы рекомендуем действовать последовательно: сначала провести диагностику с помощью замера производительности, затем выполнить обслуживание базы данных (реиндексацию и пересчет итогов) и проверить оптимизацию макета печатной формы. Кардинальным же решением для компании с 50 активными пользователями станет перевод базы данных на клиент-серверную архитектуру под управлением SQL.