Почему физический сервер 1С работает медленнее виртуального в облаке и как правильно собрать производительное железо для УПП

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

При переносе высоконагруженных баз данных 1С:УПП из облачной инфраструктуры (например, Яндекс Облака) на собственное физическое оборудование системные администраторы часто сталкиваются с парадоксальной ситуацией. Физический сервер, купленный за внушительную сумму, показывает производительность в тестах и реальной работе в 1.5–2 раза ниже, чем арендованная виртуальная машина. Пользователи начинают жаловаться на задержки при проведении документов, а регламентные операции и расчет себестоимости выполняются значительно дольше.

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

В чем кроется секрет скорости Яндекс Облака: архитектура процессоров и IPC

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

Проанализируем пример конфигурации, упомянутой в обсуждении: сервер на базе процессора Intel Xeon E5-1650v3 с частотой 3.5 ГГц показал производительность в два раза ниже, чем виртуальная машина в облаке. Выясним причину этой проблемы:

  1. Поколение архитектуры и показатель IPC (Instructions Per Cycle): Процессор Xeon E5-1650v3 относится к микроархитектуре Haswell (выпуск 2014 года). Несмотря на высокую номинальную частоту 3.5 ГГц, его вычислительная мощность на один такт (IPC) безнадежно устарела. Современный процессор при той же тактовой частоте выполняет в 2–2.5 раза больше инструкций за один такт.
  2. Современные облачные платформы: Крупные облачные провайдеры используют в своих Compute-Optimized линейках новейшие процессоры (например, Intel Xeon Ice Lake или AMD EPYC Zen 4 серии F) с высокой базовой частотой (до 3.8–4.0 ГГц) и огромным объемом кэш-памяти L3. Один vCPU в таком облаке на аппаратном уровне работает в разы эффективнее, чем ядро физического процессора десятилетней давности.

Ошибка при покупке «топового» сервера: ядра против частоты

Часто для 1С приобретают классические двухпроцессорные серверы (например, на базе двух Intel Xeon Silver или Gold по 16–24 ядра в каждом). Стоимость такого оборудования может превышать 400 000 рублей, но производительность в 1С оказывается крайне низкой. Почему так происходит?

Серверные процессоры общего назначения проектируются под задачи виртуализации, веб-сервисы и СУБД с высокой параллельной нагрузкой. Их главная задача — утилизировать как можно больше потоков одновременно. Для этого производители вынуждены снижать тактовую частоту каждого отдельного ядра (обычно до 2.0–2.4 ГГц) и укладывать процессор в жесткие рамки тепловыделения (TDP). Для платформы 1С такой процессор — худший выбор. Ей не нужны 48 медленных ядер, ей требуются 4–8 ядер, но с максимально возможной частотой (желательно от 4.0 ГГц и выше).

Именно поэтому домашние или полупрофессиональные десктопные процессоры (такие как Intel Core i9 или AMD Ryzen 9) в тестах производительности Гилёва показывают феноменальные результаты (свыше 60–80 попугаев), обгоняя тяжелые серверные платформы за миллионы рублей.

Дисковая подсистема: почему SATA SSD RAID-1 больше не тянет

Вторым критическим узким местом при переносе баз данных является дисковая подсистема. На примере конфигурации из Hetzner мы видим использование накопителей SATA SSD в RAID-1. Рассмотрим, почему это ограничивает производительность высоконагруженной 1С:УПП:

В облачных инфраструктурах дисковая подсистема организована на базе сетевых или локальных NVMe-накопителей с поддержкой огромного пула IOPS и минимальной латентностью (менее 1 мс). Чтобы достичь аналогичного уровня производительности на физическом сервере, необходимо использовать исключительно корпоративные PCIe NVMe SSD (например, серии Intel/D單, Samsung PM или Kioxia) и полностью отказаться от интерфейсов SATA/SAS для рабочих баз данных.

Настройка электропитания — «скрытый убийца» производительности железа

Физические серверы поставляются с завода с включенными функциями энергосбережения в BIOS. Это делается для соответствия экологическим стандартам и снижения затрат на охлаждение ЦОД. Процессор динамически снижает свою частоту и отключает неиспользуемые блоки ядер, переходя в так называемые C-states (состояния глубокого сна).

Специфика работы 1С заключается в импульсной нагрузке: пользователь нажимает кнопку «Провести», сервер получает мгновенный тяжелый запрос, который нужно обработать за доли секунды, и снова переходит в режим ожидания. Если в BIOS включено энергосбережение, процессор просто физически не успевает «проснуться», поднять частоту ядра до максимума (Turbo Boost) и выполнить операцию. В результате система постоянно работает на пониженной частоте (например, 1.2 ГГц вместо 4.0 ГГц), из-за чего возникают микролаги.

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

