Нужно ли разносить сервер 1С и СУБД на разные физические машины?

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

Совместное размещение против физического разделения

Для небольших и средних баз данных с числом активных пользователей до 100–150 совместное размещение сервера «1С:Предприятие» и MS SQL Server на одном физическом хосте почти всегда обеспечивает максимальную производительность. Выясним причину такого поведения архитектуры 1С:

1. Протокол Shared Memory (разделяемая память): При работе 1С и SQL Server на одном сервере обмен данными между процессами rphost и sqlservr.exe происходит напрямую через оперативную память хоста без сетевых накладных расходов. Это гарантирует практически нулевые задержки при передаче сотен тысяч мелких пакетов данных.
2. Сетевая задержка (Latency) и RTT: Архитектура платформы 1С устроена так, что даже для выполнения одной простой транзакции (например, проведения типового документа реализации в «1С:Управление торговлей») сервер приложений формирует множество последовательных коротких запросов к СУБД. При разнесении серверов по разным хостам даже при пропускной способности сети 1 Гбит/с или 10 Гбит/с решающую роль играет сетевая задержка (RTT — Round Trip Time). Если задержка составляет 0.5–1 мс, суммарное время ожидания ответов от СУБД драматически увеличивает общее время проведения документа.
3. Ограничения масштабирования: Разнесение серверов 1С и СУБД на разные машины оправдано только тогда, когда суммарная нагрузка превышает вычислительные возможности одного хоста (от 150–200 активных пользователей, тяжелые регламентные операции и фоновые расчеты), либо когда требуется балансировка нагрузки в рамках многосерверного кластера 1С.

Настройка оперативной памяти при совместном размещении

Распространенное опасение заключается в том, что MS SQL Server может занять всю доступную оперативную память хоста и вызвать дефицит ресурсов для процессов сервера 1С (ragent, rmngr, rphost). Проанализируем, как правильно распределить память:

1. Ограничение параметра max server memory: По умолчанию MS SQL Server динамически захватывает доступную память для своего буферного пула. Необходимо жестко зафиксировать верхний предел памяти для экземпляра SQL Server. Например, при общем объеме ОЗУ 64 Гб разумно выделить: под СУБД — 36–40 Гб, под операционную систему — 4–6 Гб, под процессы сервера 1С — 18–24 Гб.
2. Привилегия Lock Pages in Memory: Для учетной записи, под которой запущена служба СУБД, необходимо предоставить привилегию «Блокировка страниц в памяти» (Lock Pages in Memory). Это предотвратит принудительный сброс буферного пула SQL Server в файл подкачки Windows при резких всплесках потребления памяти процессами 1С.
3. Перезапуск рабочих процессов 1С: В консоли администрирования кластера 1С настраиваются параметры допустимого объема памяти на рабочий процесс и интервалы перезапуска. Это защищает систему от деградации из-за утечек памяти в неоптимизированном прикладном коде.

Оптимизация параметров MS SQL Server для платформы 1С

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

1. Параметр MAXDOP (Max Degree of Parallelism): Для баз 1С на MS SQL Server критически важно выставлять параметр Max Degree of Parallelism = 1 (или ограничивать до 2 при параллельных пакетных операциях). Неконтролируемое распараллеливание запросов СУБД в 1С часто приводит к самоблокировкам потоков и падению общей производительности (ожидания типа CXPACKET).
2. Мгновенная инициализация файлов (Instant File Initialization): Службе SQL Server необходимо предоставить право «Выполнение задач по обслуживанию томов» (Perform Volume Maintenance Tasks). Это позволяет СУБД мгновенно расширять файлы данных .mdf и моментально разворачивать бэкапы без предварительного заполнения дискового пространства нулями.
3. Настройка базы tempdb: База данных tempdb активно используется платформой 1С для работы с временными таблицами. Рекомендуется разделить tempdb на несколько файлов данных одинакового размера (по числу физических ядер, но не более 8) и разместить их на максимально быстром твердотельном накопителе.
4. Отключение Auto-Shrink: Автоматическое сжатие баз данных должно быть строго отключено, так как постоянное сжатие и последующий рост файлов вызывают предельную фрагментацию индексов и парализуют дисковую подсистему.

Требования к оборудованию, процессору и дисковой подсистеме

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

1. Частота процессора на одно ядро: Большинство ключевых операций в 1С (проведение документов, закрытие месяца, расчет себестоимости) выполняются в один поток. Для 1С критически важна высокая тактовая частота процессора (от 3.5–4.0 ГГц и выше) и высокая производительность на одно ядро, а не общее количество ядер с низкой частотой.
2. Планы электропитания: В BIOS/UEFI материнской платы и в операционной системе обязательно устанавливается схема питания «Высокая производительность» (High Performance). Динамическое управление частотой ядер и режимы энергосбережения вызывают микрозадержки при пробуждении ядер, что существенно замедляет проведение документов.
3. Конфигурация дисков: Использование классических HDD для рабочих баз 1С недопустимо из-за низкого показателя IOPS и высоких задержек поиска. Оптимальная схема включает использование надежных NVMe/SATA SSD под базу данных и tempdb, а также выделенный HDD или сетевое хранилище под создание полных и дифференциальных резервных копий.

Особенности виртуализации серверов 1С

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

1. Учет NUMA-архитектуры: Виртуальная машина с сервером 1С или СУБД не должна выходить за пределы одного физического NUMA-узла процессора. Количество выделенных vCPU не должно превышать число физических ядер одного сокета, чтобы исключить медленные межсокетные обращения к оперативной памяти.
2. Резервирование ресурсов (Memory Reservation): Для виртуальных машин с 1С и SQL Server необходимо включать 100% резервирование физической памяти, чтобы гипервизор не использовал механизмы динамического перераспределения памяти (Dynamic Memory, Memory Ballooning) или файлы подкачки гипервизора.
3. Разделение на две ВМ в рамках одного хоста: Разделять сервер 1С и SQL Server на две отдельные виртуальные машины на одном и том же физическом сервере не рекомендуется. Это лишает систему преимуществ Shared Memory и добавляет виртуальный сетевой стек, снижая общую производительность.