Как выбрать и настроить сервер для 1С:Управление торговлей 11 на 50 активных пользователей

Системный администратор 1С v8.3 (Управляемые формы) 1С:Управление торговлей IT и автоматизация бизнеса
← На главную

Развертывание производительного серверного комплекса для конфигурации уровня «1С:Управление торговлей 11» при 50 одновременно работающих пользователях требует комплексного учета аппаратных характеристик, профиля транзакционной нагрузки и специфики взаимодействия кластера 1С с СУБД. Разберем по шагам ключевые критерии выбора комплектующих, архитектурные решения и правила тонкой настройки системы для обеспечения максимального комфорта пользователей.

Архитектурный подход и разделение нагрузки

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

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

Если вся нагрузка концентрируется на одном физическом сервере, совмещенное размещение кластера 1С и Microsoft SQL Server на одном хосте дает преимущество за счет использования протокола Shared Memory. Это исключает сетевые задержки при обмене между сервером приложений и СУБД. При разделении ролей на два физических узла критически важно обеспечить задержку сети между ними на уровне менее 0.5 мс и пропускную способность сетевых адаптеров не ниже 10 Gbps.

Требования к процессору (CPU)

Платформа «1С:Предприятие 8» критически чувствительна к однопоточной производительности (Single Core Performance). Операции проведения документов, расчет себестоимости и контроль блокировок выполняются в один поток, поэтому ключевым показателем является не суммарное количество ядер, а их тактовая частота.

  1. Выбираем серверные процессоры с базовой тактовой частотой от 3.5 ГГц и возможностью динамического разгона (Turbo Boost) до 4.0 ГГц и выше.
  2. В BIOS/UEFI сервера обязательно отключаем все профили энергосбережения (C-States, SpeedStep, EIST) и принудительно переводим систему в режим максимальной производительности (High Performance). Динамическое изменение частоты процессорных ядер на лету приводит к микрозадержкам при блокировочных транзакциях.

Подбор дисковой подсистемы и ресурс накопителей

Дисковая подсистема является главным узким местом при работе 50 активных пользователей в тяжелой базе. Использование традиционных жестких дисков (HDD) или медленных SATA SSD недопустимо. Выясним причину: интенсивная запись журналов транзакций и работа с временными таблицами создают огромный поток случайных операций ввода-вывода (IOPS).

  1. Интерфейс накопителей: ориентируемся на высокоскоростные твердотельные накопители с интерфейсом NVMe (форм-факторы U.2 или PCIe-платы). Они обеспечивают прямую связь с шиной PCI Express без ограничений устаревшего протокола AHCI.
  2. Параметр износостойкости (DWPD): критически важный фактор надежности. Пользовательские SSD и серверные модели начального уровня (категория Read-Intensive с DWPD < 0.8) быстро исчерпывают ресурс ячеек памяти из-за непрерывной перезаписи логов СУБД. Для промышленной эксплуатации 1С выбираем накопители классов Mixed-Use или Write-Intensive с показателем DWPD от 1 до 3 (то есть накопитель гарантированно выдерживает перезапись своего полного объема от 1 до 3 раз в сутки на протяжении гарантийного срока).
  3. Организация дисковых очередей: разделяем дисковые массивы по функциональному назначению. Оптимально изолировать операционную систему с кластером 1С, основные файлы данных СУБД (.mdf), журнал транзакций (.ldf) и системную базу TempDB. Для журнала транзакций первостепенно время отклика на последовательную запись, а для TempDB — скорость случайного чтения и записи.

Расчет оперативной памяти (RAM)

Для базы из 50 пользователей необходим объем оперативной памяти от 64 до 128 ГБ. Рассмотрим подробнее распределение ресурсов памяти:

  1. Операционная система: резервируем 8–16 ГБ для нужд ОС и системного дискового кэша.
  2. Кластер серверов 1С: исходим из эмпирического правила выделения от 1 до 2 ГБ RAM на одну активную пользовательскую сессию под управлением рабочих процессов rphost. Для 50 пользователей кластеру требуется от 50 до 80 ГБ оперативной памяти. Обязательно используем исключительно 64-разрядный сервер «1С:Предприятие», так как 32-разрядная служба ограничена адресным пространством в 4 ГБ на процесс и аварийно завершает работу при формировании крупных отчетов.
  3. СУБД: оставшийся объем выделяется под кэш буферного пула СУБД.

Тонкая настройка СУБД и кластера 1С

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

  1. Ограничение памяти СУБД (Max Server Memory): в свойствах экземпляра Microsoft SQL Server принудительно ограничиваем максимальный объем потребляемой памяти, чтобы СУБД не вытеснила из RAM рабочие процессы кластера 1С.
  2. Настройка базы TempDB: создаем число файлов данных TempDB, равное количеству физических процессорных ядер сервера (до 8 файлов). Всем файлам задаем одинаковый начальный размер и фиксированный шаг авторасширения в мегабайтах (отключение авторасширения в процентах).
  3. Быстрая инициализация файлов (Instant File Initialization): учетной записи службы СУБД назначаем право Windows «Выполнение задач по обслуживанию томов» (Perform volume maintenance tasks), что исключает зависание системы при расширении файлов данных.
  4. Параллелизм: для Microsoft SQL Server задаем параметр Max Degree of Parallelism (MAXDOP) равным 1, чтобы предотвратить взаимоблокировки параллельных потоков при выполнении типовых транзакций 1С, а порог запуска параллельных планов (Cost Threshold for Parallelism) поднимаем до 40–50.
  5. Параметры кластера 1С: для 50 пользователей в консоли администрирования кластера создаем 2–3 рабочих процесса rphost. Включаем плановый перезапуск рабочих процессов по расписанию или по достижению лимита памяти для нейтрализации фрагментации адресного пространства.
← На главную