Пошаговая инструкция по настройке и оптимизации физического сервера под 1С

Рассмотрим комплекс мер, которые необходимо выполнить при развертывании СУБД и сервера приложений 1С на собственном физическом сервере.

Шаг 1. Настройка BIOS физического сервера

Перед установкой операционной системы обязательно зайдите в настройки BIOS/UEFI сервера и измените следующие параметры:

  1. Переведите профиль электропитания (System Profile / Power Management) в режим Maximum Performance (Максимальная производительность).
  2. Отключите технологии энергосбережения процессора: C-States, C1E, Intel SpeedStep (EIST), AMD Cool'n'Quiet.
  3. Включите технологию динамического разгона: Intel Turbo Boost или AMD Turbo Core.
  4. Включите режим постоянной активности ядер (отключение парковки ядер процессора).

Шаг 2. Настройка схемы электропитания в ОС

В операционной системе Windows Server по умолчанию может быть установлен сбалансированный режим. Перейдите в «Панель управления» -> «Электропитание» и выберите схему «Высокая производительность» (High Performance) или «Максимальная производительность» (Ultimate Performance).

Для операционных систем семейства Linux (если сервер приложений или СУБД развернуты на них) необходимо настроить регулятор частоты процессора (CPU Governor). Выполните в терминале команду:


cpupower frequency-set -g performance

Шаг 3. Оптимизация дисковой подсистемы под TempDB и логи транзакций

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

Для MS SQL Server настройте оптимальное количество файлов базы данных tempdb. Количество файлов должно быть равно числу логических ядер процессора (но не более 8, если ядер больше). Это позволит избежать внутренней конкуренции за страницы распределения в СУБД. Настройку можно выполнить через среду СУБД SQL Server Management Studio или с помощью скрипта:


ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, SIZE = 1024MB, FILEGROWTH = 256MB);
-- Повторить добавление файлов tempdev2, tempdev3 и т.д. в зависимости от количества ядер процессора
ALTER DATABASE tempdb ADD FILE (NAME = tempdev2, FILENAME = 'T:\TempDB\tempdev2.ndf', SIZE = 1024MB, FILEGROWTH = 256MB);

Шаг 4. Настройка протокола Shared Memory (Общая память)

Если сервер приложений 1С и сервер СУБД (MS SQL Server) работают на одном физическом сервере, их сетевое взаимодействие по умолчанию может идти через протокол TCP/IP, что вызывает задержки на уровне сетевого стека ОС. Включим обмен данными напрямую через оперативную память:

  1. Откройте SQL Server Configuration Manager.
  2. Перейдите в раздел SQL Server Network Configuration -> Protocols for MSSQLSERVER.
  3. Убедитесь, что протокол Shared Memory находится в состоянии Enabled.
  4. В свойствах подключения в кластере 1С при указании имени сервера СУБД используйте локальное имя сервера или точку (.), либо явно укажите протокол в строке подключения СУБД: lpc:ИмяСервера.

Проверить текущие активные подключения к MS SQL Server и используемые ими протоколы можно с помощью следующего запроса:


SELECT session_id, net_transport, client_net_address 
FROM sys.dm_exec_connections;

В выводе для локальных подключений сервера приложений 1С в колонке net_transport должно быть указано значение Shared memory.

Шаг 5. Тонкая настройка параллелизма в MS SQL Server (MAXDOP)

По умолчанию MS SQL Server пытается распараллелить тяжелые запросы на все доступные ядра процессора. В 1С это часто приводит к взаимным блокировкам (Deadlocks) и общему снижению производительности из-за накладных расходов на сборку параллельных потоков.

Рекомендуется ограничить максимальную степень параллелизма (MAXDOP). Для баз данных 1С оптимальным значением является 1 (полный запрет параллелизма для запросов) или значение 2 (для очень тяжелых отчетов при наличии свободных ядер процессора). Изменим эти параметры через T-SQL:


EXEC sys.sp_configure N'show advanced options', N'1' RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'max degree of parallelism', N'1'
GO
EXEC sys.sp_configure N'cost threshold for parallelism', N'50'
GO
RECONFIGURE WITH OVERRIDE
GO

Резюме по выбору комплектующих для нового физического сервера

Если вы приняли окончательное решение съехать с облака Яндекс и собрать собственный сервер для высоконагруженной 1С:УПП на 20 пользователей с активными обменами роботов, придерживайтесь следующих правил подбора оборудования:

← На главную