Как устранить блокировки в регистре «ЗамерыВремени» при использовании подсистемы «Оценка производительности» на высоконагруженных системах?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Анализируем причины возникновения блокировок

Проанализируем архитектуру подсистемы. Основная нагрузка ложится на регистр сведений ЗамерыВремени. В теории БСП должна записывать данные пакетами, но на практике серверные замеры (вызовы из общего модуля ОценкаПроизводительности) часто фиксируются немедленно после завершения операции. Когда более тысячи пользователей одновременно открывают формы, проводят документы или формируют отчеты, возникают сотни одновременных транзакций записи в одну и ту же таблицу.

Ситуация осложняется двумя факторами:

  1. Эскалация блокировок: SQL-сервер при накоплении большого количества блокировок строк может принять решение заблокировать всю таблицу целиком, что парализует работу всех пользователей.
  2. Регламентная очистка: Стандартные механизмы удаления старых замеров часто пытаются удалить десятки тысяч записей одной транзакцией, что вызывает длительные блокировки (от 2 до 5 минут).

Оптимизируем механизм очистки регистра

Выясним причину блокировок при очистке. Штатное регламентное задание часто использует установку отбора по измерению ДатаЗаписиНачалоЧаса и записывает пустой набор записей. Это «тяжелая» операция. Разберем, как переписать этот процесс, чтобы удаление происходило порциями. Мы можем создать собственный алгоритм, который будет выбирать записи небольшими пакетами и удалять их в цикле.

Рассмотрим пример кода для оптимизированной очистки замеров:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ ПЕРВЫЕ 5000
    |   ЗамерыВремени.ДатаЗаписиНачалоЧаса КАК ДатаЗаписиНачалоЧаса,
    |   ЗамерыВремени.КлючеваяОперация КАК КлючеваяОперация,
    |   ЗамерыВремени.НомерСеанса КАК НомерСеанса,
    |   ЗамерыВремени.ДатаНачалаЗамера КАК ДатаНачалаЗамера
    |ИЗ
    |   РегистрСведений.ЗамерыВремени КАК ЗамерыВремени
    |ГДЕ
    |   ЗамерыВремени.ДатаЗаписиНачалоЧаса < &ГраницаУдаления";

Запрос.УстановитьПараметр("ГраницаУдаления", КонецДня(ТекущаяДата() - 86400 * ДнейХранения));

Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
    НаборЗаписей = РегистрыСведений.ЗамерыВремени.СоздатьНаборЗаписей();
    НаборЗаписей.Отбор.ДатаЗаписиНачалоЧаса.Установить(Выборка.ДатаЗаписиНачалоЧаса);
    НаборЗаписей.Отбор.КлючеваяОперация.Установить(Выборка.КлючеваяОперация);
    НаборЗаписей.Отбор.НомерСеанса.Установить(Выборка.НомерСеанса);
    НаборЗаписей.Отбор.ДатаНачалаЗамера.Установить(Выборка.ДатаНачалаЗамера);
    НаборЗаписей.Записать(Истина);
КонецЦикла;

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

Борьба с эскалацией блокировок на уровне СУБД

Если ваша база данных работает под управлением Microsoft SQL Server и версия платформы 1С ниже 8.3.22, рекомендуется рассмотреть возможность отключения эскалации блокировок для таблицы регистра. Это позволит системе блокировать только конкретные строки индекса, не захватывая всю таблицу ЗамерыВремени.

Проанализируем SQL-команду, которую может выполнить системный администратор:

ALTER TABLE _InfoRgXXXX SET (LOCK_ESCALATION = DISABLE);

Здесь _InfoRgXXXX — имя таблицы регистра ЗамерыВремени в базе данных SQL. Это радикально снижает вероятность «глухих» блокировок всей подсистемы оценки производительности.

Использование современных механизмов БСП

Посмотрим на развитие подсистемы в новых версиях БСП (3.1.5 и выше). Разработчики 1С ввели новые регистры, такие как ЗамерыВремениТехнологические. В этих регистрах структура индексов пересмотрена для минимизации эффекта Hot Spot (горячего пятна). В старых версиях новые записи всегда попадали в конец индекса по дате, что создавало конкуренцию за одну и ту же страницу данных. В новых версиях измерения переставлены так, чтобы данные «размазывались» по разным страницам индекса (например, за счет использования НомерСеанса в качестве одного из первых измерений).

Также рекомендуем проверить настройку Минимальная длительность замера. Часто система перегружена записью «микро-замеров» длительностью 0.01 сек, которые не несут аналитической ценности. Установите порог в 0.1 или 0.5 секунды, чтобы отсечь лишний шум и снизить нагрузку на БД на 70-80%.

Альтернативные методы сбора данных

Если количество пользователей превышает 2000-3000, стоит рассмотреть отказ от записи замеров непосредственно в транзакционную базу данных 1С. Разберем два пути:

  1. Центр мониторинга: В настройках БСП можно указать отправку замеров во внешнюю базу «Центра мониторинга» через HTTP-запросы. В этом случае нагрузка по записи полностью уходит из основной базы.
  2. Технологический журнал (ТЖ): Мы можем настроить сбор данных через логи ТЖ. Это наиболее производительный способ, так как запись в текстовые файлы на диске сервера не создает никаких блокировок в SQL. Для анализа таких логов можно использовать внешние инструменты, такие как стек ELK (Elasticsearch, Logstash, Kibana) или Grafana.

Резюме и рекомендации

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

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

← На главную