Гилёв Вячеслав -Влияние блокировок на производительность 1С:Предприятие 8.1

Статья посвящана решению вопросов производтельности многопользовательских систем на платформе 1С:Предприятие 8.1.

Применение в российском бизнесе 1С:Предприятие 8.1 широко: продукт можно увидеть как в маленьких конторах (для бухгалтера), так и в компаниях с десятками-сотнями пользователей (много разных решаемых задач). Для средних и крупных компаний использование 1С:Предприятие 8.1 в многопользовательском режиме имеет ряд характерных особенностей, которые отсутствует при однопользовательской работе (монопольной) у маленьких компаний. Это статья посвящена влиянию механизма блокировок, влияющему на одновременную работу большого числа пользователей.
В этой статье будет изложена личная позиция автора, принимавшего участие в десятках крупных проектах. Автор не претендует на абсолютную истину, но уверен, что его опыт может пригодиться при решении вопросов производительности 1С:Предприяите 8.1. Будут рассмотрены явления, связанные с блокировками и их влияние на производительность:

Пояснения, перед тем как вы начнете читать дальше

Особо хочется отметить, что разбор простых понятных проблем с низким быстродействием уже изложен в статье «Влияние оптимизатора запросов…». Такие проблемы обычно «видны», т.е. их можно обнаружить, они воспроизводиться чаще всего и в монопольном режиме.
Здесь же мы сосредоточимся на диагностике сложных проблем с непонятным источником происхождения, например возникающем при большом количестве пользователей.

Суть проблемы решения вопросов производительности в многопользовательском режиме

Часто наблюдал (и сам так ошибался), как специалисты пытаются решить сложные комплексные проблемы с быстродействием тем же путем, как и простые проблемы производительности, когда причина одна и понятно что делать. Другими словами, просто делается попытка найти самый долгий запрос и оптимизировать его. Другой характерный прием – это посоветоваться с другими руководителями проектов (без необходимых для этих вопросов технических знаний) и не привлекать экспертов, специально занимающихся задачами производительности. Такой способ решения проблемы будет носить вероятностный характер, т.е. если «звезды совпадут» то есть шанс решить проблему. Но вот гарантий в таких случаях не бывает. Это происходит в результате отсутствие объективной информации о производительности системы. Сложно правильно оценить ситуацию и предложить адекватные меры.
Также популярны попытки решать проблему только знанием механизмов 1С:Предприятие без знания механизмов блокировок. Отмету отсутствие замеров показателей до устранения неисправностей и после. Более того, еще же надо сообразить, какие показатели использовать и каковы граничные значения, не так ли? Руководителям проектов характерны попытки решить проблемой настройкой серверов, недооценивая сложность и первопричины ситуации.
У руководителей попросту отсутствует информации обо всех проблемах производительности. Они не могут точно ответить на вопросы вроде «сколько проблем в системе», «где конкретно они возникают», «каждая из проблем с какой точно частотой возникает», «какие проблемы значимы, а какие второстепенны». Этот список можно продолжать.
Кроме этого, и технические специалисты в таких случаях не владеют полной информацией по каждой проблеме. А точнее не знают полный контекст проблемы, без которого сложно понять причину ее возникновения. Кстати, обычно причин несколько.

Во первых собрать полный контекст при одновременно работающих 200 пользователях невероятно сложно, а до недавнего времени средства автоматического сбора отсутствовали (таким продуктом является 1С:ЦУП).

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

Для анализа сложных комплексных проблем быстродействия используйте 1С:ЦУП

Завершаю пугать и даю конкретный совет: Вам нужен инструмент, который выполнит автоматизированный сбор данных, содержащих информацию о проблемах медленных запросов, блокировок, взаимных блокировок. Этот инструмент должен сгруппировать проблемы «по весу», т.е. задать порядок их расследования по степени вклада в общий вопрос производительности. Автору известен только один такой инструмент – 1С: Центр управления производительностью. Подробности здесь. Перечень компаний, где есть специалисты, умеющих с ним работать приведены в этом списке. Обратите внимание, что полный анализ ЦУПом возможен пока только для СУБД MS SQL Server 2005.

