Как выявить ресурсоёмкие регламентные задания и устранить замедления в 1С:Комплексная автоматизация

Проблемы с производительностью в крупных базах 1С, особенно при использовании расширений для работы с маркетплейсами, — это классическая ситуация для высоконагруженных систем. Когда база достигает объема в сотни гигабайт (в нашем случае 430 ГБ), а интерфейс начинает «подмерзать» даже в простое, необходимо переходить от поверхностного наблюдения к глубокой диагностике. Разберем пошагово, как выявить виновников нагрузки и оптимизировать систему.

Этап 1. Локализация проблемы: СУБД или Сервер 1С

Прежде чем приступать к анализу кода, нам необходимо понять, на каком уровне происходит «затык». Рассмотрим основные показатели. Если тест Гилёва показывает значительное падение под нагрузкой (с 30 до 17 единиц), это явный признак нехватки ресурсов процессора или блокировок на уровне СУБД.

Проанализируем настройки сервера:

1. Режим электропитания: Убедимся, что на физическом сервере и в настройках Windows установлен режим «Максимальная производительность». Для процессоров Xeon с Turbo Boost это критично, так как парковка ядер или снижение частоты в моменты простоя могут вызывать микрофризы при резком старте регламентного задания.
2. Shared Memory: Если MS SQL Server и сервер 1С установлены на одной физической машине, обязательно проверим использование протокола Shared Memory. Это исключит лишние накладные расходы на сетевой стек.
3. Настройки MS SQL Server: Для баз объемом более 400 ГБ крайне важен параметр MAXDOP (Maximum Degree of Parallelism). Рекомендуем установить его в значение 1. Это предотвратит ситуацию, когда один тяжелый запрос от расширения маркетплейса пытается захватить все 10 ядер процессора, парализуя работу остальных пользователей. Также проверим Cost Threshold for Parallelism — значение должно быть не ниже 50.

Этап 2. Использование встроенных инструментов «Оценки производительности»

В современных конфигурациях, таких как 1С:Комплексная автоматизация 2.5, встроен мощный механизм на базе БСП для мониторинга скорости работы. Рассмотрим, как его активировать.

Перейдем в раздел НСИ и администрирование — Обслуживание — Оценка производительности. Здесь необходимо установить флаг Оценка производительности. После этого система начнет записывать время выполнения ключевых операций.

Выполним следующие действия:

• Создадим профили ключевых операций для проблемных участков (например, проведение заказов или загрузка отчетов комиссионера).
• Проанализируем отчет «Ключевые операции», который покажет APDEX (индекс производительности). Если значения ниже 0.85 — операция выполняется недопустимо долго.
• В этом же разделе можно увидеть замеры времени, которые помогут понять, какие именно действия пользователей или фоновые процессы занимают больше всего времени.

Этап 3. Диагностика «зависания» курсора в простое

Ситуация, когда пользователь ничего не делает, а курсор показывает загрузку, часто указывает на работу обработчиков ожидания на клиенте. В расширениях для маркетплейсов разработчики часто используют механизмы периодического опроса сервера.

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

// Пример потенциально опасного кода в расширении
Процедура ПриНачалеРаботыСистемы()
    // Интервал 5 секунд слишком мал для тяжелых запросов
    ПодключитьОбработчикОжидания("ПроверитьСтатусыЗаказовМаркетплейсов", 5);
КонецПроцедуры

Если процедура ПроверитьСтатусыЗаказовМаркетплейсов обращается к базе данных или выполняет тяжелые вычисления на сервере, интерфейс будет «замирать» каждые 5 секунд. Выясним, есть ли такие вызовы в модулях расширений, и попробуем увеличить интервал до разумных пределов (например, 300 секунд).

Этап 4. Поиск ресурсоёмких фоновых заданий через конфигуратор

Если консоль заданий не дает полной картины, воспользуемся Замером производительности в конфигураторе. Это позволит увидеть, на каких именно строках кода «висят» фоновые процессы.

Выполним замер по шагам:

1. Запустим базу в режиме отладки.
2. В конфигураторе перейдем в меню Отладка — Подключение.
3. Выберем интересующее нас фоновое задание (тип клиента — BackgroundJob).
4. Включим Замер производительности (F12).
5. Подождем 1-2 минуты и выключим замер.

В открывшемся окне мы увидим таблицу. Обратим внимание на колонку «Чистое время». Именно здесь будут видны процедуры расширений маркетплейсов, которые потребляют 90% ресурсов. Часто это оказываются запросы к огромным регистрам сведений без использования индексов.

Этап 5. Работа с «раздутыми» регистрами

Вы упоминали, что почти половину базы (около 200 ГБ) занимают регистры маркетплейсов. Это критический момент. Даже если регламентное задание просто «просматривает» такой регистр, это создает колоссальную нагрузку на дисковую подсистему NVMe и оперативную память.

Рекомендации по оптимизации данных:

• Полнотекстовый поиск: Проверим, включен ли полнотекстовый поиск для этих тяжелых регистров. Если да — индекс ПП будет обновляться постоянно, вызывая те самые «тормоза в простое». Попробуем временно отключить его в разделе Администрирование — Полнотекстовый поиск.
• Очистка данных: Если разработчики подтвердят возможность очистки, не стоит делать это простым удалением через НаборЗаписей. При таком объеме лог транзакций SQL переполнится мгновенно. Лучше использовать порционное удаление или, если это допустимо, TRUNCATE TABLE на уровне СУБД (с последующим пересчетом итогов).
• Обслуживание индексов: После удаления больших объемов данных обязательно выполним Reorganize и Rebuild индексов. Без этого SQL-сервер продолжит «спотыкаться» о пустые страницы в файлах базы данных.

Этап 6. Настройка Технологического Журнала (ТЖ)

Для окончательного выявления «виновников» среди регламентных заданий, настроим сбор событий DBMSSQL и CALL. Это позволит увидеть текст SQL-запроса, который выполняется слишком долго.

Пример файла настроек logcfg.xml для поиска долгих запросов (более 10 секунд):

<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
  <log location="C:\Logs\1C\LongQueries" history="24">
    <event>
      <eq property="Name" value="DBMSSQL"/>
      <gt property="Duration" value="10000000"/>
    </event>
    <event>
      <eq property="Name" value="CALL"/>
      <gt property="Duration" value="10000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Проанализировав логи ТЖ, мы получим точный список методов 1С и соответствующих им тяжелых SQL-запросов. Это даст неопровержимые доказательства для разработчиков расширений о необходимости оптимизации их кода.

Подведем итог: диагностика производительности в 1С:КА 2.5 при наличии тяжелых расширений должна быть комплексной. Начнем с настройки SQL (MAXDOP, Shared Memory), продолжим анализом клиентских обработчиков ожидания и закончим детальным замером производительности фоновых заданий через конфигуратор или ТЖ. Только так можно превратить «тормозящую» систему в эффективный инструмент бизнеса.