← На главную

Каждый администратор и разработчик 1С рано или поздно сталкивается с парадоксальной ситуацией: пользователь жалуется, что тяжелый ежемесячный отчет формируется десятки минут, но при анализе производительности сервера выясняется, что нагрузка на центральный процессор (ЦП) составляет скромные 1–2%, а дисковая активность практически нулевая. Сервер выглядит абсолютно ненагруженным, однако отчет «висит». На примере отчета «Ведомость расчетов с клиентами по документам» в конфигурации «Управление торговлей 11.4» мы подробно разберем, почему так происходит, и как решить эту проблему комплексными методами.

Выясняем причину: почему загрузка ЦП и диска на сервере всего 1–2%?

Этот симптом часто вводит в заблуждение технических специалистов. На самом деле за низкой утилизацией ресурсов скрываются вполне конкретные архитектурные особенности работы платформы 1С:Предприятие 8.3 и СУБД MS SQL Server:

1. Однопоточность формирования отчета. Платформа 1С обрабатывает запрос и строит итоговый макет в один поток. Если на сервере установлен, к примеру, 32-поточный процессор, то полная загрузка одного потока (ядра) математически будет отображаться в диспетчере задач как 3% от общей мощности процессора. Одно ядро работает на пределе возможностей, пока остальные 31 ядро «отдыхают».
2. Ожидания на стороне СУБД (Wait Stats). Если сервер приложений 1С (процесс rphost) и SQL-сервер физически разделены, СУБД может быстро подготовить порцию данных и ожидать, пока 1С примет ее по сети. В этот момент возникает ожидание ASYNC_NETWORK_IO, при котором оба сервера показывают околонулевую активность.
3. Неоптимальный план запроса (Nested Loops). Из-за устаревшей статистики SQL-сервер может выбрать алгоритм соединения таблиц «вложенные циклы» (Nested Loops) вместо хэш-соединения (Hash Match). Это приводит к миллионам последовательных чтений из кэша оперативной памяти. Дисковая активность при этом равна нулю, а общая нагрузка на процессор минимальна из-за выполнения операции в один поток.
4. Конкуренция за временные таблицы в TempDB. Запросы СКД (системы компоновки данных) активно используют временные таблицы. Если системная база данных tempdb настроена некорректно, возникает конкуренция за страницы распределения памяти, и процессор простаивает в ожиданиях внутренних защелок (latch contention).

Специфика архитектуры взаиморасчетов в «Управление торговлей 11»

Типовой отчет «Ведомость расчетов с клиентами по документам» строится по регистрам накопления расчетов с клиентами. В современных конфигурациях на базе ERP-платформы (УТ 11, КА 2, ERP) существует два режима ведения взаиморасчетов:

• Офлайн-режим (отложенный расчет). Расчет и распределение оплат по документам выполняются регламентным заданием по расписанию или при закрытии месяца. Если регламентное задание не запущено, то при формировании отчета за большой период (например, за полтора года) система будет вынуждена рассчитывать всю аналитику «на лету» прямо в транзакции формирования отчета. Это колоссально замедляет процесс.
• Онлайн-режим (новая архитектура взаиморасчетов). Все расчеты, распределение авансов и сопоставление документов производятся непосредственно в момент проведения документов. Отчету не требуется ничего вычислять — он просто мгновенно считывает готовые данные.

Решение: В настройках программы перейдем в раздел НСИ и администрирование -> Казначейство и взаиморасчеты и проверим, включена ли новая архитектура взаиморасчетов (режим «Онлайн»). Если используется старый офлайн-режим, крайне рекомендуется запланировать переход на новую онлайн-архитектуру.

Тонкие настройки MS SQL Server под 1С:Предприятие

Для устранения узких мест на уровне базы данных проанализируем и скорректируем настройки MS SQL Server:

Настройка параметра MAXDOP

Для баз данных 1С настоятельно рекомендуется устанавливать параметр максимальной степени параллелизма MAXDOP = 1. Если этот параметр установлен в значение 0 (по умолчанию), SQL-сервер будет пытаться распараллелить тяжелый запрос отчета. В условиях сложной структуры таблиц 1С это гарантированно приводит к взаимным блокировкам и деградации производительности.

Использование Legacy Cardinality Estimator