Анализ проблем с помощью 1С:ЦУП

Итак, мы сказали, что в качестве панацеи надо использовать Центр Управления Производительностью. Для решения проблем сначало надо собрать "логи", в которых ЦУП вычленит информацию в следующих показателях производительности:

- время запроса (разумеется, отранжировав проблемные запросы по весу (время запроса на количество вызовов этого запроса);

Т.е. мы сможем собрать проблемы, которые будут сгруппированны по источникам происхождения (код конфигурации и объекты метаданных). Не надо обольщаться, что тем самым мы автоматически решим все проблемы. Но мы сможем выполнить самую главную задачу, которую в ручную иногда сделать нельзя - понять, В ЧЕМ СУТЬ ПРОБЛЕМЫ!

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

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

В данной статье сосредоточимся на упомянутых 80% ситуаций, обрабатываемых ЦУПом. Расмотрим анализ информации, собранной автоматически с помощью ЦУПа.

Время исполнения запроса

Как уже сказал в статье «Влияние оптимизатора запросов…» двумя наиболее вероятными причинами долгого ИСПОЛНЕНИЯ ЗАПРОСА являются отсутствующие индексы и сложность запроса. Однако время отклика пользователю состоит из ИСПОЛНЕНИЯ ЗАПРОСА и ОЖИДАНИЙ ЗАПРОСА. Посмотрим на вторую составляющую. Ожиданиями условно можно обозначить очереди к конкурентным ресурсам. Часть времении исполнения запросы могут ничего не делать (отсюда отсутствие загруженности железа), а просто ожидать своей очереди, когда будет снята блокировка с ресурса, который нужен запросу. Кстати ресурсом может быть справочник, документ, регистр, практически большинство объектов метаданных.

После того, ЦУП выполнит сбор данных для анализа, в режиме просмотра мы получим группировку кода конфигурации и объектов конфигурации в разрезе озвученных ранее трех критериев (время запроса, время ожидания блокировок, количество взаимных блокировк).

Влияние блокировок на производительность

Можно ли отказаться от блокировок?

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

Как работают блокировки (этот пункт можно не читать)

Работой с блокировками занимается специальный модуль SQL Server’а – менеджер блокировок (Lock Manager). В его задачи входит:

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

Основная причина, снижающая быстродействие – блокировки

Ожидания на блокировках являются основной проблемой быстродействия многопользовательского режима. И это понятно, ведь они увеличивают время ожидания операций, а значит и время отклика. Можно ли сказать, что ожидание на блокировках – это не правильно и ошибка многопользовательской системы? Так сказать нельзя, поскольку сам по себе механизм блокирования ресурсов обеспечивает целостность данных. С помощью механизма блокировок конкурентные данные ЗАПИСЫВАЮТСЯ ПОСЛЕДОВАТЕЛЬНО.

Разница между необходимыми и избыточными блокировками

Когда пользователь сообщает об ошибке ожидания на блокировке, то с его точки зрения это всегда ошибка, потому что она например мешает ему работать – увеличивается время выполнения его

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

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

А транзакция - это множество вычислений и операций с данными (наиболее яркий пример - при проведении документа) , выполняемых как единое целое. Невыполнений любой из операции транзакции приводит к отмене транзакции целиком.

Итак,пользователи в многопользовательских информационных базах могут часто жаловаться, что невозможно работать из-за этих блокировок, при этом в коде действительно могут быть блокировки, которые в этом месте не нужны (избыточные).
А еще и в коде конфигурации они сами по себе блокировки могут не присутствавать, про них можно прочитать например здесь http://kb.1c.ru/articleView.jsp?id=30 (статья является фрагментом книги П.С.Белоусов, А.В.Островерх "1С:Предприятие: от 8.0 к 8.1".). Предлагаю упрощенный способ объяснения различия блокировок на простом примере так:

В вашей конфигурации в режиме 1С:Предприятие создайте две одинаковых накладных с одинаковым составом товара. Но обязательно укажите различные склады поступления.
В коде обработки проведения надо добавить строчку с выводом на экран сообщения (или другой код, способный задержать исполнение обработки проведения на 21 секунду ( таймаут блокировки происходит через 20 секунд, если параметры по умолчанию)).
Проводите два документа.
Если возникает таймаут, а по логике товары приходят на разные склады, в приложении присутствуют избыточные блокировки. Бизнес – логике (считай по здравому смыслу) здесь блокировок не должно быть.
Если же мы теперь сделаем в этих двух накладных одинаковые склады. То созданные блокировки в результате попытки одновременного проведения приведут НЕОБХОДИМОЙ блокировке и это ХОРОШО!

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

Конечно даже этот простой пример оставляет много вопросов. Например, а если документы от одного поставщика и «двигается» задолженность по нему. А если двигаются не одни остатки на складе, а несколько регистров, а документы разного вида.
Но самый главный вопрос – А ПО КАКОЙ ТАКОЙ БИЗНЕС-ЛОГИКЕ НЕ ДОЛЖНО БЫТЬ БЛОКИРОВОК. Кто эту бизнес – логику и где прописывает в контексте блокировок? Но довайте обо всем по порядку.

Избыточные блокировки – лишние – которые не нужны с точки зрения обеспечения целостности данных и при этом снижающие общую производительность системы, увеличивая общее время «простоя» - ожидания на блокировках.
Необходимая блокировка возникает при захвате двумя пользователями одних и тех же ресурсов (объектов данных). Если же пользователи работают с непересекающимися ресурсами, но при этом происходит ожидание на блокировке, то блокировка считается избыточной.
ЦУП не отличает избыточные блокировки от необходимых! Для определения избыточности нужно «анализировать» блокировки.

Наиболее понятными критериями избыточности блокировок обозначу:

2. Уровень (область) блокировки выше необходимой (как частный случай повышения уровня блокировки, т.н. эскалация);

3. Время блокировки больше времени "реального" использования объекта блокировки.

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

Получив информацию о группировках проблем в разрезе метаданных 1С:Предприятие, рекомендую обратить внимание прежде всего на объектах:

1) В константы лучше ничего не писать. В крайнем случаи делать это из под одного пользователя, и то помнит, что пока пользователь "пишет" одну константу, не только эту, но и любую другую константу другие пользователи будут "ждать". Поэтому особо опасно использовать констатны в обработке проведения. Значения всех констант хранятся в одном ресурсе.

