← На главную

При проектировании серверной инфраструктуры для конфигурации 1С:Управление торговлей 11 (УТ 11) системные администраторы и разработчики часто сталкиваются с дилеммой: как сбалансировать бюджет и обеспечить высокий запас производительности при наличии 50–100 активных пользователей, включенных механизмах RLS и интенсивном обмене данными. Разберем практический опыт внедрения, архитектурные нюансы подбора железа и программные методы решения узких мест производительности.

Анализ требований и выбор аппаратной конфигурации

Рассмотрим типовой сценарий: совмещенный сервер 1С и MS SQL Server, на котором работает база УТ 11 объемом от 35 до 50 Гб с 50–130 пользователями (из них 30–50 постоянно активных). В системе ведется интенсивный документооборот (более 1000 документов в день), настроены обмены с бухгалтерией и внешними сайтами, а также включено разграничение прав доступа RLS по организациям, складам, партнерам и ценам.

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

1. Процессор (CPU): Для систем 1С решающее значение имеет высокая тактовая частота на одно ядро (от 3.2–3.6 GHz в бусте). Отличным выбором являются процессоры линейки Intel Xeon E5-2667 v3/v4 или их современные аналоги. Решающую роль играют гигагерцы, а не просто количество ядер.
2. Оперативная память (RAM): Объем 96–128 Гб DDR4 с высокой частотой. Это позволит выделить достаточный объем памяти для кэша SQL Server и рабочих процессов сервера 1С (rphost).
3. Подсистема хранения данных (SSD/HDD): Скорость работы базы 1С напрямую зависит от дисковой подсистемы.

Организация дискового массива и минимизация рисков

Разберем детально, как распределить файлы базы данных и операционной системы по дискам для достижения максимального быстродействия:

1. Основная база данных (файлы mdf): Использование высокоскоростных NVMe SSD дисков enterprise-уровня (например, Intel DC серия P3700/P3710 с подключением PCIe). Для SSD дисков случайная запись и чтение происходят одинаково быстро.
2. Журнал транзакций (файлы ldf): Можно размещать на одном SSD-массиве с файлом данных или выносить на отдельный SSD. Для защиты от потерь данных настраивается логирование транзакций с бэкапом каждые 15 минут. В таком случае максимальная возможная потеря данных при сбое одиночного SSD составит не более 15 минут работы.
3. База TempDB и временные файлы: Файлы временной базы tempdb СУБД, временные файлы ОС Windows и каталоги рабочих процессов 1С (кэш юзеров и сервера) рекомендуется выносить на отдельный быстрый SSD-диск или массив. Это предотвращает взаимную блокировку ввода-вывода.
4. Резервные копии и ОС: Под операционную систему выделим надежный RAID 1 или RAID 10 из классических SAS/SATA дисков. Для хранения полных ночных бэкапов SQL достаточно использовать объемные HDD диски (например, WD Red 5400rpm в RAID 1).

Настройка BIOS и операционной системы: устранение просадок CPU

Часто после запуска сервера показатели синтетических тестов (например, теста Гилёва) оказывается ниже ожидаемых (около 20–23 баллов вместо 45–50). Одной из главных причин является динамическое сбросовое управление частотой процессора на аппаратном уровне.

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

1. Отключение C-States в BIOS: Переведем параметры энергосбережения процессора в BIOS (параметры C-States, C1E, C3, C6) в режим Disabled. Установим профиль управления питания материнской платы (Power Management) в положение Maximum Performance.
2. Настройка электропитания в ОС: В Windows Server выставим схему электропитания «Высокая производительность» (High Performance). Это предотвратит "проседание" частоты ядер процессора в моменты простоя и устранит задержки при резких всплесках нагрузки.
3. Отключение парковки ядер: Убедимся, что режим парковки ядер (Core Parking) выключен, чтобы все физические ядра были готовы к обработке потоков rphost и sqlservr без задержек.

Влияние RLS (граничение доступа на уровне записей) на скорость работы

Включение RLS по организациям, кассам, складам и особенно по группам доступа партнеров создаёт колоссальную нагрузку на СУБД. При классическом режиме RLS условия прав динамически дописываются в каждый SQL-запрос в виде сложных подзапросов, что замедляет проведение документов и работу форм списков.

Рассмотрим способы минимизации влияния RLS:

1. Переход на производительный режим RLS: В современных версиях 1С:Управление торговлей используется механизмы ключей доступа. Права рассчитываются фоновыми заданиями и записываются в специальные регистры сведений. В запросах выполняется простое соединение по ключам доступа, что экономит ресурсы процессора.
2. Регламент расчета ключей доступа: Задания обновления ключей доступа должны быть вынесены на нерабочее время, чтобы избежать транзакционных блокировок в пиковые часы.
3. Анализ и оптимизация запросов: Как показывает практика, сам по себе RLS при проведении документов дает от 5% до 15% задержки. Основная потеря скорости часто кроется в некорректных запросах типовых или доработанных механизмов (например, при формировании печатных форм, ТТН или отчетов). Посредством замера производительности и оптимизации запросов удается ускорить работу системы без отмены RLS.

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

Механизм дополнительных реквизитов и сведений в УТ 11 построен по модели EAV (Entity-Attribute-Value). Вывод дополнительных реквизитов в формы списков и отчеты заставляет SQL Server вызывать левые соединения с табличными частями. Если вынести такой реквизит в журнал документов и включить сортировку по нему, открытие формы списка может занять до 2 минут.

Разберем пути решения этой проблемы:

1. Отказ от доп. реквизитов в пользу реальных полей: Если параметр критичен для быстрых отборов и отчетов, целесообразно добавить реальный реквизит прямо в объект метаданных (через механизм расширений конфигурации). Это позволит SQL Server использовать стандартные индексы.
2. Индексация дополнительных реквизитов: Для свойств, которые должны остаться в рамках БСП, следует установить флаг индексации в настройках самого дополнительного реквизита.
3. Оптимизация динамических списков: Для журналов документов (Заказы клиентов, Реализации товаров и услуг) установите жесткое ограничение периода по умолчанию. Отключите использование новомодных общих реестров документов, если они замедляют работу, и вернитесь к стандартным журналам.

Тонкая настройка MS SQL Server и 1С

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

1. Память SQL Server: Зафиксируем максимальный объем памяти (Max Server Memory) для MS SQL Server, оставив не менее 16–24 Гб оперативной памяти под службы 1С (rphost, rmngr) и нужды ОС.
2. Настройка Lock Pages in Memory (LPIM): Назначим учетной записи службы SQL Server право закрепления страниц в памяти в локальных политиках безопасности Windows, чтобы предотвратить сброс кэша SQL в файл подкачки.
3. Настройка TempDB: База данных tempdb должна содержать количество файлов данных, равное числу физических ядер процессора (но не более 8 файлов), с одинаковым начальным размером и фиксированным шагом авторасширения. Файлы размещаются на самом быстром SSD.
4. Параметры параллелизма: Установим параметр Max Degree of Parallelism (MAXDOP) в значение 1 или 2, а Cost Threshold for Parallelism поднимем до 50, чтобы предотвратить затраты ресурсов на построение неэффективных параллельных планов выполнения запросов 1С.

Таким образом, даже при наличии жестких ограничений бюджета и включенного RLS, грамотная настройка электропитания CPU, вынос временных файлов на SSD, оптимизация доп. реквизитов и тонкая настройка СУБД позволяют получить высокую скорость работы системы для 50–100 пользователей.