Сервер для 1С на 10–50 пользователей: ядра, память, диски

Сервер для 1С на 10–50 пользователей: где нужна мощность, а где начинается переплата

Сервер под 1С на 10–50 пользователей почти всегда покупают с перекосом в одну сторону: либо «возьмём помощнее, чтобы не возвращаться», либо «нас же немного, хватит офисной машины». В обоих случаях деньги уходят не туда. Ниже — практический разбор для этого диапазона: из каких ролей вообще состоит «сервер 1С», сколько ресурсов нужно на каждом уровне, что придётся купить кроме железа и в какой момент доплата перестаёт влиять на скорость работы бухгалтерии.

Коротко: что нужно серверу 1С на 10–50 пользователей

Если нужен ответ в одну строку: серверу 1С в этом диапазоне нужны быстрые ядра, а не многочисленные, ECC-память с запасом 20–30 % и NVMe под базу. Всё остальное — вопрос того, сколько ролей вы навесите на одну машину.

Пользователей	Процессор	Память	Диски	Что решает больше всего
10–15	6–8 быстрых ядер, частота от 3,0 ГГц	32 ГБ ECC	SSD NVMe, RAID 1	Диск и частота ядра
16–30	8–12 ядер с высокой частотой	64 ГБ ECC	NVMe, RAID 1 или RAID 10	Объём кэша СУБД и задержки диска
31–50	12–16+ ядер или разделение ролей	96–128 ГБ ECC	NVMe, RAID 10, отдельный том под журналы	Архитектура: сколько ролей на одной машине

Совет на практике

Прежде чем выбирать процессор, посмотрите в диспетчере задач на текущем сервере, что происходит в момент закрытия месяца. Если процессор загружен на 30–40 %, а диск на 100 % — новые ядра не помогут вообще, нужен NVMe. Если наоборот, процессор в потолке, а диск спокоен — деньги нужно вкладывать в частоту, а не в количество ядер.

Из каких ролей состоит сервер 1С

«Сервер 1С» — это не одна программа, а набор служб. На бумаге их можно поставить на одну машину, и для 10–50 пользователей так чаще всего и делают. Но понимать, что именно вы совмещаете, нужно: именно совмещение ролей, а не число сотрудников, чаще всего и приводит к тому, что сервер «не тянет».

Роль	Что делает	Что требует от железа	Нужна на 10–50
Сервер СУБД (PostgreSQL или MS SQL)	Хранит базу и выполняет запросы	Ядра, много памяти под кэш, NVMe по IOPS	Да, если база не файловая
Сервер приложений (кластер 1С)	Исполняет код конфигурации, регламентные задания, обмены	Высокая частота ядра, 8+ ядер, 8–16 ГБ памяти	Да
Сервер лицензирования	Выдаёт клиентские лицензии по сети	Практически ничего: 1 ядро, 1–2 ГБ	Да, но всегда совмещается
Веб-сервер (публикация базы)	Отдаёт веб-клиент через Apache или IIS	Немного CPU, память под сессии	По необходимости
Сервер взаимодействия	Чат, уведомления, совместная работа	Отдельный сервис и отдельные лицензии	Редко, в основном для КОРП-задач
Файловая шара и бэкапы	Хранит копии, обмены, вложения	Диски и место	Лучше вынести с сервера 1С

Сервер СУБД

Самая требовательная роль. СУБД умеет параллелить запросы, поэтому ей нужны и ядра, и большой объём памяти под кэш данных. Если памяти мало, СУБД начинает читать с диска то, что могла бы держать в оперативке, и скорость падает в разы — при этом процессор может оставаться полупустым. Для PostgreSQL на 30 пользователей 64 ГБ памяти — это не «жирно», а нормальный рабочий объём.

Сервер приложений и сервер лицензирования

Кластер серверов 1С исполняет код конфигурации. Здесь всё наоборот: важна частота одного ядра, потому что проведение документа и расчёт себестоимости идут в один поток. Сервер лицензирования (служба rages на Linux или HASP-совместимая служба на Windows) ресурсов почти не потребляет и всегда живёт на той же машине — отдельный сервер под него в этом диапазоне не нужен.

Веб-сервер и сервер взаимодействия

