Какую серверную ОС и версию SQL Server выбрать при переходе на 1С:Комплексная автоматизация 2.4 / 2.5?

← На главную

При переходе со старых конфигураций, таких как 1С:Комплексная автоматизация 1.1 (КА 1.1), на современные решения поколения КА 2.4 или КА 2.5, перед системными администраторами и руководителями ИТ-отделов неизбежно встает вопрос модернизации серверной инфраструктуры. Старый стек технологий, состоящий из Windows Server 2008 R2 и MS SQL Server 2008 R2, долгое время служил верой и правдой. Однако современная платформа 1С:Предприятие 8.3 и новые тяжелые конфигурации предъявляют принципиально иные требования к системному ПО и аппаратному обеспечению.

В этой статье мы подробно рассмотрим, почему оставаться на старых версиях операционных систем и СУБД невозможно, проведем детальный анализ выбора между решениями от Microsoft и PostgreSQL (Postgres Pro), а также разберем тонкие технические настройки для обеспечения максимальной производительности базы данных объемом от 30 ГБ и выше при работе 15 и более активных пользователей.

1. Почему модернизация серверного ПО неизбежна при переходе на КА 2.4 / 2.5?

Рассмотрим ключевые причины, по которым старая связка Windows Server 2008 R2 + MS SQL Server 2008 R2 не подходит для работы современных конфигураций:

Прекращение поддержки производителями: Microsoft полностью прекратила расширенную поддержку Windows Server 2008 R2 и MS SQL Server 2008 R2 еще в январе 2020 года. Это означает полное отсутствие обновлений безопасности, что делает вашу корпоративную сеть уязвимой к современным угрозам и вирусам-шифровальщикам.
Совместимость с платформой 1С:Предприятие: Новые релизы технологической платформы 1С:Предприятие 8.3 (начиная с версий 8.3.22 и 8.3.23) постепенно урезают поддержку устаревших СУБД. Вы просто не сможете обновить платформу до актуального релиза, необходимого для работы регламентированной отчетности и интеграции с государственными информационными системами (Честный Знак, ЕГАИС, Меркурий).
Проблемы с современными веб-протоколами: Устаревшие ОС не поддерживают современные стандарты шифрования (например, TLS 1.2/1.3 по умолчанию на системном уровне без сложных донастроек). Из-за этого сервер 1С не сможет корректно обмениваться данными с банками, сервисами контрагентов и контролирующими органами.

2. Архитектурные различия: как переход на КА 2.5 влияет на нагрузку на сервер

Переход с КА 1.1 на КА 2.4/2.5 — это не просто косметическое обновление интерфейса. Это переход на принципиально новую, гораздо более тяжелую архитектуру на базе флагманского решения 1С:ERP. Рассмотрим, как меняется характер нагрузки на серверное оборудование:

Управляемые формы: В КА 1.1 использовались обычные формы, где значительная часть вычислений производилась на клиентских компьютерах пользователей. В КА 2.4/2.5 используются исключительно управляемые формы. Практически вся бизнес-логика, проведение документов, расчеты себестоимости теперь выполняются на сервере приложений 1С.
Потребление оперативной памяти: Один активный сеанс пользователя в КА 2.5 на сервере 1С может потреблять от 1 до 2 ГБ ОЗУ в моменты сложных расчетов. Для 15 пользователей только серверным процессам 1С (rphost) потребуется около 20–30 ГБ оперативной памяти. К этому нужно добавить аппетиты СУБД и самой ОС. Поэтому минимальный объем ОЗУ для нового сервера должен составлять **не менее 48–64 ГБ**.
Требования к процессору: Большинство расчетных механизмов в 1С (таких как закрытие месяца или партионный учет) выполняются в один поток. Следовательно, для высокой производительности критически важна **высокая тактовая частота процессора на одно ядро (от 3.2 ГГц и выше)**, а не общее количество ядер с низкой частотой.

3. Выбор СУБД: Microsoft SQL Server против PostgreSQL (Postgres Pro)

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

Вариант А: Microsoft SQL Server (версии 2019 или 2022)

Если ваша организация имеет возможность приобрести или продолжить использовать лицензии Microsoft, то связка Windows Server 2022 + MS SQL Server 2019 / 2022 остается стандартом высокой производительности. Версия 2019 года на сегодняшний день является наиболее стабильной и проверенной временем СУБД для крупных баз 1С.

Преимущества: Отличный оптимизатор запросов, простота администрирования, стабильная работа "из коробки" без глубоких технических настроек.

Недостатки: Крайне высокая стоимость лицензий (как серверных, так и клиентских CAL-лицензий), а также сложности с официальным приобретением новых лицензий на территории РФ.

Вариант Б: Postgres Pro для 1С (или бесплатный PostgreSQL с патчами от 1С)

Для базы объемом 30 ГБ и 15 пользователей СУБД PostgreSQL является идеальным и экономически оправданным решением. Вы можете использовать полностью бесплатную сборку PostgreSQL от компании 1С или приобрести коммерческую версию Postgres Pro Standard, которая содержит дополнительные оптимизации для работы с тяжелыми таблицами 1С.

