1С конфликт блокировок

Ищем блокировки

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

0. Описание проблемы:

Итак, задача: наш сырный клиент, 1С:Молокозавод (на основе УПП 1.3), платформа 8.3.8, уровень изоляции транзакций Read committed snapshot . Множество ошибок превышения времени ожидания предоставления блокировки, взаимоблокировок. Особенно во время обменов данными по web-сервисам с некой WMS-системой. Клиент точно не может сказать, в какое время дня возникают проблемы. 1С:ЦУП отсутствует, к тому же, сбор данных ЦУП не желательно запускать более чем на 20 минут, т.к. замедляется работа исследуемой базы и сильно растёт файл данных для анализа, а мы не знаем, когда же нам поймать эти «20 минут». Поэтому мы будем использовать технологический журнал 1С.

1. Настройка технологического журнала

Для тех, кто не знает, на сервере 1С можно настроить логирование многих событий. Создаём специальный конфигурационный xml-файл, помещаем в папку conf сервера и сервер начинает запись логов. Подробнее останавливаться на этом не буду – в моём первом и втором «пятничном» вебинарах я подробно рассказывал о настройке технологического журнала 1С. Итак, включаю технологический журнал (далее – ТЖ) со следующими отборами: отбор по информационной базе, отбор по следующим событиям:

  • EXCP – все исключительные ситуации, возникающие в работе исследуемой базы
  • DBMSSQL — исполнение операторов SQL СУБД Microsoft SQL Server. Также, ставлю отбор на параметр «lkp» = 1, означающий, что процесс ожидал предоставления блокировки.
  • TLOCK -управление транзакционными блокировками в управляемом режиме. Также, ставлю отбор на «WaitConnections» <> «», что означает, что процесс ожидал предоставления управляемой блокировки
  • TTIMEOUT — превышение максимального времени ожидания транзакционной блокировки.
  • TDEADLOCK – обнаружена взаимоблокировка в управляемом режиме.

События TTIMEOUT и TDEADLOCK появились только в версии 8.3.7 платформы.

Итак, запускаем сбор логов, ставим ограничение, скажем, на 48 часов – платформа будет хранить логи за последние 48 часов.

2. Анализ логов технологического журнала

Через день я начал смотреть, что же у нас получилось:

С 8 до 9 утра было зафиксировано множество событий TDEADLOCK, TTIMEOUT, TLOCK, EXCP.

Пару слов о механизме управляемых блокировок:

С версии платформы 8.1 у нас появился режим управления блокировкой данных «управляемый»

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

Теперь давайте разберем события ТЖ подробнее. EXCP:

События EXCP были следующего вида:

EXCP,Usr=АдминистраторWMS,Descr=’Конфликт блокировок при выполнении транзакции: Превышено время ожидания запроса на блокировку. ‘,Context=’ WebСервис.ax_Exchange.Модуль : 1151 : ВыполнитьОтложенноеПроведениеДокумента(стрДок);

Ещё одно исключение для примера:

EXCP,Usr=АдминистраторWMS,Descr=’Конфликт блокировок при выполнении транзакции: Неустранимый конфликт блокировок’,Context=’ WebСервис.ax_Exchange.Модуль : 1151 : ВыполнитьОтложенноеПроведениеДокумента(стрДок);

Я немного упростил лог. По этим строчкам видно, что возникали таймауты и дедлоки под пользователем АдминистраторWMS, в контексте отложенного проведения документов.

В нашей статье разберем взаимоблокировку. Смотрим событие TDEADLOCK:

TDEADLOCK,Usr=АдминистраторWMS,DeadlockConnectionIntersections=’2896 2894 Seq31427.DIMS Exclusive Fld31428=79:a0b0000c6eb6752411db283f6c576d63,2894 2896 AccRg14235.DIMS Exclusive Account=4:80669393ef352fcb42964c7f786c877d Correspond=0 ExtDimension1=71:818b005056c0000811e2a819ec1a1fc2 ExtDimension2=114:a23600259037056711e2395da86502e1 Fld14236=79:a0b0000c6eb6752411db283f6c576d63 Fld14237=Null Period= Splitter=0′,Context=’ WebСервис.ax_Exchange.Модуль : 1151 : ВыполнитьОтложенноеПроведениеДокумента(стрДок); WebСервис.ax_Exchange.Модуль : 3068 : Объект.Записать(РежимЗаписиДокумента.Проведение);’

