Блокировки 1С: что это и почему это неизбежно

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

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

Где именно возникают блокировки: три уровня

• Прикладной уровень 1С
  Платформа защищает конкурентную запись объектов и обеспечивает согласованность прикладной логики (запись документов, справочников, движения по регистрам). Даже если СУБД «готова», платформа может не разрешить запись в силу контроля актуальности и правил бизнес-логики.
• Уровень СУБД (MS SQL / PostgreSQL)
  Это «настоящие» транзакционные блокировки, ожидания на ресурсах, дедлоки. Именно здесь чаще всего видно: кто кого блокирует, сколько ждут, на каких таблицах/индексах/строках.
• Инфраструктура (CPU/RAM/диск/сеть)
  Формально это не блокировки, но влияние прямое: чем медленнее выполняются запросы и запись на диск, тем дольше живут транзакции, а значит, тем дольше удерживаются блокировки и тем сильнее «очереди ожидания».

Виды блокировок, с которыми чаще всего сталкиваются

Объектные конфликты (логика платформы)

Типично: два процесса пытаются записать один и тот же документ/элемент справочника или косвенно воздействуют на одну и ту же «горячую точку» (например, одну кассу/склад/контрагента).

Симптомы: долгое выполнение пользовательских операций, большой разброс по длительности однотипных операций (например запись документов с одинаковым составом данных в разное выполняется с разной длительностью), ошибки с текстом «Конфликт блокировок при выполнении транзакции» или «Неудачная попытка эскалации управляемой блокировки».

Транзакционные блокировки СУБД

Проявляются как ожидания: один сеанс держит блокировку (пишет), другие ждут (хотят читать/писать пересекающиеся данные).

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

Взаимоблокировки (deadlocks)

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

Симптомы: ошибки взаимоблокировки, «иногда падает проведение/обмен», сложно воспроизводится.

Рисунок 1 – Схема работы веб-приложения

Почему блокировки превращаются в проблему: основные причины

1) Длинные транзакции (топ-1 причина)

Транзакция держит блокировки до COMMIT/ROLLBACK. Длинной её делают:

• длительные запросы и отсутствие подходящих индексов;
• циклы записи «по одной строке»;
• интерактив/внешние вызовы внутри транзакции (диалоги, HTTP, файлы);
• ожидания из-за I/O или перегрузкиперегруза сервера.

Практическое правило: всё, что можно посчитать/подготовить до транзакции — делайте до. Внутри транзакции оставляйте только минимально необходимую запись.

2) Слишком широкая область блокировки

Когда операция «захватывает» больше данных, чем нужно: большой диапазон ключей, слишком общий фильтр, работа с «горячими» регистрами без локализации по измерениям (склад/организация/период/касса).

3) Разный порядок захвата ресурсов

Классический дедлок: одна операция делает A→B, другая B→A. На нагрузке это гарантированно всплывёт.

4) Конкуренция с регламентными заданиями и обменами

Фоновые задания и интеграции часто пишут в те же данные, что и пользователи. Если расписание не разведено, вы получаете «конкурирующую запись» в самый пик.

5) Инфраструктурные узкие места

Перегруженный диск или CPU не «создаёт» блокировки напрямую, но удлиняет операции: транзакции живут дольше → блокировки держатся дольше → все ждут.

Последствия: как это выглядит в эксплуатации

Для бизнеса и пользователей

• формы «подвисают», проведение идёт минутами;
• периодически появляются ошибки блокировок/таймауты;
• регламентные операции не укладываются в окно (закрытия, расчёты, обмены).

Для ИТ (админы/DBA/разработчики)

• рост среднего и 95/99-перцентиля времени отклика;
• цепочки блокировок в СУБД;
• всплески deadlocks;
• «плавающие» инциденты, которые трудно поймать без постоянной наблюдаемости.

Диагностика: что искать в первую очередь

1) Определить тип проблемы

• Это именно ожидания на блокировках или просто медленные запросы/ресурсы?
• Проблема локальная (одна операция) или системная (всё «встало»)?

2) Найти «виновника» и «жертв»

Вам нужна связка:

• кто блокирует (сеанс/процесс/задание),
• кого блокирует (какие операции ждут),
• что именно удерживается (таблицы/ресурсы/объекты),
• сколько времени длится ожидание.

3) Привязать к прикладному сценарию

Почти всегда финальный ответ — «вот эта операция/обработка/задание держит транзакцию слишком долго» или «вот этот участок кода берёт блокировки слишком широко».

Схема 2 – Причины блокировок в транзакциях

Как снижать блокировки: практические меры

Для разработчиков 1С

• Короткие транзакции: подготовка данных до транзакции, запись — быстро и атомарно.
• Сужение области записи: меньше затрагиваемых строк/регистров/периодов.
• Единый порядок работы с ресурсами: особенно там, где несколько сущностей обновляются вместе.
• Пакетирование массовых операций: меньше round-trip к СУБД, меньше записей «по одной».
• Оптимизация запросов: правильные индексы под условия отбора, меньше «широких» сканов.

Для сисадминов/DBA/DevOps

• Контроль I/O: медленный диск = длинные транзакции = лавина ожиданий.
• Разведение тяжёлых регламенток по времени: не пересекать с пиком пользователей.
• Наблюдаемость по СУБД: ожидания, блокирующие цепочки, deadlocks, тяжёлые запросы.
• Регулярная гигиена СУБД: статистика/индексы/вакуум (в зависимости от СУБД).

«Пожарный» алгоритм, когда “всё тормозит прямо сейчас”

• Зафиксировать время инцидента и понять масштаб: одна база/кластер/все пользователи.
• Проверить: есть ли массовые ожидания на блокировках в СУБД.
• Найти блокирующий сеанс и его действие (часто это регламентка/обмен/массовая обработка).
• Быстро снять нагрузку: развести задания, остановить конкурирующую массовую операцию, устранить узкое место по I/O/CPU.
• После стабилизации — разбор первопричины: укоротить транзакцию, сузить область блокировки, выровнять порядок захвата ресурсов, добавить индексы/переписать запрос.

Схема 3 – Процесс устранения блокировок 1С

Metrika42 в контексте блокировок

Главная боль блокировок — не факт их наличия, а быстрая локализация причины: кто блокирует, кого, чем именно и в рамках какой бизнес-операции. Когда мониторинг показывает только «плохо», расследование превращается в ручное копание логов и попытки поймать редкий момент.

Metrika42 – инструмент, который помогает именно с эксплуатационной стороной: увидеть конфликт блокировок как цепочку «виновник–жертва», привязать к операциям/ошибкам/запросам, а дальше уже принять инженерное решение (код/индексы/расписание/ресурсы). Плюс полезна общая картинка по производительности и аномалиям (вроде просадки отклика или перегруза), потому что блокировки почти всегда усиливаются инфраструктурой и «длиной» транзакций.

Скриншот 1 – Функционал анализа блокировок 1С в Metrika42