Начиная с версии MS SQL Server 2014, новый оптимизатор запросов часто некорректно оценивает кардинальность (количество строк) для временных таблиц 1С, что ведет к выбору крайне неэффективных планов запросов. Чтобы исправить это, включим устаревший оценщик стоимости запросов. В свойствах базы данных SQL перейдем в раздел Database Scoped Configurations и установим для параметра Legacy Cardinality Estimation значение ON.

Протокол Shared Memory

Если сервер приложений 1С и сервер СУБД MS SQL установлены на одном физическом сервере, проверим строку подключения в кластере 1С. В качестве имени сервера баз данных следует указывать точку . или (local). Это заставит систему обмениваться данными через протокол Shared Memory (общая память), минуя сетевой стек TCP/IP, что значительно ускорит передачу больших выборок данных (например, отчетов на 170 тысяч строк).

Регламентные операции СУБД

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

• Обновление статистики (Update Statistics) — должно выполняться ежедневно. Устаревшая статистика — главная причина того, почему вчера отчет работал быстро, а сегодня «завис».
• Реиндексация и дефрагментация индексов — реиндексацию (Rebuild) высокофрагментированных таблиц следует выполнять раз в неделю (в выходные), а ежедневную дефрагментацию (Reorganize) менее фрагментированных индексов — каждую ночь.
• Очистка процедурного кэша — после обновления статистики полезно сбросить кэш планов запросов, выполнив команду FREEPROCCACHE, чтобы SQL-сервер гарантированно построил новые оптимальные планы.

Ограничения платформы 1С при выводе сверхбольших отчетов

Вывод 173 480 строк в один табличный документ — это экстремальная нагрузка на клиентское приложение и рабочий процесс rphost. Даже если база данных отдаст результат запроса за 5 секунд, платформа 1С потратит несколько минут на обработку макета, применение условного оформления, расчет итогов по группировкам и отрисовку графических элементов в памяти.

Проанализируем структуру отчета и оптимизируем настройки СКД:

• Исключим вычисляемые поля с вызовами функций общих модулей. Если программист добавил в схему компоновки вычисляемое поле, которое для каждой из 173 тысяч строк вызывает функцию общего модуля 1С (например, для получения какого-то дополнительного реквизита), формирование отчета замедлится в десятки раз из-за контекстных переходов между СУБД и сервером приложений. Перенесем все расчеты внутрь SQL-запроса.
• Ограничим детальные записи. Прочесть глазами 170 тысяч строк физически невозможно. Настроим отчет таким образом, чтобы по умолчанию выводились только верхнеуровневые группировки (например, по партнерам и договорам). Детальные записи (документы-регистраторы) пользователь должен открывать точечно с помощью стандартного механизма расшифровки СКД.
• Используем фоновое формирование отчетов. Включим в настройках отчетов типовой механизм фонового формирования. Это позволит пользователю продолжать работу в системе, пока тяжелый отчет подготавливается на сервере приложений.

Пошаговый план диагностики и ускорения отчета

Разберем последовательность действий для локализации и решения проблемы:

1. Запустим Замер производительности в конфигураторе 1С. Сформируем отчет за проблемный период. Посмотрим, какая строка кода занимает больше всего времени. Если это метод СкомпоноватьРезультат(), значит, основная проблема кроется в тяжелом SQL-запросе или неоптимальном плане на стороне СУБД.
2. Проверим состояние актуальности итогов в 1С. Перейдем в Все функции -> Стандартные -> Управление итогами (или через Администрирование). Убедимся, что итоги по регистрам взаиморасчетов рассчитаны по текущую дату. Смещение итогов назад во времени заставляет систему вычислять остатки динамически по таблицам движений, что парализует скорость выполнения отчетов.
3. Выполним регламентную процедуру Тестирование и исправление (ТиИ) информационной базы. Выберем режимы «Реиндексация таблиц» и «Пересчет итогов». Если процедуру требуется выполнять регулярно по расписанию, используется автоматическое тестирование и обслуживание нескольких баз 1С без участия пользователя.
4. Настроим в MS SQL Server технологический журнал или воспользуемся встроенным монитором активности для перехвата тяжелого запроса отчета. Проанализируем план запроса (Execution Plan). При обнаружении операции Index Scan (сканирование индекса) вместо Index Seek (поиск в индексе) создадим недостающие индексы или обновим статистику по соответствующим таблицам.

Применяя данные подходы комплексно — от оптимизации настроек СУБД до правильной настройки регламентных заданий в самой 1С — мы сможем сократить время формирования тяжелых аналитических отчетов в разы, снизив нагрузку на аппаратную часть сервера.