Блокировки и взаимоблокировки в 1С: как находить виновника, а не перезапускать сервер

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

Блокировка — не баг и не проблема производительности. Это механизм, без которого учёт был бы неверным.

Простой пример. На складе три единицы товара. Два менеджера одновременно проводят реализацию по три штуки каждый. Без блокировок оба прочитают остаток «3», оба решат, что товара хватает, оба проведут документ. На складе окажется минус три.

Блокировка не даёт второму читать остаток, пока первый его меняет. Второй ждёт долю секунды, потом видит остаток «0» и получает честный отказ.

Поэтому цель работы с блокировками — не убрать их, а сократить время удержания и область захвата. Система без блокировок быстрая и неправильная.

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

Запомнить стоит одно.

Блокировка, длящаяся сорок миллисекунд, — это правильно работающая система, и трогать её не нужно; блокировка, длящаяся четыре минуты, — это уже не механизм целостности, а конкретная прикладная ошибка, у которой есть автор, время появления и, как правило, вполне понятная причина вроде обращения к внешнему сервису изнутри открытой транзакции или обработки, которая в цикле по тысяче строк документа лезет в базу за каждой строкой отдельно.

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

В 1С есть два режима управления блокировками, и разница между ними принципиальная.

Автоматический режим — старый. Платформа перекладывает управление на СУБД и повышает уровень изоляции транзакции. SQL Server начинает блокировать не отдельные записи, а диапазоны и целые страницы. Проведение одного документа может заблокировать сотни чужих строк.

Управляемый режим — платформа сама ведёт таблицу блокировок в менеджере кластера и блокирует ровно те значения, которые нужны прикладной логике. На стороне СУБД при этом используется уровень изоляции READ COMMITTED, и лишних захватов не происходит.

Все современные типовые конфигурации работают в управляемом режиме. Но у клиентов с историей регулярно встречаются базы, где режим остался автоматическим — либо конфигурация старая, либо когда-то переключили «чтобы починить» и забыли.

Проверяется свойством конфигурации «Режим управления блокировкой данных». Значение должно быть «Управляемый», а не «Автоматический» и не «Автоматический и управляемый».

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

Эффект от перехода бывает драматическим. У клиента-производственника после перевода базы УПП в управляемый режим количество таймаутов упало с 30–40 в день до одного-двух в неделю. Ничего больше не меняли.

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

Таймаут по умолчанию — 20 секунд. Это значит, что пользователь, чей документ не проводится, честно прождал двадцать секунд, прежде чем получить сообщение. Двадцать секунд ожидания в интерфейсе воспринимаются как «зависло намертво».

Соблазн увеличить таймаут велик и почти всегда вреден. Он не убирает причину, а растягивает страдание: вместо ошибки через 20 секунд пользователь получит ошибку через 60. Единственный случай, когда увеличение оправдано, — заведомо длинные регламентные операции в нерабочее время.

Уменьшать, кстати, иногда полезно. Если операция в принципе не может занимать больше пяти секунд, таймаут в 20 просто задерживает обнаружение проблемы.

Ключевая мысль: жалуется всегда тот, кто в конце цепочки, а виноват тот, кто в начале.

Типичная картина. Бухгалтер не может провести документ. Он ждёт менеджера, который проводит реализацию. Тот, в свою очередь, ждёт фоновое задание, которое пересчитывает себестоимость и держит блокировку уже четыре минуты. Виновник — задание, а заявку пишет бухгалтер.

Найти начало цепочки на стороне SQL Server можно одним запросом:

SELECT r.session_id, r.blocking_session_id, r.wait_type,
       r.wait_time / 1000 AS wait_s, r.command,
       SUBSTRING(t.text, 1, 200) AS sql_text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.blocking_session_id <> 0
   OR r.session_id IN (SELECT blocking_session_id
                       FROM sys.dm_exec_requests WHERE blocking_session_id <> 0);

Сессия, у которой blocking_session_id равен нулю, но которая при этом фигурирует как блокирующая для других, — корень цепочки.

Дальше связываем сессию SQL с сеансом 1С. В консоли администрирования кластера у каждого сеанса есть свойство с идентификатором соединения СУБД. Сопоставив, получаем имя пользователя и приложение.

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

Администратор не пишет код, но должен уметь распознать симптом и правильно поставить задачу программисту.

