После активации механизма RLS (Row-Level Security) в системе 1С многие пользователи сталкиваются с существенным замедлением работы. Это распространенная проблема, и мы с вами разберем, почему она возникает и как ее эффективно решить.
Суть проблемы заключается в том, что RLS добавляет дополнительные условия ограничения к каждому запросу, усложняя их выполнение на уровне СУБД. Представьте, что к каждому запросу теперь прилагается целый "список разрешений", который нужно проверить. Если пользователь имеет доступ к одной и той же таблице через несколько ролей, оптимизатор запросов СУБД может столкнуться с трудностями при их эффективной обработке, что значительно увеличивает время получения данных. Шаблоны RLS, особенно сложные, могут приводить к формированию большого количества соединений между таблицами (иногда сотни или даже тысячи), что часто вызывает неверные планы запросов и неэффективное использование индексов.
Давайте вместе проанализируем ситуацию и выясним причины замедления, а затем рассмотрим подробные шаги по их устранению.
Решение проблемы замедления работы 1С после включения RLS требует комплексного подхода. Нам предстоит рассмотреть как аппаратные аспекты, так и тонкости настройки программного обеспечения, включая саму СУБД и механизмы RLS в 1С. Мы разберем каждое направление по шагам.
Начнем с аппаратной части, поскольку без адекватного "железа" все программные оптимизации могут оказаться недостаточными. Мы часто видим, что пользователи для 30+ человек используют устаревшие или недостаточно мощные серверы. Это одна из ключевых причин проблем с производительностью.
Процессор (CPU): Производительность системы 1С, особенно при обработке сложных запросов и в конфигурациях, работающих в однопоточном режиме, крайне сильно зависит от быстродействия одного ядра процессора. Не стоит гнаться за большим количеством ядер с низкой тактовой частотой.
Оперативная память (RAM): Достаточный объем оперативной памяти критичен для работы СУБД и сервера 1С. Для 30+ пользователей мы рекомендуем начинать с 64 ГБ ОЗУ. Для более крупных систем (70-100 пользователей) может потребоваться 96–128 ГБ и более.
Дисковая подсистема: Скорость работы дисковой подсистемы напрямую влияет на производительность базы данных. Мы настоятельно рекомендуем размещать СУБД и саму базу данных на разных физических дисках. Обязательно используйте SSD-накопители, так как они значительно повышают скорость чтения/записи данных.
Если в качестве СУБД используется PostgreSQL, его стандартные настройки часто не являются оптимальными для работы с 1С. Нам предстоит провести тщательную настройку.
Выбор операционной системы: Мы выяснили, что PostgreSQL на Linux, как правило, демонстрирует лучшую производительность по сравнению с Windows при работе с 1С. Некоторые пользователи сталкивались с "невероятными тормозами" при использовании связки 1С 8.3 + PostgreSQL на Windows с включённым RLS. Современные версии платформы 1С полностью поддерживают работу как серверной, так и клиентской части в Linux, поэтому рассмотрите возможность перехода на эту ОС.
Оптимизация файла `postgresql.conf`: Давайте внимательно изучим и настроим ключевые параметры этого файла.
max_connections: Этот параметр определяет максимальное количество одновременных подключений к базе данных. 1С рекомендует устанавливать от 500 до 1000 соединений.shared_buffers: Объем памяти, выделяемый для кеша данных PostgreSQL. Рекомендуем выделять около 1/4 от общего объема оперативной памяти сервера.work_mem: Лимит памяти для обработки одного запроса. Это индивидуальное значение для каждой сессии. Рекомендуется устанавливать, рассчитывая по формуле RAM/32..64 или из диапазона 32MB..128MB.maintenance_work_mem: Лимит памяти для обслуживающих задач (сбор статистики, сборка мусора, создание индексов). Мы рекомендуем указывать либо по формуле RAM/16..32, либо значение work_mem * 4, либо из диапазона 256MB..4GB.fsync: Отключение этого параметра может повысить производительность операций записи на диск, но требует обязательного использования многодисковых RAID-массивов с кэширующими RAID-контроллерами и источником бесперебойного питания (ИБП) для обеспечения консистентности данных. Будьте крайне осторожны с этим параметром!effective_cache_size: Мы рекомендуем увеличить значение этого параметра, чтобы PostgreSQL более эффективно использовал системный кеш оперативной памяти.Особенности параллельного выполнения запросов: В отличие от MS SQL, PostgreSQL исторически не умеет распараллеливать выполнение одного запроса на несколько ядер процессора. Это может стать узким местом для тяжёлых запросов, даже при наличии мощного многоядерного CPU. Этот факт следует учитывать при проектировании и оптимизации запросов.
Теперь перейдем к оптимизации самого механизма RLS в конфигурации 1С. Здесь есть несколько ключевых подходов.
Производительный режим RLS: Это наиболее рекомендуемый способ оптимизации RLS, особенно для больших объемов данных и сложной системы разграничения прав. Давайте разберем его подробнее.
Избегаем сортировки по полям с RLS-ограничением: Мы часто видим, что списки сортируются по полям, которые находятся под контролем RLS. Например, список заказов, который по умолчанию никак не менялся в коде, может быть отсортирован по такому полю.
Оптимизация шаблонов RLS: Мы рекомендуем тщательно прорабатывать шаблоны RLS, чтобы они были максимально простыми и не приводили к избыточным соединениям. Чем проще шаблон, тем быстрее СУБД сможет его обработать.
"Лакс" ограничение для справочников (WHERE ИСТИНА): Существует так называемый "лайфхак", который может помочь в некоторых случаях ускорить сортировку по представлению для справочников, ограниченных RLS.
ГДЕ ИСТИНА на поля, используемые для представления (например, Ссылка, Наименование). Это может выглядеть как дополнительная строка в шаблоне RLS. Тогда сортировка по представлению снова будет работать быстро.
#Если &ОграничениеПоОрганизациям
ОБЪЕКТ.Организация В (&ДоступныеОрганизации)
#КонецЕсли
ИЛИ
(ИСТИНА ГДЕ ОБЪЕКТ.Ссылка ЕСТЬ NULL) // Дополнительное условие для ускорения сортировки по представлению
В этом примере второе условие (ИСТИНА ГДЕ ОБЪЕКТ.Ссылка ЕСТЬ NULL) является "лаксом" ограничением, которое может быть оптимизировано СУБД. Однако, будьте крайне осторожны!
ПометкаУдаления. В динамических списках и подборах по строке это уже по дефолту есть, но речь идет о других местах, где может запрашиваться только наименование или только ссылка. Мы должны убедиться, что пользователь не получит доступ к данным, к которым он не должен иметь доступ, даже если это ускоряет работу.Для поддержания стабильной производительности и своевременного выявления проблем мы рекомендуем следующее:
Мониторинг: Регулярно отслеживайте состояние системы прав доступа и историю их выдачи. Используйте средства технологического журнала 1С для анализа производительности запросов.
Аудит: Проведение технологического аудита производительности 1С может помочь выявить узкие места и предложить конкретные решения, адаптированные под вашу уникальную конфигурацию и нагрузку.
Применяя эти рекомендации, мы сможем значительно улучшить производительность вашей системы 1С после включения RLS и обеспечить комфортную работу для всех пользователей.
← К списку