Давайте разбирать этот жуткий текст. Взаимоблокировка, тот же пользователь АдминистраторWMS, далее идет информация о 2х блокировках, на которых и возник конфликт.

  1. 2896 2894 Seq31427.DIMS Exclusive Fld31428=79:a0b0000c6eb6752411db283f6c576d63
    • 2896 – соединение, ожидающее блокировку
    • 2894 – соединение, установившее блокировку
    • SeqDIMS заблокированный ресурс. Имя таблицы начинается на Seq, значит это последовательность. Обработкой «Структура БД» по имени таблицы мы можем найти, какая именно последовательность.
    • Exclusive – это тип блокировки «исключительная», такая ставится при записи
    • Fld31428=79:a0b0000c6eb6752411db283f6c576d Сама блокировка на поле Fld31428. Это поле тоже можно «расшифровать в обработке «Структура БД»
  2. 2894 2896 AccRg14235.DIMS Exclusive
    • Те же 2 сеанса, только наоборот. 2896 установил блокировку, 2894 – ожидает
    • AccRgDIMS Exclusive. Эксклюзивная блокировка на таблице AccRg14235. Это РБ Хозрасчетный.

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

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

TLOCK, t:connectID=2896,Usr=АдминистраторWMS,Locks=’Seq31427.DIMS Exclusive Fld31428=79:a0b0000c6eb6752411db283f6c576d63′,WaitConnections=2894,Context=’ WebСервис.ax_Exchange.Модуль : 1151 : ВыполнитьОтложенноеПроведениеДокумента(стрДок); WebСервис.ax_Exchange.Модуль : 3068 : Объект.Записать(РежимЗаписиДокумента.Проведение);’ TLOCK, t:connectID=2894,Usr=АдминистраторWMS,Locks=’AccRg14235.DIMS…’,WaitConnections=2896,Context=’ WebСервис.ax_Exchange.Модуль : 1151 : ВыполнитьОтложенноеПроведениеДокумента(стрДок); WebСервис.ax_Exchange.Модуль : 3068 : Объект.Записать(РежимЗаписиДокумента.Проведение); Документ.ОтчетПроизводстваЗаСмену.МодульОбъекта : 3634 : ОбщегоНазначения.УдалитьДвиженияРегистратора(ЭтотОбъект, Отказ); ОбщийМодуль.ОбщегоНазначения.Модуль : 5495 : УдалитьЗаписанныеДвиженияДокумента(ДокументОбъект, Отказ, ВыборочноОчищатьРегистры, РежимПроведенияДокумента); ОбщийМодуль.ОбщегоНазначения.Модуль : 5610 : ПолныеПрава.ЗаписатьНаборЗаписейНаСервере(ИмяРегистра, ДокументОбъект.Ссылка,, ТипРегистра); ОбщийМодуль.ПолныеПрава.Модуль : 1283 : Набор.Записать();’

Это 2 события TLOCK, на которых были ожидания блокировок. Мы видим наши номера сеансов connectID, а также WaitConnections – номера сеансов, которых ожидали. И контексты. В одном случае идет запись данных при проведении, а в другом – удаление записанных движений в начале проведения.

Проблему обнаружили. Теперь подумаем, что можно сделать для её решения и почему вообще она возникла.

Во-первых, и сеансы-виновники и сеансы-жертвы – это обмен с системой WMS. Таким образом получается, что обмен с WMS может проходить одновременно в несколько сеансов. Если по бизнес-логике в этом нет необходимости, можно исключить возможность параллельных обменов.

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

Как видим, режим разделения итогов выключен. Необходимо включить.

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

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

Остальные проблемы, а также настройку и работу с ТЖ смотрите на наших вебинарах.

Спасибо за внимание 🙂

Помогла ли вам данная статья?

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

Конфликт блокировок в 1С 8.3 и его значение

Для большинства пользователей сообщение о конфликте блокировок 1С означает лишь ошибку, мешающую им выполнять свою работу. Они хотят поскорее избавиться от этой проблемы и осаждают IT-отдел жалобами на то, что «1С не работает».

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

Причины возникновения ошибок блокировки в 1С

Показательные нагрузочные тестирования демонстрируют, что сервер 1С выдерживает параллельную работу более чем пяти тысяч пользователей. Но идеальные условия подобных экспериментов недостижимы в повседневных условиях крупных и средних компаний. Чтобы добиться аналогичного быстродействия и безошибочности, конфигурация должна быть идеально разработана и заточена под конкретные бизнес-процессы предприятия.

Если не брать идеальные варианты, то конфликты блокировок 1С встречаются по следующим причинам:

Одновременная работа пользователей с большим объемом данных. Эта первопричина продиктована внутренними механизмами 1С. Они предполагают запрет изменения данных, вовлеченных в транзакцию, запущенную от имени другого пользователя;

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

  • Неоптимальные запросы;
  • Запрос остатков в начале действий;
  • Непонимание предназначения объектов конфигурации и их неправильное применение;
  • Избыточность заложенных в системе или дополнительно разработанных блокировок.

Как исправить конфликт блокировок в 1С 8.3

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

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

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

Быстрое решение конфликта блокировок 1С

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

Для быстрого решения проблемы существуют два пути:

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

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