Публикация базы для веб-клиента добавляет Apache или IIS. Для 10–50 пользователей, которые работают с тонким клиентом, эта роль не нужна. Веб-публикация нужна, если сотрудники заходят с домашних компьютеров, из филиалов или с планшетов. Сервер взаимодействия — отдельная история: он нужен для чата и совместной работы в 1С:Документооборот и подобных конфигурациях, требует собственных лицензий и на обычной бухгалтерии не используется.

Какая у вас 1С, а не сколько пользователей

Число пользователей — плохая единственная метрика. 20 сотрудников в базе могут создавать совершенно разную нагрузку:

20 кассиров или операторов, которые вносят документы небольшими порциями;
20 бухгалтеров, которые закрывают месяц, формируют тяжёлые отчёты и активно работают с регламентными заданиями;
20 пользователей через RDP на том же сервере, где работает СУБД;
20 пользователей в терминале плюс обмены, выгрузки, ЭДО, фоновые обработки и резервное копирование в рабочее время.

Перед выбором железа нужно зафиксировать четыре вещи — иначе любой подбор превращается в угадывание.

Архитектура базы. Файловая или клиент-серверная с СУБД. Для 10–50 пользователей обычно уже рассматривают клиент-серверный вариант, особенно если база растёт и есть регулярные тяжёлые операции.
Где работают пользователи. Локальные клиенты, тонкий клиент, веб или RDP. Терминальный режим резко меняет требования к процессору и памяти.
Размер и динамика базы. База 30 ГБ и база 500 ГБ — разные истории по дискам, резервному копированию и обслуживанию.
Критичные периоды. Закрытие месяца, массовые обмены, загрузка прайсов, расчёт зарплаты, выгрузки в BI и отчётность.

Конфигурация «на 30 пользователей» без понимания сценария может оказаться как избыточной, так и откровенно слабой. Подробнее о том, как вообще устроен подбор под 1С, мы разбирали в отдельной статье как выбрать сервер для 1С.

Процессор: частота важнее числа ядер

Процессор для сервера 1С: частота важнее числа ядер

Для 1С важны не только ядра. Во многих операциях критична производительность одного потока: частота, архитектура, размер кэша, поведение под длительной нагрузкой. СУБД, фоновые задания, RDP-сессии и несколько одновременных тяжёлых отчётов уже требуют большего числа ядер, но «много медленных ядер» почти всегда хуже, чем умеренное количество быстрых.

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

Сценарий	Ориентир по CPU	Комментарий
10–15 активных пользователей, СУБД отдельно не выделяется	6–8 производительных ядер	Важно не экономить на частоте и дисках
20–30 пользователей, СУБД и 1С на одном сервере	8–12 ядер	Нужен запас под фоновые задания и отчёты
40–50 пользователей, тяжёлые отчёты, RDP или активные обмены	12–16+ ядер или разделение ролей	Часто разумнее развести СУБД, 1С и терминальные службы

Где начинается переплата по процессору

Брать двухпроцессорную систему только потому, что «сервер должен быть двухпроцессорным». Для 10–30 пользователей второй сокет чаще всего простаивает.
Покупать максимальное число ядер при низкой частоте, если основная боль — долгие интерактивные операции.
Закладывать процессор под будущую нагрузку без плана роста базы, пользователей и ролей.
Смешивать на одной машине 1С, СУБД, RDP, файловую шару, видеонаблюдение и резервное копирование, а потом пытаться вылечить это процессором.

Если сервер одновременно будет узлом виртуализации, логика другая: считать нужно не только 1С, но и остальные виртуальные машины — суммарные vCPU, резерв под гипервизор и пики. Как читать характеристики серверных камней, мы подробно разбирали в статье как выбрать серверный процессор Xeon.

Память: как посчитать и где запас оправдан

Для сервера под 1С сразу рассматривайте ECC-память. Она не ускоряет работу — её задача другая: исправлять единичные сбои бит, которые на сервере с базой данных могут обойтись дороже, чем разница в цене между обычными модулями и ECC REG. Для базы, в которой лежит вся бухгалтерия, это не роскошь, а нормальная инженерная практика.

Ориентиры по объёму для 1С на 10–50 пользователей:

Пользователей	Память	Когда нужно больше
10–15	от 32 ГБ	Если СУБД, 1С и ОС на одной машине и база больше 50 ГБ
16–30	64 ГБ	Активный рост базы, тяжёлые отчёты, обмены
31–50	96–128 ГБ	Терминальные сессии, несколько ВМ, план расширения

Формула расчёта

