С ростом бизнеса растет и нагрузка на систему 1С – всё больше пользователей, процессов и интеграций. И если на старте всё работает идеально, то в какой-то момент база начинает буквально «виснуть»: простые операции тянут секунды, документы зависают на «Записать и закрыть», пользователи жалуются на таймауты.
Одна из причин – ожидания на блокировках.
Что на самом деле происходит внутри 1С
Каждый объект системы – будь то документ, справочник или регистр при чтении и изменении должен быть защищен от одновременного доступа. Для этого существует механизм блокировок:
- Объектные блокировки – работают на уровне платформы 1С и не затрагивают СУБД;
- Транзакционные блокировки – действуют уже на уровне базы данных и могут быть автоматическими (СУБД управляет ими сама) или управляемыми (контролируются приложением 1С).
В нашем случае, мы затронем тему транзакционных блокировок, ведь именно внутри транзакций используются блокировки, которые вызывают ожидания.
Как рождается ожидание на блокировке
Представьте: один пользователь записывает документ, другой – пытается изменить тот же элемент. Первый процесс блокирует ресурс, второй ждёт. Если ожидание затянулось (по умолчанию – 20 секунд), 1С выдает ошибку таймаута.
Для того, чтобы ожидание блокировки проявилось – должны соблюдаться все три условия:
- Разные сеансы;
- Один и тот же ресурс;
- Несовместимые типы блокировок.
Проблема не в самой блокировке, а в её избыточности.
Когда блокировок слишком много
Избыточные блокировки бывают разными:
- По данным – захватывают больше, чем нужно, но быстро;
- По времени – блокируют нужное, но слишком долго;
- По данным и времени – худший сценарий: блокируется всё и надолго.
В итоге мы имеем эффект снежного кома: когда один зависший процесс тянет за собой другие – и производительность падает.
Как избежать долгие ожидания
Есть два простых, но при этом критически важных правила:
- Делайте транзакции максимально короткими. Чем меньше операций между началом и фиксацией, тем меньше будет ожидание блокировки.
- Запись – только в конце транзакции. Все вычисления, проверки и подготовительные действия выполняйте заранее.
Однако даже при соблюдении этих правил блокировки не исчезают полностью. Сложность в том, что их природу трудно увидеть. В технологическом журнале 1С фиксируется всё, но без специализированных инструментов разобраться в нём вручную почти невозможно.
И именно здесь большинство команд упирается в стену: одни борются с симптомами (перезапускают сервер, увеличивают таймауты), а другие начинают искать системное решение, которое точно покажет – где, когда и почему система встала на ожидание.
Примеры записей длительных ожиданий на блокировках в технологическом журнале
Для анализа ожиданий на блокировках просто не обойтись без логов технологического журнала. Сведения о попытках установки блокировки содержатся в событии TLOCK. Рассмотрим две записи:
25:35.440002-19999953,TLOCK,4,level=INFO,process=rphost,p:processName=DataBase,OSThread=15168, t:clientID=9311,t:applicationName=1CV8C,t:computerName=pcName,t:connectID=139018, SessionID=117809,Usr=Кладовщик документы,AppID=1CV8C,DBMS=DBMSSQL,DataBase=localhost\DataBase, Regions=Document91053X1.REFLOCK,Locks='Document91053X1.REFLOCK Exclusive ID=91053:85ac00155d10172711f09dcb4b9b83ae', WaitConnections=139019,connectionID=c2b2dc41-8e30-40d6-8c05-628dbf056fd0,Context='Форма.Вызов : Обработка.ТестовыеБлокировки.Форма.ТЦФорма.Модуль.ПровестиДокумент ЭмуляцияОшибок Обработка.ТестовыеБлокировки.Форма.ТЦФорма.Форма : 40 : ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);'
25:15.440032-6,TLOCK,4,level=INFO,process=rphost,p:processName=DataBase,OSThread=12112, t:clientID=9312,t:applicationName=1CV8C,t:computerName=pcName,t:connectID=139019, SessionID=117810,Usr=Кладовщик сервис,AppID=1CV8C,DBMS=DBMSSQL,DataBase=localhost\DataBase, Regions=Document91053X1.REFLOCK,Locks='Document91053X1.REFLOCK Exclusive ID=91053:85ac00155d10172711f09dcb4b9b83ae',WaitConnections=,Context='Форма.Вызов : Обработка.ТестовыеБлокировки.Форма.ТЦФорма.Модуль.ПровестиДокумент ЭмуляцияОшибок Обработка.ТестовыеБлокировки.Форма.ТЦФорма.Форма : 40 : ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);'
Первая запись:
- 19999953 – Длительность ожидания при попытке установить блокировку;
- WaitConnections=139019 – ConnectId, который должен снять блокировку;
- Document91053X1 – Объект блокировки.
Вторая запись:
- t:connectID=139019 – ConnectId, который установил блокировку;
- Document91053X1 – Объект блокировки.
Контекст в обеих записях в текущем примере одинаковый, но на практике установка блокировок может осуществляться из разных мест.
Таким образом, необходимо изучать причины долгого проведения документа из формы обработки и выяснять, по какой причине документ проводился более 20 секунд.
Технологический журнал – мощный внутренний инструмент в рамках систем 1С, но для работы с ним требуются определенные навыки и опыт, которые не всегда бывают доступны. В этом случае может прийти на помощь наш сервис Metrika42 с функционалом анализа блокировок:
Рисунок 1 – Metrika42: функционал анализа блокировок 1С
С помощью нашего инструмента, можно проанализировать ожидания на блокировках конкретной базы 1С.
Функционал анализа ожиданий на блокировках при выборе базы 1С отображается в виде двух таблиц:
- Таблица виновников (слева). В этой таблице отображаются виновники, которые группируются по контексту. Контекст может быть развернут для детализации, которая содержит время возникновения, пользователя (виновника), количество жертв, общее время блокировки, контекст виновника.
- Таблица жертв (справа). Заполняется при выборе Виновника в левом секторе. Эта таблица содержит всех жертв выбранного виновника из левой таблицы со следующими данными: дата блокировки, время ожидания, объект метаданных, заблокированный пользователь (жертва), контекст жертвы.
