Эскалация блокировок 1c

Укрупнение области блокирования (эскалация) в MS SQL Server и 1С:Предприятие

Реальный опыт коллег

 http://partners.v8.1c.ru/forum/thread.jsp?id=869067 говорит о том, что эскалация блокировок может начинаться при записи наборов строк по 20000 -20010 записей или более!
Очень часто это сопровождается возникновением взаимных блокировок при таких записях, при этом иногда достаточно порядка 3000 строк в операции записи.
В документации MS SQL Server

Укрупнение блокировки включается в том случае, если не выключено для таблицы с помощью параметра ALTER TABLE SET LOCK_ESCALATION, и если выполняется одно из следующих условий.

  • Одна инструкция Transact-SQL получает более 5 000 блокировок в одной несекционированной таблице или индексе.
  • Одна инструкция Transact-SQL получает более 5 000 блокировок в одной секции секционированной таблицы, а параметр ALTER TABLE SET LOCK_ESCALATION установлен в значение AUTO.
  • Число блокировок в экземпляре компонента Database Engine превышает объем памяти или заданные пороговые значения.  Порог памяти зависит от параметра конфигурации locks:
  • Если параметр locks имеет значение по умолчанию 0, порог укрупнения блокировок достигается, если память, используемая объектами блокировки, составляет 24 % от памяти компонента Database Engine, исключая память AWE. Структура данных, представляющая блокировку, имеет длину примерно в 100 байт. Этот порог динамический, поскольку компонент Database Engine динамически получает и освобождает память в целях компенсации меняющейся рабочей нагрузки.

  • Если параметр locks имеет значение, отличное от 0, порог укрупнения блокировок составляет 40 процентов (или меньше, если памяти мало) от значения параметра locks.

Если блокировки не могут быть укрупнены из-за конфликтов блокировок, компонент Database Engine периодически инициирует укрупнение блокировки при получении каждых 1 250 новых блокировок.

Если на Вашем предприятии записываются документы 1С с табличной частью или движениям по регистрам более 1000 строк, то попробуйте при не очень загруженном MS SQL Server выполнить следующее

DBCC TRACEON (1211,-1);
DBCC TRACEON (1224,-1);
и установить параметр LOCK в 10 000 000 вместо 0.
Подбробнее читайте здесь http://msdn.microsoft.com/ru-ru/library/ms188396%28SQL.90%29.aspx
Также существует вариант использовать секционирование и в секционированных таблицах параметр LOCK_ESCALATION инструкции ALTER TABLE позволяет произвести укрупнение до уровня HoBT (вместо уровня таблицы) или отключить укрупнение блокировок. Правда тут надо четко знать какие строчки изначально блокируются, что бы секции оказались эффективными.
Обратите внимание, что эскалация на сервере 1С существует тоже!
А блокировки сервера 1С существуют не на сервере MS SQL Server, а в оперативной памяти сервера 1С. Есть мнение, что порог эскалации находится в районе 5000 строк.
Немного общей теории

ЭСКАЛАЦИЯ БЛОКИРОВОК

Эскалация блокировок – механизм повышения гранул (области) блокировки. Основная задача эскалации состоит в повышение производительность при очень большом количестве блокировок за счет укрупнения области блокировки. Например, вместо блокировок на каждую строчку таблица будет наложена блокировка на всю таблицу. Это конечно «упрощает» работу  СУБД, но уменьшает параллельность конкурентных ресурсов. Т.е. результат эскалации — избыточная блокировка с целью сохранить производительность железа.

УСЛОВИЯ ВОЗНИКНОВЕНИЯ УКРУПНЕНИЯ БЛОКИРОВОК

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

Как показано на рисунке, укрупнение происходит в случае, если количество блокировок в определенном просмотре превышает 5 000, или если память, используемая системой для блокировок, превышает доступный объем:

  • ядром СУБД используется 24 процента памяти не AWE при параметре блокировок – 0;
  • ядром СУБД используется 40 процентов памяти не AWE при параметре блокировок, отличном от 0.

Возникающая блокировка всегда является блокировкой таблицы.

ОДНА ИЗ ПРИЧИН ИЗБЫТОЧНОЙ ЭСКАЛАЦИИ — НЕДОСТАТОК ПАМЯТИ

 

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

Блокировки всегда хранятся в памяти не AWE, поэтому увеличение объема памяти не AWE ведет к увеличению емкости системы для хранения блокировок. При попытке увеличения емкости блокировок наилучшим вариантом является использование 64-разрядной архитектуры, поскольку 32-разрядная архитектура ограничена 4 ГБ памяти не AWE, тогда как 64-разрядная архитектура не имеет такого ограничения. 32-разрядных системах можно использовать дополнительный гигабайт памяти операционной системы для сервера SQL Server путем добавления параметра /3GB к файла Boot.ini.

ПАРАМЕТРЫ КОНФИГУРАЦИИ SQL SERVER, ВЛИЯЩИЕ НА ЭСКАЛАЦИЮ

С помощью процедуры sp_configure можно настроить различные параметры, влияющие на блокировку. Параметр блокировок определяет количество блокировок, которое может храниться в системе до возникновения ошибки. Значение этого параметра по умолчанию – 0, что означает, что сервер динамически регулирует количество зарезервированных блокировок с другими процессами, конкурирующими за доступ к памяти. SQL изначально резервирует 2 500 блокировок, а каждая блокировка занимает 96 байт памяти. Выгружаемая память не используется.

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

ЧАСТОТА ЭСКАЛАЦИИ БЛОКИРОВОК, ДА И ПРОСТО БЛОКИРОВОК

Попробуйте ответить на вопрос: например сколько машин за час будут помыты на автомойке?
Кажется что все просто. Мы должны узнать количество помытых машин за час — скорость помывки. И определить пропускную способность – сколько одновременно машин на автомойке могут мыться.
НО!, кроме скорости и пропускной способности на мойке многое зависит от количества желающих помыть свои машины, и не просто их количество, но и их возможности ждать очередь определенно время (в идеале они должны ждать одинаковое количество времени:)), а также распределение по времени, когда они приезжают на мойку. А это уже вероятностные величины.
Т.е. мы можем посчитать, сколько со 100% вероятностью смогут помыться и сколько гарантированно не смогут помыться машин. А возникший диапазон будет интервалом вероятностного характера. Тоже самое происходит из блокировками, мы можем говорить только либо о «крайних» значениях, когда они наверняка будут или не будут, все промежуточные цифры носят вероятностный характер. Поэтому чтобы как то успокоить, хочу сказать, что для замера эскалации можно также применить сервис Анализа загруженности оборудования

смотрите также настройку эскалации для конкретной таблицы