В этой статье мы поговорим о том, что такое таймаут на управляемых блокировках 1С:Предприятия и как расследовать причины его возникновения.

При управляемом режиме , помимо управляемых блокировок 1С:Предприятия, на стороне СУБД в этот самый момент могут действовать также свои блокировки СУБД, обеспечивая изоляцию на более низком уровне. Блокировки СУБД при этом, в общем случае, осуществляются на «запись» таблицы. В отдельных ситуациях, однако, СУБД может посчитать необходимым заблокировать и таблицу целиком.

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

1. Что видит пользователь? Конфликт блокировки при выполнении транзакции.
2. Что на самом деле происходит?
3. Где указывается время ожидания освобождения управляемой блокировки 1С:Предприятия?
4. Что будет в технологическом журнале? Парсим технологический журнал в поисках таймаута.

Что видит пользователь при возникновении конфликта блокировок?

Пользователь видит ошибки:

Конфликт блокировки при выполнении транзакции Превышено максимальное время ожидания предоставления блокировки

Сообщение 1С:Предприятие о конфликте управляемых блокировок при выполнении транзакции

Данное сообщение – сообщение о таймауте на управляемых блокировках 1С:Предприятия.

Что на самом деле происходит при блокировке 1С?

Если упрощённо:

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

У него было некоторое время , чтобы дождаться освобождения этих ресурсов.

Не дождавшись освобождения – действие пользователя прерывается и он видит вышеописанную ошибку.

Надо отметить, что таймаутом называется именно событие, когда блокировка уже не дождалась ресурсов и была прервана по времени, указанному в настройках 1С:Предприятия.

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

Блокировка – это информация о том, что данные ресурсы «заняты» и не могут быть использованы другой транзакцией.

ВАЖНО: ВНЕ ТРАНЗАКЦИИ БЛОКИРОВКИ НЕТ!!!

Где указывается время ожидания освобождения управляемой блокировки 1С:Предприятия?

Интервал этого времени ожидания освобождения управляемой блокировки указывается в конфигураторе информационной базы и по умолчанию составляет 20 секунд.

Настройка параметров информационной базы 1С

Настройка параметров информационной базы 1С

Настройка интервала времени ожидания освобождения управляемой блокировки 1С

Настройка интервала времени ожидания освобождения управляемой блокировки 1С

Как настроить технологический журнал для сбора событий и ошибок по управляемым блокировкам?

Файл настройки технологического журнала обычно общий и для расследования как таймаутов, так и взаимоблокировок:

С помощью этого журнала будут собираться следующие события технологического журнала, относящиеся исключительно к УПРАВЛЯЕМЫМ блокировкам 1С:Предприятия.

TTIMEOUT – превышение времени ожидания блокировки.

TLOCK – управление(установка/снятие) блокировками.

TDEADLOCK – обнаружена взаимоблокировка.

Важно отметить, что, если события TTIMEOUT и TDEADLOCK являются показателем некорректной работы системы и в нормальной ситуации появляться в журнале не должны. То TLOCK — это обычная работа системы и таких событий в журнале будет очень много.

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

В качестве мониторинга можем рекомендовать настроить следующий журнал:

Таким образом мы собираем все взаимоблокировки, таймауты и собираем только длительные блокировки, длительность более 15 секунд.

При анализе такого журнала мы не сможем увидеть виновника ожидания или взаимоблокировки. Его блокировка установилась, скорее всего, быстро и в записи журнала не попадет по фильтру >15сек. Но сможем проанализировать на каких пространствах возникла проблема.

Вместо фильтра по длительности можно использовать фильтр по заполненности свойства, указывающего на ConnectionID блокировки, которое заставила ожидать текущую блокировку(WaitConnections).

Что будет в технологическом журнале? Парсим технологический журнал в поисках таймаута.

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

Приведём пример реального анализа из технологического журнала.

1. Ищем таймауты (TTIMEOUT).

Регулярное выражение поиска таймаута.

2. Ищем TLOCK от найденного в п.1 таймаута — жертва. Это TLOCK, который платформа наложить не смогла. Другими словами это регистрация в технологическом журнале неуспешной попытки.

Регулярное выражение поиска TLOCK по ID соединения(фиолетовый маркер) и ID ожидания(красный маркер).

Где будет данное событие? Правильно! Сразу после относящегося к нему события TTIMEOUT.

Отсюда мы узнаем за какой ресурс конфликтуют блокировки (зеленый маркер).

Стоит отметить, что с блокировкой уровня Exclusive не будет совместима ни блокировка Exclusive, ни блокировка уровня Shared.

По длительности самого события также видно, что блокировка ожидала освобождения ресурсов 20 002010 мкс, то есть более 20 секунд.

3. Ищем предыдущий по времени TLOCK, конфликтующий по тем же условиям (Regions, Locks) и ID соединения, которого будет соответствовать ID ожидания(красный маркер) нашего таймаута — виновник.

Данное событие будет, как вы понимаете:

  • ДО расследуемого TTIMEOUT
  • НО максимально ближнее к расследуемому TTIMEOUT.

Также обращаем внимание на поля :Fld… Чтобы понять на каких полях произошло пересечение блокировки. В нашем случае — это полное совпадение полей блокировки.

Но возможны ситуации, когда в пространствах блокировки — можно увидеть меньше полей (1, 2 и тд) что свидетельствует о избыточной блокировки виновника, которая блокирует также все остальные  поля записи.

Таким образом мы нашли источник, жертву и ресурс из-за которого возник таймаут.

4. С помощью метода ПолучитьСтруктуруХраненияБазыДанных() или обработок, использующих данный метод – определяем как называется на языке метаданных 1С объект, который стал причиной таймаута.

5. По контексту ищем в коде причину таймаута и устраняем.