Бухгалтер запускает отчёт по продажам. Через полминуты появляется индикатор, а результат — через пять минут. Такую сцену приводит fast1c.by в разборе медленных отчётов СКД.
Покупка нового сервера пока ничем не обоснована. Сначала выясните, где прошли эти пять минут: в СУБД, на сервере 1С или при выводе результата.
Отчёт СКД проходит три этапа. Система компоновки данных отправляет запрос в СУБД, собирает табличную модель на сервере 1С и выводит её клиенту. Задержка на каждом этапе требует своего исполнителя и своего действия.
Ваша задача — за один повторный запуск локализовать задержку. После этого разработчик или администратор получит проверяемую задачу вместо просьбы «посмотреть производительность».
Один замер делит время отчёта на три этапа
Запустите отчёт с включённым замером производительности. В разборе fast1c.by указан путь: «Сервис → Замер производительности».
Повторите исходный сценарий без изменений. Возьмите тот же вариант отчёта, период, организацию, пользователя и состав отборов. Иначе вы сравните разные запросы.
Замер покажет длительность отдельных операций. Для серверной базы дополните его технологическим журналом 1С. Долгое событие DBMSSQL означает, что платформа ждала выполнения запроса в СУБД, пишет fast1c.by.
| Где ушло время | Что видно при проверке | Кто продолжает диагностику | Что передать |
|---|---|---|---|
| Запрос к СУБД | Длительное событие DBMSSQL | Разработчик 1С и администратор СУБД | Текст SQL, план выполнения, параметры отчёта и имя пользователя |
| Компоновка на сервере 1С | SQL завершился, но сервер продолжает собирать результат | Разработчик отчёта | Вариант отчёта, группировки, вычисляемые поля и условное оформление |
| Вывод клиенту | Табличная модель готова, задержка остаётся при отображении | Разработчик отчёта и системный администратор | Число строк, уровень детализации, клиент 1С и способ подключения |
Эта таблица задаёт границу ответственности. Сервер обсуждают после локализации задержки, а не вместо неё.
Снимите замер дважды. Первый запуск может попасть на холодный кэш, второй — использовать уже прочитанные данные и готовые планы. Эти результаты нельзя выдавать за лабораторный тест, но разница поможет сформулировать проверку для администратора СУБД.
Зафиксируйте контекст запуска:
- имя отчёта и его вариант;
- период и пользовательские отборы;
- учётную запись пользователя;
- время начала и завершения;
- длительность
DBMSSQL; - число строк в готовом отчёте.
Так разработчик сможет повторить тот же сценарий. Без этих данных фраза «отчёт строится пять минут» почти бесполезна.
Медленный запрос часто читает данные, которые не попадут в отчёт
Fast1c.by связывает с запросом девять из десяти разобранных случаев медленного отчёта СКД. Это наблюдение автора разбора, а не статистика нашей лаборатории. Для конкретной базы вывод всё равно надо подтвердить замером.
Первый кандидат — виртуальная таблица регистра без параметров. СУБД читает большой массив записей, хотя отчёту нужен один период или одна организация.
Похожая ошибка возникает, когда период задан пользовательским отбором. Параметр набора данных ограничивает выборку на стороне СУБД. Пользовательский отбор СКД может сработать позже, когда строки уже переданы на сервер 1С.
Допустим, в регистре хранится история за несколько лет, а бухгалтер строит отчёт за месяц. Если период попал только в отбор варианта, запрос способен забрать историю целиком и удалить лишние строки уже при компоновке. Fast1c.by описывает именно такой механизм.
Третий кандидат — соединение крупных таблиц до ограничения периода. СУБД сначала строит большой промежуточный набор, а затем отбрасывает записи. При неудачном условии соединения объём промежуточных данных растёт ещё сильнее.
| Признак | Вероятная причина | Что запросить у разработчика |
|---|---|---|
| Отчёт за месяц читает историю регистра | Период задан отбором варианта, а не параметром набора данных | Передать границы периода в параметры запроса |
| В запросе есть виртуальная таблица без параметров | СУБД строит набор без раннего ограничения | Задать период и другие доступные условия в параметрах виртуальной таблицы |
| После соединения резко растёт число строк | Крупные таблицы соединяются до отбора | Ограничить каждую сторону соединения до объединения данных |
| SQL содержит коррелированный подзапрос | Подзапрос повторяется для каждой строки результата | Заменить повторное вычисление соединением или заранее подготовленным набором |
| Один пользователь ждёт дольше остальных | RLS добавляет условия по правам и меняет план | Сравнить SQL и план под разными наборами прав |
| SQL завершается быстро, но отчёт ещё строится | Задержка находится в компоновке или выводе | Проверить группировки, вычисляемые поля, оформление и детализацию |
Сначала сокращают набор на стороне СУБД. Оформление отчёта и серверное оборудование проверяют после этого.
Не просите разработчика «оптимизировать запрос» без приложения. Передайте вариант отчёта, параметры запуска, событие DBMSSQL, текст SQL и план выполнения. Такая задача проверяется повторным замером.
План SQL показывает лишнее чтение и сброс на диск
Технологический журнал 1С сохраняет SQL, который СКД сформировала для СУБД. Fast1c.by рекомендует брать этот текст из журнала и изучать план выполнения.
Для Microsoft SQL Server план открывают в SQL Server Management Studio. Операция scan означает просмотр индекса или таблицы, а seek — обращение к подходящему диапазону индекса. Сам по себе scan не доказывает ошибку: маленькую таблицу СУБД может прочитать целиком быстрее.
Смотрите на объём строк и место операции в плане. Если SQL читает большой регистр целиком, а отчёт возвращает небольшой период, разработчику надо проверить параметры виртуальной таблицы и условия соединения.
Сброс промежуточных данных на диск указывает на другую развилку. Запросу могло не хватить выделенной памяти, либо он построил слишком большой набор из-за своей структуры. Установка дополнительных модулей памяти не исправит соединение, которое размножает строки.
Сначала разработчик сокращает промежуточный набор. Затем администратор проверяет память, tempdb, статистику и настройки экземпляра SQL Server. Порядок важен: иначе аппаратный ресурс маскирует плохой запрос, но не устраняет его.
После подтверждённой задержки в СУБД переходите к настройке SQL Server для 1С. Не переносите параметры из чужого примера вслепую: сверяйте их с версией SQL Server, объёмом RAM и соседними службами на узле.
Права пользователя способны изменить план запроса
СКД добавляет в SQL пользовательские отборы, сортировку и ограничения доступа. RLS — ограничения доступа на уровне записей — дополняет запрос условиями для конкретного пользователя.
Новое условие способно изменить порядок соединений и выбранные индексы. Поэтому отчёт у администратора может строиться быстро, а у бухгалтера — медленно при тех же видимых настройках.
Сравните два запуска: под проблемной учётной записью и под пользователем с другим набором прав. Период, вариант отчёта и остальные параметры должны совпадать.
Если различаются текст SQL или план, приложите оба варианта к задаче разработчику. Проверять только запуск под полными правами нельзя: он воспроизводит другой запрос.
Отдельно ищите подзапросы в вычисляемых выражениях. По разбору fast1c.by, такой подзапрос может выполняться для каждой строки результата. При росте выборки его цена повторяется вместе с числом строк.
После SQL время забирает компоновка
Быстрый DBMSSQL не означает, что весь отчёт готов. Получив строки, сервер 1С формирует табличную модель: считает ресурсы, строит группировки и применяет вычисляемые поля.
Каждый уровень группировки требует своего набора агрегаций. Отчёт с организацией, подразделением, номенклатурой, документом и регистратором выполняет больше работы, чем сводка по организации и подразделению.
Вычисляемые поля СКД считаются при выводе, а не внутри исходного SQL. Условное оформление проверяет ячейки по заданным условиям. Чем больше строк и правил, тем заметнее этот этап.
Проверьте упрощённый вариант того же отчёта. Оставьте один-два уровня группировки, уберите необязательные вычисляемые поля и отключите условное оформление. Исходный запрос и период менять не надо.
Если упрощённый вариант строится быстрее при сопоставимом времени SQL, причина находится в компоновке. Разработчику не нужен новый индекс: ему надо сократить работу СКД после получения данных.
Не превращайте рабочий отчёт в плоскую выгрузку ради одной редкой проверки. Сделайте два варианта:
- краткий — для ежедневной работы и контроля итогов;
- детальный — для поиска расхождений по документам.
Fast1c.by также советует включать настройку «Иерархия выводится с группировкой». Она сокращает число одновременно показанных строк, когда пользователю не нужна раскрытая иерархия целиком.
Вывод табличного документа тоже занимает время
После компоновки клиенту ещё надо показать результат. Fast1c.by отмечает, что рендеринг десятков тысяч строк может занимать несколько секунд.
Признак этого этапа прост: SQL и серверная компоновка завершились, но окно отчёта продолжает заполняться. При удалённом подключении к задержке добавляется передача результата клиенту.
Сначала сократите детализацию. Если бухгалтеру нужны итоги продаж по подразделениям, не выводите в том же варианте каждую строку документа. Детали можно раскрывать отдельным вариантом или расшифровкой.
Проверьте отчёт на обычном рабочем месте и рядом с сервером. Это не заменяет замер, но отделяет медленный вывод на конкретном клиенте от одинаковой задержки для всех пользователей.
Не делайте вывод о процессоре по одному большому табличному документу. Новый CPU не сократит число строк, которые клиент должен получить, оформить и показать.
Память и диски проверяют после запроса
Аппаратную причину стоит искать, когда медленны разные отчёты либо план показывает ожидание ресурса. Один неудачный вариант СКД ещё не доказывает нехватку сервера.
При дефиците RAM операционная система переносит часть данных в файл подкачки, пишет Iteron. Диск отвечает медленнее оперативной памяти, поэтому задержки появляются сразу в нескольких операциях.
Сопоставьте время отчёта с использованием памяти и подкачки. Если подкачка растёт во время разных запросов, продолжите проверку по инструкции о нехватке памяти на сервере 1С.
Диск проверяют при сбросе временных данных, высоких задержках ввода-вывода и конкуренции за хранилище. Сравнение дисков для сервера 1С пригодится после такого подтверждения. Оно не заменяет план SQL и не доказывает, что конкретному отчёту нужен NVMe.
Настройки PostgreSQL или Microsoft SQL Server тоже проверяют после локализации. Не копируйте work_mem, shared_buffers, MAXDOP и параметры tempdb из общей статьи без проверки документации вашей версии и текущей нагрузки.
Универсального значения памяти для отдельного запроса нет. Оно зависит от числа одновременных сеансов, структуры плана и других служб на том же узле.
Что передать исполнителю после замера
Если долго выполняется DBMSSQL, передайте разработчику текст SQL и план. Попросите проверить параметры периода, виртуальные таблицы, порядок соединений, подзапросы и влияние RLS.
Если SQL завершился быстро, а время ушло в компоновку, приложите вариант отчёта. Укажите группировки, вычисляемые поля, правила оформления и число строк результата.
Если задержку создаёт вывод, подготовьте краткий вариант без лишней детализации. Затем сравните клиентские рабочие места при одинаковых параметрах отчёта.
Если одновременно медленны разные отчёты и растёт подкачка, подключайте администратора сервера и СУБД. Ему нужны график памяти, активность файла подкачки, ожидания диска и планы запросов.
После настройки повторите исходный запуск. Условия должны совпадать с первым замером. Иначе сокращение времени нельзя связать с конкретным изменением.
Новый сервер обсуждают после двух ответов: на каком этапе ушло время и какой ресурс ждал этот этап. Пока ответов нет, замена железа остаётся догадкой.
Проверка после диагностики занимает один повторный сценарий:
- Запустите замер производительности с прежними параметрами отчёта.
- Найдите длительный этап:
DBMSSQL, компоновку или вывод. - Приложите к задаче артефакт этого этапа: SQL и план либо вариант СКД.
- Повторите запуск после одного изменения.
- Покупку сервера обсуждайте только при подтверждённом ожидании RAM, диска или CPU.