Преимущества: Нулевая или минимальная стоимость лицензирования СУБД, возможность развертывания на бесплатных дистрибутивах Linux (Astra Linux, РЕД ОС, Ubuntu Server), что избавляет от необходимости покупать дорогие лицензии Windows Server.

Недостатки: Требует более высокой квалификации системного администратора для первоначальной настройки и периодического обслуживания ( vacuum, analyze, оптимизация конфигурационного файла postgresql.conf).

4. Тонкая техническая настройка MS SQL Server для оптимизации работы 1С

Если вы приняли решение использовать MS SQL Server, крайне важно отказаться от настроек по умолчанию, которые могут существенно замедлять работу конфигурации. Разберем по шагам ключевые параметры оптимизации.

Настройка степени параллелизма (MAXDOP)

По умолчанию SQL Server пытается распределить выполнение одного тяжелого запроса на все доступные ядра процессора. Для 1С это губительно, так как вызывает избыточные ожидания на блокировках. Фирма 1С официально рекомендует устанавливать параметр Max Degree of Parallelism (MAXDOP) в значение 1 (использование только одного ядра на один запрос).

Включение режима изоляции Snapshot (RCSI)

Режим Read Committed Snapshot Isolation (RCSI) кардинально снижает количество взаимных блокировок в многопользовательской среде. При включенном RCSI читающие транзакции не блокируют пишущие, а пишущие не мешают читающим. Для активации этого режима выполните следующий скрипт в MS SQL Management Studio:


ALTER DATABASE [Имя_Вашей_Базы_1С] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [Имя_Вашей_Базы_1С] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [Имя_Вашей_Базы_1С] SET MULTI_USER;

Ограничение потребления оперативной памяти

По умолчанию MS SQL Server стремится забрать под свои нужды до 98% всей оперативной памяти сервера, не оставляя ресурсов серверу приложений 1С и операционной системе. Это приводит к критическим сбоям и уходу сервера в swap-файл подкачки.

Необходимо жестко ограничить параметр Max Server Memory в свойствах сервера СУБД. Например, если на сервере установлено 32 ГБ ОЗУ, выделите под MS SQL Server не более 18–20 ГБ, оставив остальные ресурсы операционной системе и процессам rphost сервера 1С.

Настройка автоувеличения файлов базы данных (Autogrowth)

По умолчанию файлы базы данных (MDF) и логов транзакций (LDF) увеличиваются на фиксированный процент (например, на 10%). Когда база размером 30 ГБ пытается вырасти сразу на 3 ГБ, сервер временно "замирает", блокируя работу всех пользователей.

Настройте автоувеличение файлов в фиксированных единицах. Рекомендуется установить рост файла данных (MDF) равным 512 МБ или 1024 МБ, а файла лога транзакций (LDF) – 256 МБ или 512 МБ.

5. Оптимизация дисковой подсистемы и мифы о виртуализации

В процессе обсуждения на форумах часто возникает спор: можно ли использовать виртуализацию для баз данных СУБД или нужно использовать только "реальное железо"?

Современные гипервизоры (такие как VMware ESXi, Microsoft Hyper-V или Proxmox VE) при правильном конфигурировании дают потерю производительности процессора и памяти не более 2–5%. При этом они предоставляют колоссальные преимущества: легкое резервное копирование снимками (снапшотами) перед обновлениями КА, удобный перенос виртуальной машины на другой физический сервер в случае аварии и гибкое распределение ресурсов.

Однако при работе в виртуальной среде критически важно соблюдать правила настройки дисковой подсистемы:

Разделение дисков на уровне физических накопителей: Недостаточно просто создать в виртуальной машине диски C, D и E. Если все они физически лежат на одном медленном RAID-массиве или на одном сетевом хранилище, производительность СУБД будет крайне низкой из-за высокой очереди диска.
Вынос TempDB на самый быстрый диск: База временных таблиц СУБД tempdb испытывает колоссальные нагрузки при проведении документов в 1С. Размещайте файлы tempdb исключительно на локальных твердотельных накопителях корпоративного класса (Enterprise SSD или NVMe) с высоким ресурсом перезаписи (DWPD).
Отказ от оверкоммита ресурсов: В настройках виртуальной машины с сервером 1С и СУБД необходимо зарезервировать 100% выделенной оперативной памяти (параметр RAM Reservation), чтобы гипервизор не сбрасывал память сервера 1С на медленный диск хоста. Также не рекомендуется выделять виртуальной машине больше виртуальных ядер процессора (vCPU), чем физически присутствует на сокете сервера.

Проанализировав все особенности перехода со старого стека на современные конфигурации семейства КА 2.4/2.5, мы можем сделать вывод: покупка нового производительного оборудования с высокой частотой ядер процессора, переход на СУБД Postgres Pro (для экономии бюджета) или современный MS SQL Server 2019/2022, а также грамотное разделение дисковой подсистемы под базы данных и файлы tempdb гарантируют быструю и комфортную работу пользователей в обновленной системе.