Описание основных возможных причин возникновения блокировок при работе пользователей

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

Описание основных возможных причин возникновения блокировок при работе пользователей.

 

 1. Сервер

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

 

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

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

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

Условия возникновения укрупнения блокировок

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, таким образом настраивая сервер на статическое использование памяти. Поскольку укрупнение блокировок относится к доступной памяти, резервирование памяти от конкурирующих процессов может положительно влиять на возможность возникновения укрупнений.

 Регламентные операций на уровне СУБД.

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

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

 Выполнение регламентных процедур должно быть автоматизировано. Для автоматизации этих операций рекомендуется использовать встроенное средства MS SQL Server: Maintenance Plan. Существуют так же другие способы автоматизации выполнения этих процедур. В настоящей статье для каждой регламентной процедуры дан пример ее настройки при помощи Maintenance Plan для MS SQL Server 2005.

 Для MS SQL Server рекомендуется выполнять следующие регламентные операции:

Обновление статистики

Очистка процедурного КЭШа

Дефрагментация индексов

Реиндексация таблиц базы данных

 Рекомендуется регулярно контролировать своевременность и правильность выполнения данных регламентных процедур.

 Кроме всего прочего необходимо учитывать следующую информацию от пользователей. Периодически возникают дни, когда производительность резко возрастает без видимых на то причин. Теоретически существенных изменений в 1С в этот момент не происходит и эти «дни» не связаны с изменениями конфигурации 1С.

 Выводы:

Необходимо провести анализ загруженности сервера и ПО (Server SQL), используемого на сервере, его настроек и регламентных операций.

 

 2.Архитектура и состояние базы  1С.

 Здесь описываются неоптимальные используемые решения по архитектуре используемой  конфигурации.


Используются механизмы типовых конфигураци, которые ввиду их направленности на универсальность не всегда оптимальны для текущих потребностей.

 Пример:

 а) Проведение документов по регистру «ПартииТоваровНаСкладах» использует типовой» набор функций и процедур, запрос остатков по партиям занимает для отдельных документов до 80% времени.

 б) Сдвиг границы последовательности при неоперативном проведении документов по регистру «ПартииТоваровНаСкладах».

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

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

 

Для регистров накопления не включен режим разделения итогов.

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

 

Архитектура «типовых» и «не типовых» регистров не всегда соответствует оптимальной для производительности в рамках текущей базы данных.

Примеры: регистр «ЗначенияСвойствОбъектов» — универсален для записи значений характеристик, но например для каждой характеристики заводится много записей (5 и более), что не является оптимальным способом хранения, если известно, что количество свойств не меняется.

Выводы:

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

 

3. Перечень возможных действий.

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

 

Проведение регламентных операций MS SQL Server.

Анализ и возможное изменение настроек MS SQL Server.

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

Оптимизация типовых процедур выполняемых при проведении документов, в частности запрос остатков для регистра «ПартииТоваровНаСкладах».

Удаление из процедур проведения документов процедуры по сдвигу границы последовательности.

Анализ регистров и установка при необходимости измерениям признака «индексировать», изменения порядка следования измерений при необходимости.

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

Анализ основных используемых типовых регистров, дублирование данных этих регистров в специализированных созданных новых регистрах, перенос запросов и т.д. на новые регистры. Как вариант возможное удаление типовых уже не используемых более регистров. (пример: замена регистра «ЗначениеСвойствОбъектов» с набором из 5 записей, регистром с 5-ю ресурсами и одной записью, соответствующей данным из 5 записей)

Анализ и оптимизация запросов и алгоритмов в обработках проведения документов, которые являются длительными по времени выполнения.

 Анализ и оптимизация запросов и алгоритмов в отчетах и обработках, которые являются длительными по времени выполнения.

«Обрезание» базы данных и перенос остатков.

 

4 Comments

  1. headMade

    Для регистров накопления не включен режим разделения итогов.

    Однако, если при этом используется контроль остатков, то режим разделения итогов не даст положительного эффекта.

    А почему не даст положит. результата? Объясните плиз

    Reply
  2. zhleonid8

    «Обрезание» базы данных и перенос остатков…………

    это вообще тупик….проверено.

    в бухгалтерии это приводит к коллапсу

    Reply
  3. Sairys

    Очень похожа на измененную статью Гилёва.

    Reply
  4. Sairys

    Но всё равно спасибо автору

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *