Интернет-магазин Доставка и оплата

Мы выбрали для Вас офис в Москве.

Вы можете изменить его на офис в другом городе.

1c-crm-red
От экспертов «1С‑Рарус»: Производительность нового RLS в 1С БСП 3. Переходить или нет?
13 августа 2020

От экспертов «1С‑Рарус»: Производительность нового RLS в 1С БСП 3. Переходить или нет?

Производительность механизма ограничения прав на уровне записи в «1С» (RLS)

Одним из известных источников проблем производительности в «1С» является механизм RLS (Record Level Security). Связано это, как мы увидим ниже, с построением неоптимального плана запроса. Часто на больших проектах, проектные команды доходили вплоть до отказа от использования этого механизма и разрабатывали на уровне прикладного кода свои механизмы.

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

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

В рамках данной статьи проведен тщательный сравнительный анализ нового подхода и основные нюансы по переходу на него.

Архитектурный обзор

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

Архитектурный обзор

Принципиальным моментом для нас является то, что сами тексты шаблонов значительно отличаются в новом и старом подходе. В новом они ультракомпактны. За выбор между новым и старым RLS отвечает константа «ОграничениеДоступаНаУровне
ЗаписейУниверсально»:

Архитектурный обзор

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

Архитектурный обзор

В старом RLS участвуют шаблоны «ПоЗначениям», «ПоЗначениямРасширенный», «ПоЗначениямИНаборам
Расширенный», «ПоНаборамЗначений». Они имеют большое количество параметров, где мы в простейшем случае указываем имя объекта и право, которое мы ограничиваем, а дальше попарно перечисляем вид доступа, который ограничиваем и имя реквизита объекта, по которому производится фильтрация:

Архитектурный обзор

В самом шаблоне для каждой пары параметров «вид доступа — имя реквизита» добавляется текст проверки ограничения, при этом используются регистры сведений:

  • ТаблицыГруппДоступа,
  • ЗначенияГруппДоступа.

Недостаток такого подхода заключается в масштабируемости, чем больше видов доступа настраиваем для объекта, тем больше финальный текст запроса в СУБД и количество левых соединение в нем:

Архитектурный обзор

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

В новом же RLS используются шаблоны доступа «ДляОбъекта» и «ДляРегистра». В перечисленных шаблонах используются уже другие сущности для проверки прав доступа.

Регистр сведений для хранения настроек:

  • ПараметрыОграниченияДоступа.

Регистры сведений для проверки ограничений:

  • КлючиДоступаКОбъектам,
  • КлючиДоступаПользователей.

Справочники ключей:

  • КлючиДоступа,
  • НаборыГруппДоступа.

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

Архитектурный обзор

Достигается это за счет устройства регистров сведений для проверки ограничений «КлючиДоступаКОбъектам» и «КлючиДоступаПользователей».

Регистры имеют следующую структуру:

Архитектурный обзор

Архитектурный обзор

Здесь объект — это ссылка на конкретный объект в информационной базе (например, «Приходная накладная 0001 от 01.08.2020»), а ключ доступа пользователей — это специальный справочник, представляющий из себя составной ключ, содержащий определенную комбинацию значений видов доступа:

Архитектурный обзор

Стоит обратить внимание на реквизиты Значение 1, Значение 2 и т. д. В них будет содержаться комбинация конкретных значений видов доступа. Например, для видов доступа Организация, Структурная единица это могут быть «Ресторан», «Кухня-цех» или «Кафе Аленка», «Кухня-склад» и т. д.

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

Архитектурный обзор

Регистр ключей доступа пользователей в измерении «Пользователь» содержит справочник ключей пользователей, к которым применяется ограничение, а также справочник ключей доступа к объектам.

Таким образом при проверке ограничений доступа вне зависимости от количества настроенных для конкретного проверяемого объекта видов доступа запрос всегда будет дополняться одним соединением с регистром «Ключи доступа к объектам» по проверяемому объекту и с регистром «Ключи доступа пользователей» по текущему пользователю:

Архитектурный обзор

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

Архитектурный обзор

Переход со старого на новый и обратно

Если вы используете старый механизм RLS (или не используете ограничение на уровне записей вовсе) и хотите перейти на новый, то можно это сделать, выполнив несложную последовательность действий:

  • Убедиться, что ваша конфигурация разработана на версии БСП 3.0.1 и выше. Если это не так, то необходимо будет выполнить соответствующее обновление.
  • Для работы с новым механизмом RLS необходимо включить константы «Ограничивать доступ на уровне записей» и «Ограничивать доступ на уровне записей Производительный». Не во всех типовых решениях вторая константа вынесена в интерфейс, поэтому проще всего это сделать через меню «Все функции»:

    Переход со старого на новый и обратно

  • Далее, если в конфигурации есть доработки по ролям, то нам необходимо в эти роли прописать шаблоны ограничений «ДляОбъекта» и «ДляРегистра». Сделать это можно несколькими способами:
    • Если ролей немного, то копируем шаблоны из какой-либо типовой роли вручную.
    • Если же ролей большое количество, то можно воспользоваться обработкой «ПроверкаВнедренияБСП», которая входит в дополнительные файлы поставки БСП.
    • Третий вариант — самостоятельно написать обработку, которая выгрузит конфигурацию в файлы и допишет новые шаблоны в доработанные роли.
  • В общем модуле «УправлениеДоступом
    Переопределяемый» в процедуру «ПриЗаполненииСписковС
    ОграничениемДоступа» дописать объекты, которые будут использовать новый механизм проверки ограничений на уровне записей:

    Переход со старого на новый и обратно

  • В модуле менеджера каждого из объектов, который был описан в предыдущем шаге, добавить функцию «ПриЗаполненииОграничений
    Доступа», в которой на специальном языке описания ограничений указать какие виды доступа необходимо проверить:

    Переход со старого на новый и обратно

Подробное описание языка ограничений есть на ИТС, а также синтаксис языка ограничений находится в модуле «УправлениеДоступомСлужебный» в функции «СинтаксисЯзыка».

  • В форме элемента объекта в функции «ПриЧтенииНаСервере» дописать следующий вызов общего модуля подсистемы «Управление доступом»:

    Переход со старого на новый и обратно

  • В определяемых типах «ВладелецЗначенийКлючей
    ДоступаДокумент», «ВладелецЗначенийКлючей
    ДоступаНаборЗаписей», «ВладелецЗначенийКлючей
    ДоступаОбъект» добавить вышеописанные объекты / наборы записей регистров.
  • Также для регистров сведений или накопления необходимо в справочнике «Идентификаторы объектов метаданных» добавить предопределенные элементы в соответствии с уже существующими:

    Переход со старого на новый и обратно

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

    Переход со старого на новый и обратно

  • Последним пунктом будет убедиться в том, что регламентное задание по обновлению ключей доступа к данным выполнено и справочник ключей доступа заполнился. Для этого в БСП есть специальная форма «Обновление доступа на уровне записей», которая обычно открывается из настроек программы. Справочник «Ключи доступа» можно открыть через «Все функции» и убедиться, что он не пустой.

    Переход со старого на новый и обратно

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

Стоит отметить, что после выполненных действий не составит труда вернуться на старый механизм RLS и обратно, если это требуется.

Для этого необходимо изменить константу «Ограничивать доступ на уровне записей универсально». Это достигается благодаря тому, что старый и новый механизм ограничения доступа на уровне записей используют разные объекты метаданных.

При переключении константы система просто станет использовать другие регистры для проверки ограничений. Дополнительно при переключении на новый механизм RLS будет произведено обновление ключей доступа к объектам и ключей доступа пользователей.

Сравнительное тестирование

Итак, приступим непосредственно к проведению сравнительного тестирования двух систем RLS.

Параметры стенда:

  • Две базы с одинаковой конфигурацией «1С:УНФ 8. Управление предприятием общепита» ред. 1.6.21.103 с БСП ред. 3.1.3.179.
  • Платформа 1С: 8.3.16.1296.
  • Операционная система: Windows Server 2012 R2.
  • База данных: Microsoft SQL Server 2017 64х.
  • Конфигурация сервера:
    • Процессор: Intel Xeon X5680 12M Cache 3.33, 6 ядер, 2 шт.
    • Оперативная память: 192 ГБ DDR3.
    • Дисковые накопители: HGST HUH 721212ALE604 (файлы баз данных), Intel SSDSC2BA800G4 (системный диск, tempdb).
  • СУБД и кластер «1С» на одном сервере.

Параметры операций для тестирования

В качестве основных объектов наблюдения были выбраны:

  • Документ «Приходная накладная».
  • Регистр накопления «Запасы». Собственно, этот регистр двигается при проведении исследуемого документа.

Операции:

  • Запись и проведение документов «Приходная накладная».
  • Выполнение запросов:
    1. Выборка документов «Приходная накладная» со всеми реквизитами без табличной части, за выбранный период пользователю доступно 22–25 тыс. документов.
    2. Аналогичная выборка из п. 1, но ограниченная первыми 45 элементами. Число 45 выбрано не случайно, такое количество строк платформа обычно выбирает при запросах в динамических списках.
    3. Выборка из виртуальной таблицы «обороты» регистра накопления «Запасы», за выбранный период пользователю доступно ~ 22-25 тыс. записей.
    4. Аналогичная выборка из п. 3, но ограниченная первыми 45 элементами.

 Документ «Приходная накладная»

Сравнительное тестирование

Для документа настроены ограничения доступа по полям «Организация», «Контрагент», «Структурная единица».

Сравнительное тестирование

Регистр накопления «Запасы»

Сравнительное тестирование

Для регистра настроены ограничения доступа по измерениям «Организация» и «Структурная единица».

Сравнительное тестирование

Настройка доступа и подготовка баз

Для тестового пользователя были настроены ограничения по видам доступа:

  • «Организации» — доступно 1 значение, остальные запрещены.
  • «Структурные единицы» — доступно 1 значение, остальные запрещены.

Сравнительное тестирование

За основу взята демо-база, в которой были массово созданы документы типа «Приходная накладная» по организации доступной пользователю и по трем складам, доступен из которых только один. К началу эксперимента в обеих базах было порядка 100 тыс. документов, из которых пользователю с ограниченными правами доступно 35–37 тыс.

Настройки

Замеры будем производить несколькими путями:

  • замер времени выполнения кода, с помощью функции ТекущаяУниверсальная
    ДатаВМиллисекундах();
  • замер производительности «1С»;
  • технологический журнал «1С»;
  • системный монитор производительности;
  • расширенные события MS SQL — для получения планов запросов.

Настройка системного монитора производительности (performance monitor)

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

  • Processor\% Processor Time,
  • Memory\ Available Mbytes,
  • Memory\Pages/sec,
  • Physical Disk\ Avg. Disk Queue Length,
  • Physical Disk\ Avg. Disk sec transfer.

Дополнительно включим счетчики MS SQL Server для отслеживания работы с буферным кэшем:

  • Buffer manager\Page life expectancy,
  • Buffer manager\Buffer cache hit ratio,
  • Plan Cache\Plan cache hit ratio,
  • Buffer Manager\Page reads/sec,
  • Buffer Manager\Page writes/sec,
  • Buffer Manager\Lazy writes/sec.

Настройки

Настройка технологического журнала

Используем следующий файл настройки ТЖ — включен мониторинг событий CALL, SCALL, SDBL и DBMSSQL, с отбором по выбранной базе.

Настройка технологического журнала

Настройка механизма расширенных событий MSSQL

Для получения планов запросов выбираем следующее событие:

  • query_post_compilation_showplan

    На закладке «Filter» устанавливаем фильтр по имени базы:

  • database_id = <ИмяБазы>

    Внешний вид настройки лога расширенных событий:

Настройки

Результаты тестирования старого и нового механизмов RLS

Для простоты обозначим далее:

  • RLSOld — база со старой RLS.
  • RLSNew — база с новой RLS.

Замеры времени

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

Запись

Вид теста Кол-во тестов Вид RLS Cр. время одной операции (мс) Изменение в новой RLS (%)
Проведение существующей приходной накладной 300 RLSOld 967 2,38%
RLSNew 990
Создание и проведение новых приходных накладных 500 RLSOld 983 3,64%
RLSNew 1 019

Чтение

Вид теста Кол-во тестов Вид RLS Cр. время одной операции (мс) Изменение в новой RLS (%)
Запрос к таблице приходной накладной 50 RLSOld 6 133 -90,03%
RLSNew 611
Запрос к таблице приходной накладной — первые 45 5 000 RLSOld 13 -44,26%
RLSNew 7
Запрос к таблице РН Запасы.обороты 300 RLSOld 588 -51,43%
RLSNew 286
Запрос к таблице РН Запасы.обороты — первые 45 300 RLSOld 443 -65,57%
RLSNew 153

По таблице видно, что RLSNew несколько проигрывает в записи, но существенно выигрывает при чтении данных. 

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

Тест чтения — Планы запросов и системный монитор

С помощью extended events и perfmon попробуем проанализировать планы запросов и нагрузку на оборудование.

Выборка документов «Приходная накладная»

Первый тест — запрос по всем реквизитам документа «Приходная накладная»

RLSOld — длительность 6487374 мкс ~ 6,5 сек.

Выборка документов «Приходная накладная»

RLSNew — длительность 569894 мкс ~ 0,5 сек.

Выборка документов «Приходная накладная»

Как можно заметить — план запросов для RLSNew гораздо компактнее, чем RLSOld. Подробно разбирать все операторы не будем, по оценке планировщика в целом видно, что врезка RLS в прежней системе требует в несколько раз больше ресурсов чем в новой.

Обратим внимание на пару моментов, которые указывают на то, что план запроса в RLSOld не оптимален:

Выборка документов «Приходная накладная»

Выборка документов «Приходная накладная»

1. Наличие операторов Index Spool и Row Count Spool

Операторы вида Spool означают перенос части данных в tempdb на жесткий диск. Как правило это связано:

    • Либо с недостатком оперативной памяти. Это не наш случай, для SQL сервера выделено 50ГБ.
    • Либо, если планировщик «не уверен» в запросе и не смог просчитать план достаточно точно. Вероятнее всего так и есть.

2. Наличие «толстых» строк на входе у операторов Nested Loops

Как правило, планировщик запросов выбирает оператор соединения Nested Loops в ситуации, когда в обеих или одной из таблиц строк мало.

По плану видно, что планировщик ошибся в оценке. Это также указывает на то, что запрос сложен для оценки.

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

Из справки

Оператор Index Spool сканирует входные строки, помещая каждую строку в скрытый файл буфера (хранимый в базе данных tempdb и существующий только в течение выполнения запроса), и создает для строк некластеризованный индекс. Это позволяет использовать поддерживаемый индексами механизм поиска для вывода только строк, отвечающих требованиям предиката SEEK:().

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

Логический оператор Lazy Spool сохраняет все строки входных данных в скрытом временном объекте, который хранится в базе данных tempdb. Если оператор сбрасывается на начало (например, оператором Nested Loops), но при этом не требуется повторная привязка, то вместо повторного сканирования ввода используются буферизованные данные.

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

Монитор производительности

Ниже приведен лог, записанный при выполнении 50 запросов в цикле.

Cache hit ratio — показывает процент планов запроса, которые получены из кэша, чем он меньше, тем больше планов SQL Server рассчитывает заново.

Монитор производительности

Выборка документов «Приходная накладная» (первые 45 строк)

RLSOld — длительность 8705 мкс ~ 0,009 с.

Монитор производительности

RLSNew — длительность 3136 мкс ~ 0,003 с.

Монитор производительности

При ограниченном количестве строк в плане RLSNew процент времени выборки из таблицы по отношению к добавке RLS уменьшился. В плане RLSOld исчез оператор Index Spool, но Row Count Spool остался.

Монитор производительности

Из справки

Оператор Row Count Spool просматривает входные данные, подсчитывая число представленных строк и возвращая такое же количество строк, очищенных от данных. Этот оператор используется, когда необходимо проверить существование строк, а не наличие в них данных.

Например, если оператор Nested Loops выполняет операцию левого полусоединения, а предикат соединения применяется к внутренним входным данным, оператор Row Count Spool можно разместить выше внутреннего ввода оператора Nested Loops.

Тогда оператор Nested Loops может определить количество выходных строк оператора Row Count Spool (поскольку реальные данные с внутренней стороны не требуются) для определения того, нужно ли возвращать внешние строки. Оператор Row Count Spool — это физический оператор.

По счетчикам системного монитора ничего примечательного не обнаружено, за исключением времени выполнения (запрос выполнялся 5000 раз).

Монитор производительности

Выборка из регистра накопления «Запасы»

Следующий тест — запрос по всем полям виртуальной таблицы «обороты» регистра накопления «Запасы».

RLSOld — длительность 591352 мкс ~ 0,59 сек.

Выборка из регистра накопления «Запасы»

RLSNew — длительность 289880 мкс ~ 0,29 сек.

Выборка из регистра накопления «Запасы»

Обратим внимание на следующие моменты, влияющие на производительность:

  • В RLSOld присутствуют операторы Index Spool и Row Count Spool.
  • В обоих планах есть оператор Sort, однако планы построены таким образом, что в RLSOld этот оператор находится до соединения с добавкой RLS и получает на вход ~ 73 тыс. строк, в то время как в RLSNew оператор Sort расположен после соединения и получает на вход только ~ 23 тыс. строк.

Соединение и Sort в RLSOld:

Соединение и Sort в RLSOld

Соединение и Sort в RLSNew:

Соединение и Sort в RLSOld

Для записи мониторинга производительности запрос выполнялся 300 раз. По логу видно, что оба запроса активно используют диск C (на котором расположена база tempdb), при этом очередь к диску (зеленая линия) во время запроса в RLSNew значительно ниже — максимум ~ 0,5, против 6,8 для RLSOld. Это вполне коррелирует с наличием операторов вида spool в планах запросов.

Также во время выполнения вырос показатель Page writes/sec (голубая линия), для RLSOld до 3,2 тыс, для RLSNew до 2,8 тыс. При выполнении в RLSOld показатель plan cache hit ratio упал с ~ 93 до 69.

Настройки

Выборка из регистра накопления «Запасы» (первые 45 строк)

RLSOld — длительность 422972 мкс ~ 0,42 сек.

Выборка из регистра накопления «Запасы» (первые 45 строк)

RLSNew — длительность 159879 мкс ~ 0,16 сек.

Выборка из регистра накопления «Запасы» (первые 45 строк)

Планы довольно похожи на предыдущий вариант, за исключением того, что в плане RLSOld теперь нет оператора Index Spool, но оператор Row Count Spool по-прежнему присутствует.

Выборка из регистра накопления «Запасы» (первые 45 строк)

По системному монитору ситуация похожая, только нет падения Cache hit ratio, при этом есть некоторый скачок счетчика Page reads/sec в начале выполнения запросов RLSNew.

Выборка из регистра накопления «Запасы» (первые 45 строк)

Комплексный тест на запись (100 документов)

Чтобы установить причину увеличения времени RLSNew в тестах записи — запустим создание и проведение 100 документов, с одновременным включением замера «1С», ТЖ и мониторингом perfmon.

Общее время выполнения

  • RLSOld = 136456 мс ~136 с.
  • RLSNew = 150706 мс ~150 с.
  • разница 14,25 с., RLSNew больше на 10,44%

Замер производительности «1С»

При сопоставлении замеров «1С» было обнаружено, что некоторые строки RLSNew не найдены в замере RLSOld, у них есть общая черта — все они из общего модуля «УправлениеДоступом
Служебный», суммарная длительность = 6,65 сек. (что составляет 4,87% от длительности в RLSOld).

Замер производительности «1С»

Технологический журнал

Проведем анализ событий ТЖ CALL/SCALL, SDBL и DBMSSQL. Посчитаем общую длительность и количество событий. Для событий SDBL и DBMSSQL дополнительно сделаем выборки:

  • по наличию названия модуля «УправлениеДоступом
    Служебный», строки с которым мы обнаружили в замере производительности «1С»;
  • по наличию названий таблиц SQL блоков RLS старого и нового.

Полученные результаты сведены в таблицу:

Событие Тип выборки
Длительность (с)
RLSOLD RLSNew
V
CALL Общая сумма 136,65 150,82 14,17
SCALL Общая сумма 1,54 2,39 0,86
SDBL Общая сумма 338,55 369,96 31,41
УправлениеДоступом
Служебный
0,06 3,23 3,17
Таблицы блоков rls 0,02 1,10 1,08
DBMSSQL Общая сумма 58,82 60,77 1,95
УправлениеДоступом
Служебный
0,03 1,88 1,84
Таблицы блоков rls 3,67 0,94 -2,74

Обзор:

  • Замеры по событиям CALL в общем совпадают с замерами времени.
  • Суммы SDBL «зашкаливают», это может быть объяснено вложенными и параллельными событиям, в данном ключе общая сумма не показательна, но можно заметить, что событий в RLSNew больше.
  • Запросы, содержащие в себе имена таблиц блоков RLS в RLSNew суммарно выполняются на 2,74 сек. меньше, чем в RLSOld, при этом количество самих событий больше.

ВАЖНО! «Долгие SDBL»

Ряд тестов изначально был проведен на более ранней версии УНФ (1.6.20.94) с БСП (3.1.2.291). В них в замере «1С» в RLSNew в топ 10 попадала строка:

  • Если Контрагент.ВестиРасчеты
    ПоЗаказам Тогда'

При этом в замере RLSOld данная строка занимала в несколько раз меньше времени. При расследовании в ТЖ были выявлены длительные события SDBL, разница в средней длительности одного события достигала 5–6 раз.

  • RLSOld = 0,02 сек.
  • RLSNew = 0,12 сек.

Была высказана гипотеза об избыточности прав, у тестового пользователя было несколько ролей с ограничением доступа на таблице «контрагенты». После сокращения ряда ролей (оставлен необходимый минимум) замеры улучшились, однако всё равно в RLSNew средняя длительность осталась в 3 раза дольше.

  • RLSOld = 0,0047 сек.
  • RLSNew = 0,0137 сек.

После обновления УНФ на версию (1.6.21.103) с БСП (3.1.3.179) проблема больше не проявляла себя, средняя длительность стала.

  • RLSOld = 0,0044 сек.
  • RLSNew = 0,004 сек.

ВНИМАНИЕ!!! Предположительно в ранних версиях конфигураций могут быть проблемы с компоновкой запроса RLS для нового блока. При принятии решения о переходе нужно иметь это ввиду.

Системный монитор производительности

Посмотрим какое влияние на счетчики производительности оказало проведение документов в RLSOld и RLSNew.

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

  • Buffer manager:Page reads/sec (на графике зеленая линия) — при проведении документов в RLSOld показатель поднимался до значения 6,4, в RLSNew оставался на 0. К росту взаимодействия с буферным кэшем вероятнее всего также приводят неоптимальные планы запроса.
  • Avg. Disk Queue Length (E:) (фиолетовая линия) — в RLSOld очередь к диску была в пределах 2,7, в RLSNew она достигала значения 7,5. Т. к. на диске E находятся файлы обеих баз данных, рост показателя означает более интенсивную работу с данными базы на диске.
  • Plan cache:Cache hit ratio (красная линия) — наблюдается некоторое падение с 91 до 71 пункта в последней трети выполнения RLSNew.

Системный монитор производительности

Из справки

Чтений страниц/с — указывает число инициируемых за одну секунду физических операций чтения страниц базы данных. Этот статистический показатель отражает общее количество физических операций чтения страниц из всех баз данных. Физический ввод-вывод связан с большой тратой ресурсов, но иногда ее можно свести к минимуму, используя более объемный кэш данных, интеллектуальные индексы и более эффективные запросы или изменяя структуру базы данных.

Выводы

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

Можно утверждать, что использование ключей доступа в новой RLS позволяет планировщику запросов MS SQL строить более оптимальные планы, а связь по ссылке дает возможность всегда использовать кластерный индекс. Что в конечном итоге даёт значительный прирост скорости при чтении данных. В то же время новая система имеет замедление при записи, т. к. требует некоторых ресурсов для актуализации ключей доступа.

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

Важно!

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

Тему замедления открытия форм в «1С» из-за RLS мы уже поднимали ранее в статье «Неожиданная причина долгого открытия формы в «1С»». Рекомендуем её тем, кому интересна взаимосвязь общей производительности и RLS.

Авторы статьи

Станислав Борисенко
Станислав Борисенко
Дмитрий Чесноков
Дмитрий Чесноков
Андрей Черанев
Андрей Черанев
Заинтересованы в сотрудничестве?
Нужна консультация?
Свяжитесь с нами!
Для отображения персонализированного контента и рекламных сообщений, а также хранения личных настроек на локальном компьютере веб‑сайты «1С‑Рарус» используют технологию cookie и аналогичные. Продолжив использование наших веб‑сайтов, Вы даете согласие на обработку персональных данных, выражаете согласие с Политикой конфиденциальности rarus.ru и применением этих технологий.
Продолжив использование веб‑сайтов «1С‑Рарус», Вы даете согласие на обработку персональных данных, выражаете согласие с Политикой конфиденциальности.
Facebook Vkontakte Youtube Instagram Telegram