ОС и служебные процессы: 6–10 ГБ
Кэш СУБД: 40–60 % от активной части базы
Сервер 1С и фоновые задания: 4–8 ГБ
RDP-сессии: 0,5–1,5 ГБ на одновременного пользователя
Резерв: 20–30 %, чтобы сервер не жил на пределе

Пример. 25 пользователей, СУБД и 1С на одной машине, RDP нет, база около 120 ГБ, активная часть заметная. 32 ГБ работать будет, но быстро станет тесно: СУБД хуже кэширует данные, диски получают лишнюю нагрузку. 64 ГБ — спокойный старт. 128 ГБ оправданы, если база растёт на 10 ГБ в месяц, есть тяжёлые отчёты и план добавить виртуальные машины; без этих условий это уже доплата за воздух.

Отдельно проверьте тип памяти, который поддерживает платформа: ECC UDIMM, RDIMM и LRDIMM — разные классы, произвольно смешивать их нельзя. Разницу между ними мы разбирали в статье LRDIMM или RDIMM, а общий принцип работы коррекции ошибок — в материале что такое ECC-память.

Диски: задержки важнее объёмов

Диски для сервера 1С: задержки важнее объёмов

Дисковая подсистема — самая частая причина жалоб «сервер мощный, а 1С всё равно думает». Для базы данных важны не объём и паспортные мегабайты в секунду, а задержки, стабильность под смешанной нагрузкой, ресурс записи и грамотное разделение ролей.

Что обычно стоит разделять:

Что	Где держать	Почему отдельно
Система и службы	SSD SATA или NVMe, зеркало	Отказ системного диска останавливает всё
База (data)	NVMe, RAID 1 или RAID 10	Основная нагрузка на случайное чтение
Журналы транзакций (log)	Отдельный NVMe	Последовательная запись не должна конкурировать с чтением
tempdb (для MS SQL)	Отдельный быстрый том	Активно перезаписывается, изнашивает диск
Резервные копии	Другой сервер, NAS или внешний контур	Копия на том же массиве не спасает от сбоя массива

NVMe дают низкие задержки на случайных операциях, но выбирать их нужно не по максимуму МБ/с: для сервера важны ресурс записи (DWPD/TBW), охлаждение, поведение под длительной нагрузкой и наличие резервирования. SATA SSD приемлемы для системы и умеренных сценариев, но на 30–50 активных пользователей с тяжёлыми отчётами они становятся компромиссом. Сравнение интерфейсов — в статье NVMe или SATA SSD для сервера.

RAID — не резервное копирование. Он защищает от отказа диска, но не от повреждения базы, ошибки администратора, шифровальщика или неудачного обновления. Какой уровень массива выбрать под базу, а какой под файлы, разобрано в материале RAID: какой уровень массива выбрать.

Одна машина или две

Для 10–50 пользователей есть два рабочих пути: один физический сервер под всё или сервер виртуализации, где 1С живёт в одной или нескольких виртуальных машинах. Оба варианта нормальные, если спроектированы под реальную нагрузку.

Когда хватает одной машины

До 15–20 одновременных пользователей, одна база, RDP не используется.
СУБД и сервер приложений совмещены, памяти хватает с запасом 20–30 %.
Нет требований к простою: остановка на пару часов для обслуживания допустима.

Когда пора разделять роли

Больше 25–30 активных пользователей и тяжёлые отчёты: СУБД и сервер приложений начинают конкурировать за процессор и память.
Пользователи работают через RDP: терминальные сессии съедают память и CPU, которые нужны базе.
Кроме 1С на сервере живут AD, файловые сервисы, мониторинг, тестовая база, шлюзы.
Нужны снапшоты перед обновлениями и быстрый перенос виртуальной машины.

Виртуализация: когда помогает, а когда маскирует проблему

Виртуализация удобна, но она не бесплатный слой. Если на одном узле одновременно работают СУБД, 1С, RDP на 40 человек, файловый сервер и резервное копирование, проблема не в выборе гипервизора, а в плотности нагрузки. И ещё одно ограничение: виртуализацию должен сопровождать человек, который понимает, что такое overcommit по памяти, как устроены снапшоты и почему бэкап виртуальной машины — не то же самое, что бэкап базы. Сколько ресурсов нужно узлу, считает материал сервер для виртуализации: сколько ядер и памяти.