Длинная транзакция. Обработка открывает транзакцию, внутри неё обращается к веб-сервису или пишет файл, и всё это время держит блокировки. Симптом: таймауты возникают строго во время работы конкретной обработки.

Блокировка без отбора. Код блокирует регистр целиком вместо конкретных значений измерений. Симптом: проведение одного документа мешает всем остальным, независимо от номенклатуры и склада.

Запрос в цикле. Обработка в цикле по строкам документа обращается к базе. На документе в 500 строк это 500 обращений внутри одной транзакции. Симптом: время проведения линейно растёт с числом строк.

Разный порядок захвата. Классическая причина взаимоблокировок, о которой говорили выше.

Отсутствие индекса под условие блокировки. Платформа блокирует по значению измерения, а индекса под него нет — СУБД вынуждена сканировать и блокировать больше, чем требуется.

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

Не всё требует правки кода. Список того, что реально в зоне влияния администратора.

• Перенести регламентные задания из рабочего времени. Самая эффективная мера. Пересчёт себестоимости, закрытие месяца, обмены — всё это в ночь.
• Разнести по времени конкурирующие процессы. Если обмен с розницей и загрузка банка стартуют в один час — развести на полчаса.
• Проверить режим управления блокировкой и инициировать перевод в управляемый, если он автоматический.
• Обновить статистику и перестроить индексы. Плохая статистика ведёт к плохим планам, плохие планы — к сканированию вместо поиска, сканирование — к избыточным блокировкам.
• Проверить MAXDOP. Параллельные планы на учётной нагрузке часто увеличивают время удержания блокировок.
• Отделить отчётность. Если тяжёлые отчёты строят по боевой базе в рабочее время, имеет смысл поднять реплику только для чтения.

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

Клиент — оптовая компания с розничной сетью, 38 рабочих мест, УТ на MS SQL.

Жалоба поступила от отдела продаж: каждый будний день примерно с 11:20 до 11:35 документы перестают проводиться, платформа пишет про превышение времени ожидания блокировки. К обеду всё само проходит.

Регулярность указывала на расписание, поэтому мы сразу пошли смотреть регламентные задания. Ничего подозрительного в это время не запускалось.

Включили технологический журнал на TTIMEOUT и TLOCK с порогом от 3 секунд. На следующий день картина была на руках.

Корень цепочки — сеанс с приложением BackgroundJob, который держал блокировку регистра «Товары на складах» больше десяти минут. Задание называлось нейтрально и в расписании стояло на 03:00.

Разгадка нашлась в журнале регистрации: задание в три часа ночи падало с ошибкой соединения, и механизм повторных запусков перезапускал его. С учётом интервала повторов очередная попытка приходилась как раз на 11:20. Каждый день.

Само падение в 03:00 объяснялось ещё проще: в это время шло обслуживание индексов, база была занята, задание отваливалось по таймауту.

Починили двумя действиями. Развели окна: обслуживание индексов в 02:00, задание в 04:30. И ограничили число повторных попыток, чтобы упавшее ночью задание не всплывало в разгар рабочего дня.

Таймауты прекратились в тот же день. Общее время работы — примерно три часа, из которых два ушли на ожидание следующего утра. Показательно здесь то, что ни одна из двух причин не была видна из жалобы: пользователи описывали симптом в 11:20, а корень лежал в 03:00 и в настройке повторов, о которой никто не помнил.

Ещё одно наблюдение из этого разбора, которое стоит вынести отдельно.

Механизм повторных запусков упавших регламентных заданий — вещь полезная и включённая по умолчанию, но она превращает разовый ночной сбой в дневную аварию, и связь между причиной и следствием оказывается разнесена на восемь часов, из-за чего её практически невозможно увидеть, глядя только на время жалобы.

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

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

Стоит ли увеличивать таймаут блокировки, если пользователи жалуются?

Почти никогда. Увеличение не убирает причину, а растягивает ожидание: вместо ошибки через 20 секунд человек получит её через 60. Оправдано только для заведомо длинных регламентных операций в нерабочее время.

Чем управляемые блокировки лучше автоматических?

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

Как понять, кто именно виноват в блокировке?

Нужно найти корень цепочки ожидания: сеанс, который блокирует других, но сам никого не ждёт. Он виден и в консоли кластера 1С, и запросом к sys.dm_exec_requests на стороне SQL Server. Жалуется обычно тот, кто в конце цепочки, а не виновник.

Что администратор может сделать без программиста?

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