На рисунке показано физическое размещение констант конфигурации УПП в таблице базы данных MS SQL Server 2005.

Это означает, что при блокировке одной константы будут заблокированы все константы. СУБД накладывает блокировку на ВСЮ единственную СТРОКУ таблицы, т.е. на все константы.

2) Отказаться от использования объекта метаданных "Последовательность". Хотя бы от движений при оперативном проведении, проводить при неоперативном (допроведении). Смотрите, как реализовано в последних версиях УПП.

3) Если в системе осуществляется оперативная запись движений по бухгалтерскому регистру в многопользовательском режиме, то рекомендуется:

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

5) Избавиться от некоторых избыточных блокировок, создаваемых платформой можно только путем использования "управляемых" блокировок. В автоматическом режиме работы конфигураций платформа "берет на себя" блокирование ресурсов. Цена беззаботного использования автоматического режима - возможны блокировки на границах диапазонов индексов, блокировки пустой таблицы, эскалация блокировок.

На рисунке показан пример, где блокировки, устанавливаемые процессом 1 (документ «РеализаяТоваровУслуг») возникают только при работе в автоматическом режиме. Характерным признаком таких блокировок является значение поля режим = «Range…»

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

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

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

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

Основные причины избыточных блокировок (подитожим выше сказанное)

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

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

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

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

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

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

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

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