Про видеокарту стоит сказать отдельно: для 1С GPU не нужен. Он оправдан, только если на той же инфраструктуре есть VDI с графикой, локальные ИИ-задачи или обработка видео. Покупать GPU «на всякий случай для 1С» — почти всегда лишняя статья бюджета.

Windows или Linux для сервера 1С

Сервер 1С работает и на Windows, и на Linux — выбор влияет не на скорость 1С, а на стоимость и на то, кто это будет обслуживать.

Критерий	Windows Server	Linux
Лицензия ОС	Платная, по числу ядер или пользователей	Бесплатно (Astra, Ubuntu, Debian, ALT)
СУБД	MS SQL или PostgreSQL	PostgreSQL
Терминальный доступ	Штатный RDS	Через отдельные решения, настраивается сложнее
Кто обслуживает	Знаком почти любому администратору	Нужен человек с опытом Linux
Ресурсы	Заметный расход на саму ОС	Меньше накладных расходов

Практическое правило для 10–50 пользователей: если база на PostgreSQL, а администратор умеет в Linux — сервер на Linux дешевле и на лицензиях, и по ресурсам. Если база на MS SQL или терминальный доступ нужен «из коробки» — Windows. Подробнее о выборе платформы — в статье какую ОС выбрать для сервера.

Лицензирование: что купить кроме железа

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

Что покупать	Зачем	На что влияет
Серверная лицензия 1С:Предприятие ПРОФ	Право запускать сервер 1С	Без неё клиент-серверный режим не работает
Расширение серверной лицензии на подключения	Ограничивает число одновременных сеансов к серверу 1С	Не путать с числом рабочих мест в базе
Клиентские лицензии на 1, 5, 10, 20, 50 мест	Право подключаться пользователям	Считаются по одновременным подключениям
Лицензия на СУБД	MS SQL лицензируется по ядрам, PostgreSQL бесплатен	При 8–16 ядрах разница в цене ощутимая
Лицензия ОС	Windows Server	На Linux не нужна

Совет на практике

Серверная лицензия 1С не включает клиентские. Это две разные покупки, и именно на этом чаще всего «попадают»: сервер установлен, база поднята, а пользователи подключиться не могут. Посчитайте клиентские лицензии по одновременным подключениям, а не по штатному расписанию — экономия может быть кратной.

Если база остаётся файловой (до 5–10 пользователей это ещё допустимо), серверная лицензия не нужна вообще — но и вся мощь железа при файловом режиме почти не используется, потому что обработка идёт на клиенте. Поэтому покупка «серверного» железа под файловую базу — типичная переплата.

Пример: 30 пользователей без лишнего героизма

Допустим, в 1С работают 30 сотрудников. Из них 20 активны ежедневно, 5–7 формируют отчёты, есть обмены с внешними системами, база около 150 ГБ, рост 5–10 ГБ в месяц. Пользователи подключаются с рабочих мест, RDP для всех не нужен. Нужна предсказуемая работа в течение дня и спокойное закрытие месяца, но без задачи строить кластер высокой доступности.

Разумная отправная точка:

Процессор: 8–12 производительных ядер с высокой частотой, без погони за максимальным числом потоков.
Память: 64 ГБ ECC REG как база, 128 ГБ — если есть тяжёлые отчёты, быстрый рост базы или план добавить виртуальные машины.
Диски: NVMe с зеркалированием, отдельные тома под базу, журналы и tempdb.
Сеть: 1 Гбит/с минимум, 10 Гбит/с имеет смысл при активной виртуализации, бэкапах и работе с крупными файлами.
Резервное копирование: отдельный контур и регулярная проверка восстановления, а не просто «копии где-то лежат».

Если те же 30 человек работают через RDP на этом же сервере, расчёт меняется: добавляется нагрузка от пользовательских сессий, профилей, офисных приложений, печати и браузеров. Тогда разумнее разделить роли — отдельная виртуальная машина или сервер под терминал, отдельная под СУБД и 1С. Сколько потянет терминальный сервер, считается в статье терминальный сервер: сколько пользователей потянет.

Если нужна не абстрактная спецификация, а подбор под конкретную базу, число пользователей и роль сервера, в каталоге есть раздел с готовыми серверами под 1С. Это не отменяет расчёт — наоборот, нормальный подбор начинается со сценария нагрузки, а не с карточки товара.

Чек-лист перед покупкой

