Переход с файлового режима работы «1С:Предприятие» на клиент-серверную архитектуру (SQL) — это важнейший шаг в развитии ИТ-инфраструктуры любого растущего предприятия. Особенно остро этот вопрос встает, когда объем базы данных увеличивается, растет количество пользователей в терминальном режиме (RDP), а распределенные информационные базы (РИБ) начинают генерировать колоссальные объемы транзакций при обмене данными.
В этой статье мы подробно проанализируем ситуацию, когда типовая база 1С:Розница объемом около 7 Гб с 60 узлами РИБ и 20–30 активными пользователями RDP RemoteApp начинает испытывать серьезные задержки в работе. Мы разберем по шагам, какое серверное железо выбрать, чтобы получить максимальную производительность, и какие критические настройки СУБД и операционной системы необходимо выполнить, чтобы дорогостоящее оборудование не простаивало впустую.
Один из самых частых вопросов, возникающих при выборе процессора для сервера 1С: «Правда ли, что потребительский Intel Core i9 работает с 1С быстрее, чем серверный Intel Xeon?»
Ответ на этот вопрос имеет двоякую природу и требует детального технического объяснения:
Какое решение выбрать? Для высокопроизводительного сервера 1С и СУБД оптимальным выбором будут специализированные серверные процессоры с высокой базовой частотой ядра (не менее 3.0 ГГц в номинальном режиме, без учета Turbo Boost). Рассмотрим отличные современные варианты:
Категорически не рекомендуется приобретать процессоры начального серверного уровня (такие как Xeon Silver 4108 / 4208) с низкой базовой частотой (1.8–2.1 ГГц). Для платформы «1С:Предприятие» они окажутся крайне медленными, и пользователи сразу заметят падение скорости работы интерфейса.
Проектируя многоядерную серверную систему, системные администраторы часто упускают из виду жесткие лицензионные ограничения платформы «1С:Предприятие 8.3».
Если у вашей организации приобретена серверная лицензия уровня ПРОФ, то начиная с версии платформы 8.3.15 рабочий процесс сервера 1С (rphost) аппаратно ограничен использованием не более чем 12 ядер процессора на одном сервере. Это означает, что если вы соберёте мощную двухпроцессорную систему на 24 или 32 ядра, значительная часть аппаратной мощности при лицензии ПРОФ будет простаивать без дела.
Переход на лицензии уровня КОРП не только снимает это ограничение, но и открывает доступ к расширенным настройкам кластера 1С, среди которых:
rphost под выполнение регламентных и фоновых заданий (таких как обмен РИБ, загрузка накладных, расчет себестоимости), чтобы они физически не забирали ресурсы у интерактивных сессий пользователей, работающих в RDP.При планировании инфраструктуры под 20–30 пользователей RemoteApp и сервер баз данных отличным решением будет разделение ролей на физическом или виртуальном уровне:
Исторически стандартом для крупных баз 1С являлся Microsoft SQL Server. Однако сегодня ситуация кардинально изменилась. Отличной альтернативой выступает отечественная коммерческая СУБД Postgres Pro Enterprise (разработанная специально с учетом специфики работы платформы 1С).
В отличие от базовой бесплатной версии PostgreSQL, коммерческая Postgres Pro содержит глубокие оптимизации ядра:
skip_temp_rel_lock минимизирует количество блокировок при активной работе с временными таблицами, что критично для тяжелых запросов в 1С.Использование оптимизированной СУБД позволяет выполнять сложные операции проведения документов в разы быстрее, вплотную приближая производительность к дорогостоящим решениям от Microsoft.
Скорость дисковой подсистемы — это главный фактор, определяющий общую отзывчивость клиент-серверной 1С. Ранее стандартом считалось создание RAID10 массивов на SAS SSD дисках через аппаратный контроллер с кэш-памятью и батарейкой (BBU).
Для современных накопителей формата NVMe (PCIe SSD) классические аппаратные RAID-контроллеры больше не требуются и даже вредны, так как они создают задержки (latency) и ограничивают пропускную способность шины. Современный подход выглядит следующим образом:
mdadm, или в среде Windows Server — через пулы носителей Storage Spaces).Даже на самом дорогом оборудовании производительность 1С будет низкой без правильной системной настройки. Выполним ключевые оптимизации по шагам.
Если сервер «1С:Предприятие» и СУБД (например, MS SQL Server) установлены на одном физическом сервере, их взаимодействие по умолчанию может идти через сетевой стек TCP/IP (даже при обращении к localhost). Нам необходимо принудительно задействовать протокол Shared Memory, который работает напрямую через оперативную память, исключая сетевые задержки ОС.
В SQL Server Configuration Manager развернем ветку SQL Server Network Configuration -> Protocols for [Имя_Экземпляра] и установим статус Enabled для протокола Shared Memory:
Shared Memory -> Enabled
TCP/IP -> Enabled (для удаленного администрирования)
Named Pipes -> Disabled (рекомендуется отключить для снижения накладных расходов)
По умолчанию серверное оборудование поставляется с включенными функциями энергосбережения. Процессор динамически снижает частоту ядер при отсутствии моментальной нагрузки. Для транзакционной системы 1С задержка в микросекундах на «разогрев» процессора при каждом проведении документа является фатальной.
По умолчанию СУБД пытается распараллелить выполнение любого сложного запроса на все доступные ядра процессора. Для учетных систем класса 1С это приводит к взаимным ожиданиям на блокировках и лавинообразному падению производительности.
Рекомендуется установить параметр MAXDOP (Maximum Degree of Parallelism) равным 1 (в редких случаях для очень мощных систем — до 2 или 4, но строго после замера производительности).
Выполним следующий скрипт в среде СУБД для изменения этой настройки:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;
GO
База tempdb активно используется платформой 1С для работы с временными таблицами. По умолчанию создается только один файл данных, что приводит к очередям запросов к дисковой подсистеме.
Рекомендуется создать несколько файлов данных tempdb. Их количество должно быть строго равно числу физических ядер процессора (но не более 8 файлов). Все файлы должны иметь абсолютно одинаковый первоначальный размер и шаг автоматического расширения, чтобы СУБД распределяла нагрузку на диски равномерно.
Пример SQL-скрипта для настройки файлов tempdb:
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'D:\SQL_TempDB\tempdb.mdf', SIZE = 4096MB, FILEGROWTH = 512MB);
GO
-- Добавление дополнительных файлов (повторить для требуемого количества ядер, например до 8)
ALTER DATABASE tempdb
ADD FILE (NAME = tempdev_2, FILENAME = 'D:\SQL_TempDB\tempdb_2.ndf', SIZE = 4096MB, FILEGROWTH = 512MB);
GO
Проанализировав все технические аспекты и требования, мы можем составить оптимальную спецификацию производительного сервера под задачи 1С:
Применение этого комплексного подхода к подбору оборудования и последующей настройке программного окружения позволит ускорить проведение документов в вашей базе 1С в разы, обеспечив комфортную и бесперебойную работу десятков пользователей в терминальном режиме.