Одна из причин избыточной эскалации - недостаток памяти

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

Блокировки всегда хранятся в памяти не 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% вероятностью смогут помыться и сколько гарантированно не смогут помыться машин. А возникший диапазон будет интервалом вероятностного характера. Тоже самое происходит из блокировками, мы можем говорить только либо о "крайних" значениях, когда они наверняка будут или не будут, все промежуточные цифры носят вероятностный характер. Поэтому чтобы как то успокоить, хочу сказать, что для замера эскалации можно также применить ЦУП.

Использование ЦУП для замера эскалации

В типовой конфигурации ЦУП можно исследовать параметр "Гранулярность".

Соответственно, если гранулой окажется таблица, то это результат эскалации.

Вот небольшой пример, как собрать факт эскалации.

Включите изменения в конфигурации и в общем макете "ПараметрыПоказателейПроизводительности" завершите текст строками:

<o:group name="Эскалация" lineType="Сплошная" lineWeight="3">
<o:counter name="ЭскалацияБлокировок" code="_31_EA____" unit="Штука" interactive="true" scale="1" r="138" g="43" b="226">
<o:support>
<o:dbms type="MSSQLServer" version="80" dlm_auto="true" dlm_mixed="true" dlm_managed="true" />
</o:support>
</o:counter>
</o:group>
</o:counterOptions>

Далее в справочник Показатели добавьте предопределенный элемент ЭскалацияБлокировок с кодом _31_EA____

и в общем модуле ПараметрыПроизводительности в процедуре ПолучитьЗначенияСчетчиков

найди строку условия Если Показатель = Справочники.Показатель.КоличествоТаймаутов Тогда
и добавьте строки к условию:

ИначеЕсли Показатель = Справочники.Показатель.ЭскалацияБлокировок Тогда //gilv
ТекстЗапроса = "SELECT * FROM sys.dm_os_performance_counters WHERE counter_name like 'Table Lock Escalations%'";
Результат = MSSQL.ВыполнитьЗапросСУБД(ТекстЗапроса,Контекст.MSSQLСервер());
ТекЧисло = Число(Результат.GetColumnString(1,4));
//СерверСУБД.Close();

Если СтрокаПоказателя.Значение = Неопределено Тогда СтрокаПоказателя.Значение = 0 КонецЕсли;
Если глСчетчикЭскалаций < ТекЧисло Тогда
СтрокаПоказателя.Значение = ТекЧисло - глСчетчикЭскалаций;
глСчетчикЭскалаций = ТекЧисло;
Прервать;
Иначе
СтрокаПоказателя.Значение = 0;
КонецЕсли;

Перем глСчетчикЭскалаций Экспорт;
Вроде все :)

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

Выводы Руководителям Проектов и CIO (IT-директорам)

- Покупая проект - покупайте ЦУП (КИП) и закладывайтесь на регламент по мониторингу и оптимизации производительности функционала

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

Выводы Системным Администраторам

- Используйте ЦУП для периодическго мониторинга "здоровья" системы, Вы всегда будете знать - "кто виноват"?

- Кстати, читайте руководство по продукту, там описаны некоторые аспекты специально для Вас.

- Если сервер сильно загружен, сначало устраните эту проблему, и только потом зовите программиста.

Выводы Программистам

- Используйте ЦУП для сбора полной информации по сложным проблемам производительности, Вы всегда будете понимать - "что делать"?

Неочевидные выводы

Понятно, что все вопросы сразу не охватить, здесь лишь наиболее часто упоминаемые. Хочу в качестве оправдания пообещать отдельную статью по взаимным блокировкам. И по остальным аспектам тоже наверно. Все это доказывает, что знаматься этой проблемой надо серьезно:

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

Именно поэтому существуют "эксперты" :). Если у Вас есть вопросы (типа а как интерпретировать собранные результаты ЦУПом и т.п.), напишите их например мне gilv (at) rarus.ru.

Влияние блокировок на производительность 1С:Предприятие 8.1

Содержание статьи