В нашей практике мы часто сталкиваемся с вопросами производительности и стабильности работы информационных систем на платформе 1С:Предприятие. Одной из наиболее острых проблем, значительно снижающих комфорт и скорость работы пользователей, являются взаимоблокировки. Когда система начинает "тормозить", и пользователи получают сообщения о конфликтах при записи данных, естественным желанием становится поиск быстрого и радикального решения. Один из таких подходов, который иногда рассматривается, — это разбиение единой информационной базы на несколько независимых с помощью механизма распределенных информационных баз (УРБД). Однако, как мы с вами выясним, этот путь не только не решает корневую проблему, но и может создать целый ряд новых, гораздо более сложных задач.
Прежде всего, давайте разберем, что такое Распределенные Информационные Базы (УРБД) и каково их истинное назначение. Механизм УРБД разработан для организации работы территориально распределенных структур, где филиалы или удаленные подразделения не могут постоянно работать с единой базой данных в режиме онлайн. УРБД позволяет синхронизировать изменения данных между центральной и периферийными базами, обеспечивая автономную работу каждого узла. Теперь проанализируем ситуацию, когда УРБД рассматривается как средство борьбы с блокировками. На первый взгляд может показаться, что если разбить одну базу на две, то пользователи будут работать в разных пространствах, и конфликтов станет меньше. Однако это ошибочное предположение. Разделение базы через УРБД не устраняет причину возникновения блокировок, а лишь переносит ее в другую плоскость, а иногда и вовсе усугубляет ситуацию. По сути, если у вас была одна проблема, после внедрения УРБД вы получите две, а то и больше. * Гарантированные конфликты изменений. Мы выясним, что при использовании УРБД вы практически гарантированно столкнетесь с "конфликтами изменений объектов". Если одни и те же объекты (например, элементы справочников, документы) могут изменяться в нескольких узлах, то при обмене данными система будет вынуждена решать, какая версия объекта является актуальной. Для предотвращения таких ситуаций необходимо заранее устанавливать очень строгие правила внесения изменений по узлам, что часто бывает сложно реализовать на практике. * Распределенные взаимоблокировки. В особенно сложных случаях могут возникать так называемые "распределенные взаимоблокировки". Это ситуации, когда части "круга ожидания" блокировок находятся в разных пространствах — например, одна часть на уровне SQL Server, а другая на уровне управляемых блокировок 1С. В таких сценариях ни СУБД, ни менеджер блокировок 1С не могут корректно обнаружить и разрешить конфликт, что приводит к зависаниям и непредсказуемому поведению системы. * Производительность обменов. Кроме того, не стоит забывать о производительности обменов данными. Регулярные обмены между базами создают значительную нагрузку на серверы и каналы связи. Это может замедлять работу системы в целом, а не ускорять ее, что прямо противоположно нашим целям по борьбе с "тормозами". * Альтернативы для распределенных сценариев (не для блокировок). Если же у вас действительно распределенная структура, и УРБД используется по своему прямому назначению, то для управления запасами и предотвращения проблем с одновременной продажей одного и того же товара в разных узлах, мы рекомендуем применять прикладные механизмы резервирования или цепочки документов (например, "Приказ на выдачу" -> "Выдача товара"), вместо использования единого документа вроде "Расходной накладной" во всех узлах одновременно.
Прежде чем перейти к решениям, давайте разберем, что же такое взаимоблокировка (deadlock). Взаимоблокировка — это неразрешимый конфликт блокировок, который возникает, когда две или более транзакций ожидают снятия блокировок, установленных друг другом. Представьте, что Транзакция А ждет ресурс, заблокированный Транзакцией Б, а Транзакция Б ждет ресурс, заблокированный Транзакцией А. Обе транзакции будут ждать бесконечно. Механизм управления блокировками СУБД (или 1С) обнаруживает такие ситуации и прерывает одну из транзакций (так называемую "жертву"), чтобы разрешить конфликт, что обычно приводит к ошибке у пользователя.
Мы проанализируем основные причины возникновения взаимоблокировок:
1. Разный порядок захвата ресурсов. Это самая частая причина. Если две транзакции пытаются получить доступ к одним и тем же данным, но в разной последовательности, это может привести к взаимному ожиданию.
2. Неоптимальная работа запросов. Запросы, использующие сканирование таблиц (table scan, index scan) или конструкцию ДЛЯ ИЗМЕНЕНИЯ без достаточной оптимизации, могут приводить к избыточным блокировкам больших объемов данных, даже если реально изменяется только малая часть.
3. Несоответствующий уровень блокировки. Если блокировка устанавливается на недостаточном уровне (например, разделяемая), а затем транзакция пытается повысить ее до исключительной, это может вызвать конфликт.
4. Ошибки внутренних механизмов СУБД. Иногда сама СУБД, пытаясь распараллелить выполнение операций, может привести к тому, что эти параллельные процессы начинают блокировать друг друга.
5. Методические ошибки при использовании объектов метаданных.
* Константы: Использование констант для хранения часто меняющихся данных приводит к блокировке всех констант при каждом изменении, что резко снижает параллельность работы.
* Регистры накопления/бухгалтерии: Блокирующее чтение остатков в начале транзакции или отсутствие режима "разделения итогов" может вызывать избыточные блокировки.
6. Длительные транзакции. Чем дольше транзакция удерживает блокировки, тем выше вероятность возникновения конфликтов с другими транзакциями.
Для выявления причин взаимоблокировок нам помогут инструменты диагностики:
* Технологический журнал 1С. Это ключевой инструмент для выявления причин взаимоблокировок и длительных операций. События TLOCK (управляемые блокировки) и TDEADLOCK (взаимоблокировки) особенно полезны для анализа. Мы сможем увидеть, какие объекты были заблокированы, какими пользователями и в какой последовательности, что позволит нам восстановить картину конфликта.
* Инструменты мониторинга производительности СУБД. Они помогают выявить долгие запросы, ожидания на блокировках и загрузку ресурсов сервера.
Итак, мы выяснили, что УРБД не является подходящим инструментом для борьбы с блокировками. Давайте рассмотрим подробнее проверенные и эффективные методы решения этой проблемы.
Это одна из наиболее эффективных рекомендаций для конфигураций на платформе 1С:Предприятие 8.2 и выше.
* Преимущества:
* Собственный менеджер блокировок 1С. Платформа 1С берет на себя управление блокировками, что позволяет ей применять менее жесткие правила, чем СУБД, учитывать бизнес-логику и устанавливать более точные ограничения на чтение и запись данных.
* Повышение производительности. Управляемые блокировки могут значительно повысить параллельность работы и уменьшить количество ошибок, связанных с блокировками.
* Гибкость. Управляемые блокировки позволяют работать с более низким уровнем изоляции транзакций на уровне СУБД (например, READ COMMITTED), сохраняя при этом целостность данных на уровне приложения.
* Особенности:
* Переход на управляемые блокировки требует от разработчика самостоятельного контроля непротиворечивости данных и установки блокировок программно.
* Блокировки в управляемом режиме удерживаются до конца транзакции. Поэтому мы рекомендуем устанавливать их как можно ближе к концу транзакции, чтобы минимизировать время ожидания других пользователей.
Рассмотрим пример использования объекта БлокировкаДанных:
// Создаем объект для управления блокировками
Блокировка = Новый БлокировкаДанных;
// Добавляем элемент для блокировки регистра накопления "ОстаткиТоваров"
// Блокируем по измерениям "Номенклатура" и "Склад"
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ОстаткиТоваров");
ЭлементБлокировки.УстановитьЗначение("Номенклатура", МояНоменклатура);
ЭлементБлокировки.УстановитьЗначение("Склад", МойСклад);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный; // Для записи
// Или для справочника
// ЭлементБлокировки = Блокировка.Добавить("Справочник.Контрагенты");
// ЭлементБлокировки.УстановитьЗначение("Ссылка", МойКонтрагент);
// ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
// Устанавливаем блокировку. Если не удастся, будет исключение.
Попытка
Блокировка.Заблокировать();
Исключение
Сообщить("Не удалось заблокировать данные: " + ОписаниеОшибки());
Отказ = Истина;
Возврат;
КонецПопытки;
// После успешной блокировки выполняем операции по изменению данных
// ...
// Все изменения должны быть внутри одной транзакции
// ...
Это фундаментальный подход, который всегда должен применяться при проблемах с производительностью.
* Единообразный порядок захвата ресурсов. Мы должны стремиться к тому, чтобы во всех транзакциях, работающих с одними и теми же данными, ресурсы захватывались в одинаковом порядке. Например, всегда сначала блокируем регистр А, потом регистр Б.
* Минимизация длительности транзакций. Сокращение времени, в течение которого транзакция удерживает блокировки, значительно уменьшает вероятность конфликтов. Мы должны выносить из транзакций все операции, не требующие блокировок (например, долгие вычисления, обращения к внешним системам).
* Отказ от избыточного использования ДЛЯ ИЗМЕНЕНИЯ. Используйте эту конструкцию только тогда, когда это действительно необходимо. Если набор записей нужен только для чтения, не используйте ДЛЯ ИЗМЕНЕНИЯ.
* Исключение сканирования таблиц. Оптимизация запросов для предотвращения полных сканирований таблиц путем использования индексов. Мы должны анализировать планы запросов, чтобы убедиться, что они эффективно используют индексы.
* Использование запросов для чтения. Если набор записей нужен только для чтения, предпочтительнее использовать запросы, а не объектную модель (например, НайтиПоКоду()), так как это приводит к меньшим или более кратковременным блокировкам.
* Уменьшение гранулярности блокировок. Блокировать только те данные, которые действительно необходимы, а не целые таблицы или регистры целиком.
Посмотрим на пример неоптимального запроса и его возможную оптимизацию:
// Неоптимальный запрос, блокирующий весь регистр (или значительную часть)
// если нет точных отборов по измерениям
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ОстаткиТоваровОстатки.Номенклатура,
| ОстаткиТоваровОстатки.Склад,
| ОстаткиТоваровОстатки.КоличествоОстаток
|ИЗ
| РегистрНакопления.ОстаткиТоваров.Остатки КАК ОстаткиТоваровОстатки
|ГДЕ
| ОстаткиТоваровОстатки.КоличествоОстаток > 0
|
|ДЛЯ ИЗМЕНЕНИЯ ОстаткиТоваровОстатки";
// Оптимизированный запрос с точными отборами и блокировкой только необходимых строк
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ОстаткиТоваровОстатки.Номенклатура,
| ОстаткиТоваровОстатки.Склад,
| ОстаткиТоваровОстатки.КоличествоОстаток
|ИЗ
| РегистрНакопления.ОстаткиТоваров.Остатки КАК ОстаткиТоваровОстатки
|ГДЕ
| ОстаткиТоваровОстатки.Номенклатура = &МояНоменклатура
| И ОстаткиТоваровОстатки.Склад = &МойСклад
|
|ДЛЯ ИЗМЕНЕНИЯ ОстаткиТоваровОстатки";
Запрос.УстановитьПараметр("МояНоменклатура", МояНоменклатура);
Запрос.УстановитьПараметр("МойСклад", МойСклад);
Мы можем помочь СУБД избежать некоторых типов взаимоблокировок, особенно вызванных распараллеливанием.
* Параметр max degree of parallelism = 1. Установка этого параметра в СУБД (например, SQL Server) может помочь избежать взаимоблокировок, вызванных избыточным распараллеливанием выполнения операций. Однако применять его следует осторожно и после консультации с администратором СУБД, так как в некоторых случаях это может повлиять на общую производительность.
Некоторые проблемы с блокировками имеют методологический характер и требуют пересмотра архитектуры данных. * Пересмотр использования констант. Избегайте хранения часто меняющихся данных в константах. Если значение константы меняется часто, это приводит к блокировке всей таблицы констант при каждом изменении, что снижает параллельность работы. Используйте регистры сведений, справочники или другие объекты, предназначенные для хранения изменяемых данных. * Включение режима "разделения итогов". Для регистров накопления и бухгалтерии это может значительно повысить параллельность записи. Если режим "разделения итогов" включен, платформа может записывать данные в разные части регистра, уменьшая конфликты. * Смещение блокирующего чтения остатков. Переносите такое чтение как можно ближе к концу транзакции. Чем позже мы заблокируем данные, тем меньше будет время, в течение которого они недоступны для других пользователей. * Минимизация изменений больших объемов данных в одной транзакции. Мы должны стараться разбивать объемные операции на более мелкие, если это возможно, чтобы уменьшить длительность и объем блокировок.
Если внутренние компетенции по оптимизации и диагностике блокировок недостаточны, мы настоятельно рекомендуем обратиться к специалистам. Расследование взаимоблокировок — это сложная задача, требующая глубоких знаний платформы 1С, СУБД и методов анализа производительности. Профессионалы смогут быстро выявить корневые причины и предложить оптимальные решения. В заключение, мы хотим подчеркнуть, что борьба с взаимоблокировками — это комплексная задача, требующая системного подхода. Разделение базы через УРБД не решает проблему, а лишь уводит нас в сторону, создавая новые сложности. Вместо этого, сосредоточимся на тщательной диагностике, оптимизации кода, правильном использовании механизмов блокировок и архитектурных решениях.
← К списку