← На главную

Ситуация, когда администраторы работают в системе без задержек, а рядовые сотрудники сталкиваются с многоминутным ожиданием отчетов и интерфейса, — классический признак проблем с механизмом RLS (Record Level Security). В сложных прикладных решениях, таких как «Агропромышленный комплекс», «ERP» или «Комплексная автоматизация», этот механизм накладывает значительную нагрузку на СУБД. Проанализируем причины деградации производительности и разберем по шагам методы оптимизации системы.

Проблема 1: Ограничение доступа на уровне записей (RLS)

Когда мы ограничиваем права пользователя (например, запрещаем видеть зарплату или данные определенных подразделений), платформа 1С при каждом запросе к базе данных добавляет к тексту SQL-запроса дополнительные условия «ГДЕ...». Если условий много, и они ссылаются на сложные иерархии, SQL-сервер тратит колоссальное время на построение плана запроса и соединение таблиц. Для комплексного анализа ролей, профилей и ограничений RLS можно использовать обработку для анализа и настройки прав доступа.

Рассмотрим, как это работает в современных конфигурациях на базе БиблиотекаСтандартныхПодсистем. В системе существует два режима работы RLS: «Стандартный» и «Производительный» (с использованием расширения 1С для SQL). Проанализируем ситуацию: если ваша конфигурация использует производительный режим, 1С создает в базе данных скрытые таблицы прав доступа. Если статистика по этим таблицам не актуальна, пользователи с ограниченными правами «зависают».

Что нужно сделать:

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

Проблема 2: Регламентное обслуживание SQL Server

В тексте обращения упоминается, что «после реиндексации база летала». Это прямое указание на то, что планы запросов SQL-сервера становятся неоптимальными из-за устаревшей статистики. Для пользователей с полными правами (администраторов) запросы простые, и SQL справляется даже с плохой статистикой. Для «обрезанных» прав запросы усложняются в разы, и малейшая ошибка в статистике приводит к выбору крайне медленного плана выполнения (например, Index Scan вместо Index Seek).

Разберем по шагам настройку регламентов SQL:

1. Обновление статистики: Настроим ежедневное (или даже несколько раз в день) обновление статистики. Используем стандартную команду SQL: UPDATE STATISTICS [Имя_Таблицы] WITH FULLSCAN; Особое внимание уделим таблицам, связанным с регистрами сведений прав доступа и константами.
2. Реиндексация и дефрагментация: В условиях интенсивной работы программистов и частого обновления данных индексы фрагментируются очень быстро. Рекомендуется настроить Rebuild Index (перестроение) для тех таблиц, где фрагментация выше 30%, и Reorganize Index для остальных.

Проблема 3: Динамическое обновление конфигурации

Ситуация, когда «после небольшого обновления производительность вернулась на плохой уровень», часто связана с так называемым «динамическим обновлением» (обновление без выгона пользователей). В среде 1С это считается дурным тоном для продуктивных баз по следующим причинам:

• Происходит «раздувание» таблиц Config и ConfigSave в базе данных SQL.
• Серверный кэш 1С начинает содержать разные версии модулей, что вызывает конфликты и замедление вызовов.
• SQL-сервер сбрасывает закэшированные планы запросов, которые были оптимальными.

Рекомендация: Всегда выполняйте обновление конфигурации в монопольном режиме. После обновления крайне желательно очистить кэш сервера 1С. Разберем, как это сделать: нужно остановить службу 1С и удалить содержимое папок в профиле пользователя, под которым работает служба (обычно это C:\Users\usr1cv8\AppData\Local\1C\1cv8\ и Roaming), сохранив только файл со списком баз.

Проблема 4: Настройка электропитания и аппаратные нюансы

Проанализируем железо: процессоры Intel Xeon Silver 4210R имеют базовую частоту 2.4 GHz. Для 1С это не самый высокий показатель, так как платформа чувствительна к скорости работы одного ядра. Если в Windows Server включена схема «Сбалансированное электропитание», процессор будет постоянно снижать частоту для экономии энергии, а «просыпаться» он не успевает из-за специфики коротких транзакций 1С.

Выясним причину через настройки:

1. В операционной системе установим режим High Performance.
2. В BIOS сервера в разделе Power Management выберем Maximum Performance. Это заставит ядра процессора работать на максимальной частоте Turbo Boost постоянно.
3. Проверим использование Intel VROC. Программные RAID-массивы на SATA-дисках часто имеют большие задержки (Latency). Если очередь диска (Disk Queue Length) превышает 1-2 единицы в моменты тормозов, стоит рассмотреть переход на аппаратный RAID-контроллер с кэшем или перенос базы на NVMe-накопитель, минуя VROC.

Проблема 5: Настройка MS SQL Server 2012 для 1С

Использование SQL Server 2012 с современными версиями платформы требует специфических настроек. В частности, для борьбы с блокировками в TempDB, которые возникают при построении временных таблиц RLS, необходимо включить флаги трассировки.

Рассмотрим важные флаги:

• T1118: Отменяет выделение смешанных экстентов, что ускоряет работу с TempDB.
• T1117: Заставляет все файлы в одной файловой группе расти одновременно, предотвращая дисбаланс нагрузки.

Также проверим параметр Compatibility Level (Уровень совместимости). Для SQL 2012 он должен быть 110. Если база была перенесена со старого сервера, уровень мог остаться 100 или ниже, что мешает оптимизатору запросов работать корректно.

Проблема 6: Разделение продуктивных и тестовых сред

На одном сервере крутится 7 баз, из которых часть — огромные копии по 66 ГБ. Проанализируем нагрузку: когда программисты запускают отладку или тяжелые обработки в копиях, они забивают дисковую очередь и кэш SQL-сервера (Buffer Pool). В итоге рабочая база «вытесняется» из оперативной памяти, и SQL вынужден читать данные с медленных дисков.

Решение:

1. Вынесем все базы для разработки и старые архивные базы на отдельный физический сервер или хотя бы на отдельные диски.
2. Ограничим Max Server Memory в настройках SQL Server, чтобы он не забирал всю память у ОС и сервера 1С, но при этом обеспечим, чтобы рабочая база (12 ГБ) целиком помещалась в кэш.

Итог: План действий по шагам

1. Настроим регламенты SQL: Ежедневное обновление статистики и реиндексация ночью.
2. Оптимизируем питание: Выставим режим «Максимальная производительность» в Windows и BIOS.
3. Откажемся от динамических обновлений: Все изменения только через монопольный доступ с последующим перезапуском службы 1С.
4. Изолируем рабочую базу: Уберем лишние копии, которые создают паразитную нагрузку на диски и память.
5. Проверим RLS: Если тормоза сохраняются, попробуем на тестовой базе временно отключить RLS для проблемных пользователей. Если скорость вернется — значит, проблема в неоптимальных шаблонах прав доступа, которые дописывали программисты. В этом случае потребуется оптимизация кода в общих модулях УправлениеДоступом.

Помните, что производительность 1С — это комплексный показатель, зависящий от синергии железа, настроек СУБД и качества программного кода. Регулярный мониторинг через Центр Управления Производительностью или обычный замер производительности в конфигураторе поможет локализовать конкретную строку кода или запрос, вызывающий задержку. Для мониторинга настроек и запросов СУБД можно использовать инструмент для анализа SQL-сервера глазами 1С-специалиста.