Что проверить	Почему это деньги
Роли сервера: только 1С и СУБД или ещё RDP, файлы, бэкапы	Каждая лишняя роль съедает ресурсы, которые вы оплатили для базы
Число одновременных пользователей, а не всего в базе	Определяет и железо, и клиентские лицензии
Размер базы и темп роста	Определяет объём памяти под кэш и ёмкость дисков
Тип базы: файловая или клиент-серверная	Определяет, нужно ли вообще серверное железо и серверная лицензия
Пики нагрузки: закрытие месяца, обмены, зарплата	Именно под них подбирается запас по CPU и диску
Тип памяти: ECC UDIMM, RDIMM или LRDIMM	Несовместимые модули придётся менять, а не докупать
Схема дисков: ОС, база, журналы, бэкапы раздельно	Один общий том — самая частая причина «тормозит»
Кто будет обслуживать: Windows или Linux	Стоимость лицензий и наличие администратора

Частые ошибки

Выбирают сервер только по числу пользователей, не выяснив архитектуру базы, размер и пики нагрузки.
Покупают много медленных ядер вместо умеренного числа быстрых — для 1С это прямой проигрыш в проведении документов.
Экономят на дисках, поставив мощный процессор: база на SATA SSD или HDD сводит на нет весь выигрыш от CPU.
Совмещают СУБД, сервер приложений, RDP и бэкапы на одном томе, а потом лечат это заменой процессора.
Считают RAID полноценным резервным копированием и не проверяют восстановление.
Забывают про лицензии 1С и СУБД, обнаруживая это уже после покупки железа.
Берут конфигурацию «с запасом на всё» без понятного сценария роста — запас, который не используется, стоит как половина сервера.

Частые вопросы

Сколько пользователей выдержит сервер 1С на одном процессоре?

При клиент-серверной базе и СУБД на той же машине один современный процессор на 8–12 быстрых ядер спокойно обслуживает 25–30 одновременных пользователей. Дальше упирается не число ядер, а память под кэш СУБД и задержки диска. Для 40–50 активных пользователей с тяжёлыми отчётами разумнее разделять роли.

Обязателен ли отдельный сервер СУБД для 20–30 пользователей?

Нет, не обязателен. До 25–30 одновременных пользователей СУБД и сервер приложений нормально живут на одной машине, если памяти хватает с запасом 20–30 процентов. Отдельный сервер СУБД имеет смысл при росте базы, тяжёлых отчётах, терминальном режиме или требованиях к доступности.

Что такое сервер приложений 1С и нужен ли он на 10–50 пользователей?

Это служба кластера 1С, которая исполняет код конфигурации, регламентные задания и обмены. Нужна всегда, если база клиент-серверная. Отдельная физическая машина под неё в диапазоне 10–50 пользователей почти никогда не требуется — она ставится вместе с СУБД.

Зачем нужен сервер лицензирования 1С?

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

Сколько памяти нужно серверу 1С на 30 пользователей?

Ориентир — 64 ГБ ECC REG, если СУБД и 1С на одной машине и RDP не используется. Если база больше 200 ГБ, растёт быстро или пользователи работают через терминал, смотреть нужно на 96–128 ГБ. Меньше 32 ГБ на 30 пользователей — почти гарантированная нехватка кэша СУБД.

Можно ли поставить сервер 1С на Linux?

Да, серверная часть 1С работает на Linux нативно, без эмуляторов. Это дешевле по лицензиям ОС и требует меньше ресурсов, но база тогда будет на PostgreSQL, а обслуживать сервер должен администратор с опытом Linux. Терминальный доступ на Linux настраивается сложнее, чем RDS на Windows.

Почему появляется ошибка «сервер 1С не обнаружен»?

Чаще всего не запущена служба агента сервера, закрыты порты 1540–1541 и диапазон 1560–1591, указан неверный адрес или порт в строке подключения, либо не установлена серверная лицензия. Реже причина в несовпадении разрядности и версий платформы на сервере и клиенте.

Нужна ли видеокарта для сервера 1С?

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

Что дешевле: собрать сервер под 1С или купить готовый?

Сборка из комплектующих обычно дешевле готового брендового сервера на 30–50 процентов при сопоставимых характеристиках. Готовый сервер выгоднее, когда нужны гарантия на всю систему, поддержка вендора и обслуживание по контракту. Разбор цен по уровням конфигураций — в статье сколько стоит собрать сервер.