При переходе на тяжелые конфигурации, такие как 1С:ERP Управление предприятием, правильный подбор серверного оборудования определяет успех всего проекта внедрения. Нагрузка в 250 одновременных сессий при общем количестве в 1100 пользователей является серьезным испытанием для ИТ-инфраструктуры. В этой статье мы подробно проанализируем предложенную конфигурацию на базе серверов Dell PowerEdge R640, выявим скрытые аппаратные «бутылочные горлышки», исправим критические ошибки проектирования и определим оптимальную архитектуру для стабильной работы системы.
Рассмотрим спецификацию сервера, предложенную к развертыванию (планируется приобретение двух таких физических машин: под сервер приложений «1С» и под сервер СУБД):
На первый взгляд, конфигурация выглядит солидно. Однако при детальном рассмотрении под нагрузкой «1С:ERP» эта спецификация имеет несколько критических уязвимостей, способных парализовать работу пользователей. Разберем их по очереди.
Выбор контроллера PERC H330 — это главная системная ошибка данной конфигурации. Этот контроллер относится к решениям начального уровня (Entry-level) и имеет одну фатальную особенность: у него полностью отсутствует аппаратный кэш записи, а также модуль защиты кэша (батарейка или суперконденсатор).
Рассмотрим, к чему это приводит на практике:
Write-Through (прямая запись). Контроллер не сможет подтвердить операцию операционной системе до тех пор, пока физические ячейки памяти SSD не завершат цикл записи.Как исправить: Необходимо полностью исключить контроллер H330. Вместо него следует установить полноценный RAID-контроллер с аппаратным энергонезависимым кэшем, например, PERC H730P (2 ГБ кэша) или PERC H740P (8 ГБ кэша) с модулем защиты кэша. Еще более прогрессивное решение — полностью отказаться от классических SAS-контроллеров в пользу современных накопителей NVMe SSD, которые подключаются напрямую к шине PCIe, минуя узкое горлышко RAID-контроллера.
Накопители Samsung PM1633a емкостью 480 Гб разработаны достаточно давно (середина 2010-х годов). По современным меркам их скорость произвольной записи в 32-37k IOPS является крайне низкой.
Второй аспект — критически малый объем. Три диска по 480 Гб дадут нам в зеркальном массиве (RAID 1 + Hot Spare) или в RAID 5 всего около 900 Гб полезного пространства. Проанализируем, как распределится это место на сервере СУБД:
tempdb (которая в ERP активно используется для хранения временных таблиц при расчете себестоимости, проведении партионного учета и формировании отчетов) требует значительного быстрого пространства — не менее 100–150 ГБ.Как исправить: Рассмотрите современные твердотельные накопители класса Mixed Use NVMe SSD (например, серии Samsung PM9A3 или PM1733) объемом не менее 960 Гб или 1.92 Тб. Отличным решением будет физическое разделение дисков: одно быстрое NVMe-зеркало под операционную систему и логи транзакций СУБД, второе — под файлы данных СУБД и базу tempdb.
Конфигурация предусматривает 128 ГБ оперативной памяти на каждый сервер. Для «1С:ERP» такой объем является крайне скудным:
rphost в конфигурации ERP чрезвычайно прожорливы. При формировании сложных аналитических отчетов или закрытии месяца один рабочий сеанс пользователя может потреблять от 512 МБ до 1.5 ГБ оперативной памяти. Умножим средние 700 МБ на 250 активных сессий — получаем около 175 ГБ RAM, необходимых только под процессы «1С», без учета потребностей самой операционной системы. При нехватке памяти сервер начнет сбрасывать данные в файл подкачки, что приведет к катастрофическому падению производительности.Как исправить: Минимальный объем оперативной памяти для сервера приложений «1С» под ERP на 250 пользователей составляет 256 ГБ. Для сервера СУБД объем ОЗУ должен быть не меньше планируемого объема базы данных в перспективе 3 лет (рекомендуется от 256 ГБ до 512 ГБ).
Выбранный процессор Intel Xeon Gold 6226R имеет базовую частоту 2.9 ГГц. Для систем на базе «1С» это компромиссный вариант. Платформа «1С:Предприятие» выполняет большинство критических бизнес-операций (таких как проведение документа, расчет себестоимости, проведение блокировок) в однопоточном режиме. Это значит, что скорость выполнения транзакции напрямую зависит от производительности конкретного ядра, то есть от его тактовой частоты.
Вторая скрытая проблема — это лицензирование Microsoft SQL Server. Как известно, лицензии на SQL Server приобретаются по количеству ядер процессора (блоками по 2 ядра, минимум 4 ядра на один сокет). Покупая процессор с 16 относительно медленными ядрами, вы будете вынуждены заплатить за лицензирование всех 16 ядер СУБД, получив при этом невысокую производительность на одно ядро.
Как исправить: Гораздо выгоднее приобретать специализированные высокочастотные процессоры с меньшим количеством ядер. Например, процессоры серии Intel Xeon Gold 6334 / 6434 (8 ядер, базовая частота 3.6 - 3.7 ГГц) или процессоры семейства AMD EPYC 1F-серии (с увеличенным L3-кэшем и высокой частотой). Таким образом, вы получите колоссальный прирост скорости работы «1С» в один поток и одновременно сэкономите огромные средства на лицензировании ядер SQL Server.
Вы планируете использовать два физических сервера — отдельно для сервера приложений и сервера БД. Действительно, классическая «трехзвенка» отлично масштабируется. Но так ли она необходима при нагрузке в 250 пользователей?
Выясним причину, почему один мощный сервер в данном случае может оказаться более предпочтительным:
Если сервер приложений «1С» (процессы rphost) и СУБД (процесс sqlservr) запущены на одной физической машине, они могут взаимодействовать друг с другом не по сетевому протоколу TCP/IP, а напрямую через оперативную память по протоколу Shared Memory (общая память). Это исключает накладные расходы сетевого стека операционной системы, снижает сетевые задержки (latency) практически до нуля и дает чистый прирост производительности транзакционных операций «1С» в районе 10–15%.
Если же вы все-таки решите разносить СУБД и «1С» на разные физические серверы, то сетевой адаптер Broadcom 5720 4x1Gb из вашей спецификации станет узким местом. Сеть 1 Гбит/с не способна прокачать гигантские объемы данных, циркулирующие между «1С» и SQL при сложных ERP-запросах. При раздельной схеме обязательным условием является наличие сетевых карт класса 10 GbE или 25 GbE с прямым соединением серверов патч-кордом или через производительный коммутатор.
Если мы примем решение объединить роли на одном мощном однопроцессорном сервере (например, выбрав 1 высокочастотный процессор на 16–24 ядра и 512 ГБ оперативной памяти), нам потребуется выполнить обязательные регламентные настройки совместного сосуществования служб СУБД и 1С.
Рассмотрим по шагам ключевые настройки:
1. Ограничение оперативной памяти для SQL Server. По умолчанию MS SQL Server стремится забрать под свой кэш всю доступную физическую память сервера. Мы должны жестко ограничить аппетиты СУБД, чтобы оставить ресурсы под процессы rphost. Например, при общем объеме памяти в 256 ГБ выделим под SQL Server не более 140 ГБ.
Для выполнения этой настройки воспользуемся следующим скриптом в SQL Management Studio (SSMS):
EXEC sys.sp_configure N'show advanced options', N'1' RECONFIGURE WITH OVERRIDE;
GO
EXEC sys.sp_configure N'max server memory (MB)', N'143360'; -- Выделяем ровно 140 ГБ под СУБД
GO
RECONFIGURE WITH OVERRIDE;
GO
2. Настройка Processor Affinity (соответствие процессоров). Чтобы процессы rphost и sqlservr не конкурировали хаотично за одни и те же ядра процессора, на уровне операционной системы или СУБД можно жестко закрепить определенные ядра под обслуживание SQL Server, оставив остальные ядра под нужды операционной системы и рабочих процессов сервера «1С».
Давайте сведем все рекомендации в единый сбалансированный шаблон для построения надежной системы под «1С:ERP»:
tempdb выделите отдельные быстрые NVMe-накопители.Применение этих практических рекомендаций позволит запустить «1С:ERP» с высокой производительностью, защитит базу данных от возможных сбоев электропитания и сэкономит существенный бюджет на покупке дорогостоящих лицензий СУБД.