Многие разработчики сталкиваются с парадоксальной ситуацией: при переводе конфигурации на управляемые блокировки скорость проведения некоторых документов катастрофически падает. В автоматическом режиме документ проводился 5 минут, а в управляемом — 30 минут. При этом в базе вы находитесь одни, никакого нового кода в объект не добавлялось, а стандартный инструмент конфигуратора показывает, что код выполняется за считанные секунды. Давайте подробно разберем эту ситуацию, проанализируем причины такого поведения системы и найдем эффективные способы решения проблемы.
Выясним причину "слепоты" встроенного профилировщика 1С. Инструмент ЗамерПроизводительности фиксирует исключительно время выполнения строк кода 1С внутри процедур и функций. Однако огромная часть работы платформы происходит скрыто от программиста.
ОбработкаПроведения завершила свою работу. Замер производительности этот длительный этап коммита данных в СУБД просто не охватывает.Если в этот момент система "зависает" на полчаса, в замере производительности мы увидим лишь быструю отработку кода модуля объекта (например, 10-15 секунд на формирование таблицы движений), а реальное время ожидания останется за кадром. Как верно подмечено, единственное, что иногда можно заметить в замерах при таких тормозах — это длительная передача контекста или задержки на методе Записать().
Рассмотрим подробнее три главные технические причины, по которым управляемые блокировки могут замедлить работу системы в разы даже для одного монопольного пользователя.
1. Перегрузка менеджера управляемых блокировок (отсутствие автоматической эскалации)
Проанализируем ситуацию с блокировками. В автоматическом режиме ими управляет СУБД (например, MS SQL Server). СУБД обладает интеллектуальными механизмами: если документ делает тысячи движений, система понимает, что блокировать каждую строку по отдельности невыгодно (не хватит памяти), и выполняет эскалацию блокировки. Она заменяет тысячи мелких блокировок одной блокировкой всей таблицы целиком. Это происходит мгновенно.
В управляемом режиме за параллельность отвечает сервер 1С. Если ваш документ генерирует огромный массив движений (десятки тысяч строк), менеджер блокировок 1С начинает честно создавать в оперативной памяти сервера микро-блокировки под каждую конкретную запись (по каждому измерению регистра). На генерацию и хранение этого огромного пространства блокировок сервер 1С тратит колоссальное количество процессорного времени. Именно здесь могут теряться те самые 25 минут.
2. Смена уровня изоляции транзакций и деградация планов запросов СУБД
Посмотрим на поведение базы данных. При переводе конфигурации на управляемые блокировки платформа дает команду СУБД снизить уровень изоляции транзакций. Происходит переход с жесткого Serializable на более мягкий Read Committed (или Read Committed Snapshot).
Из-за изменения уровня изоляции оптимизатор запросов СУБД начинает строить совершенно иные планы выполнения. Те запросы к виртуальным таблицам остатков и оборотов, которые раньше выполнялись молниеносно через индекс, могут внезапно начать выполняться через полное сканирование огромных таблиц (Table Scan). Это многократно увеличивает время выполнения запросов при проведении.
3. Неявные управляемые блокировки платформы при записи
Важно помнить: даже если вы не написали в коде ни одного использования объекта БлокировкаДанных, платформа при записи движений регистра неявно устанавливает управляемую блокировку по всем измерениям набора записей. Для очень объемных и неоптимизированных таблиц сбор данных для этих блокировок занимает существенное время.
Поскольку обычный замер не работает, нам необходимо использовать Технологический журнал (ТЖ) платформы или специализированные сервисы анализа (например, сервисы Гилева).
Настройте сбор Технологического журнала на следующие события:
TLOCK — покажет время работы менеджера управляемых блокировок 1С. Если проблема в генерации тысяч блокировок сервером 1С, вы увидите огромные задержки именно здесь.DBMSSQL (или `DBPOSTGRS`) — покажет реальное время выполнения запросов к СУБД. Это поможет выявить деградировавшие запросы.SDBL — поможет отследить время фиксации транзакций и записи наборов движений.Определив узкое место с помощью ТЖ, применим соответствующие методы оптимизации.
Шаг 1. Применение "поглощения" (ручной эскалации блокировок)
Если анализ показал, что проблема заключается в событии TLOCK (формирование огромного количества блокировок сервером 1С), нам нужно сделать то, что СУБД делала автоматически — укрупнить блокировку. Для этого перед записью движений необходимо вручную наложить блокировку на весь регистр целиком.
Посмотрим на пример реализации ручной эскалации:
Процедура ОбработкаПроведения(Отказ, РежимПроведения)
// Ручная эскалация: блокируем весь регистр целиком
// Это избавит сервер 1С от необходимости создавать тысячи микро-блокировок
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ОстаткиТоваров");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
// Намеренно НЕ указываем конкретные измерения (УстановитьЗначение)
Блокировка.Заблокировать();
// Далее идет стандартный алгоритм проведения...
КонецПроцедуры
Этот простой код установит одну широкую блокировку на таблицу. Все последующие мелкие неявные блокировки платформы по данному регистру будут "поглощены" этой широкой блокировкой. Сервер перестанет тратить время на их обработку, и скорость проведения вернется к исходным 5 минутам.
Шаг 2. Обновление статистики и очистка кэша планов запросов
Если проблема (согласно ТЖ) кроется в долгих событиях DBMSSQL, выполните обслуживание СУБД. Обновите статистику базы данных и обязательно очистите процедурный кэш (кэш планов запросов). Сброс старых планов заставит SQL-сервер построить новые, оптимальные маршруты выборки данных уже с учетом нового уровня изоляции транзакций.
Шаг 3. Анализ индексов и структуры запросов
Проверьте запросы, которые собирают данные для проведения. Убедитесь, что все поля, по которым идет фильтрация или соединение с виртуальными таблицами, проиндексированы. В управляемом режиме к качеству запросов предъявляются более жесткие требования. Запрос к оборотной таблице остаточного регистра без проиндексированного измерения может стать причиной фатальных тормозов.
Применяя эти подходы, мы с вами сможем успешно диагностировать скрытые потери производительности и завершить перевод конфигурации на управляемые блокировки, сохранив и даже приумножив скорость работы системы.