Как подобрать сервер под 1С:ERP, УТ 11, Бухгалтерию и ЗУП

2026-05-19 11:59

Требования к серверу 1С сильно зависят от того, какая прикладная конфигурация на нём работает. Машина для Бухгалтерии на двадцать сотрудников и оборудование под 1С:ERP на двести человек — это два разных мира по железу, СУБД и архитектуре. И если перепутать классы, получится одно из двух: либо переплата за неиспользуемые ресурсы, либо коробка «впритык», которая не вытянет закрытие месяца.

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

Чем отличаются по нагрузке популярные конфигурации 1С

1С:ERP — самая тяжёлая конфигурация

1С:ERP Управление предприятием — это флагман платформы с десятками подсистем. Сюда входит производственный учёт вместе со складом, продажами и закупками. Отдельно работают модули регламентированного блока, MRP и финансы холдинга. Всё вместе создаёт типичную OLTP-обработку с интенсивной активностью по всем регистрам сразу. В пиковые часы продукт легко поднимает сотни одновременных сеансов и грузит вычислительные ядра, оперативную память и tempdb по полной.

1С:УТ 11 — управление торговлей с интеграциями

1С:Управление торговлей 11 устроена легче, чем флагман, по объёму регистров, но тяжелее по сетевым потокам. К ней подключаются маркетплейсы и онлайн-кассы. Параллельно идут обмены с банком через эквайринг и с личными кабинетами клиентов. Из-за такой специфики основной пик приходится не на ночь, а на дневные часы продаж и на выгрузки в конце смены.

1С:Бухгалтерия предприятия — относительно легкая нагрузка

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

1С:ЗУП — пиковая нагрузка в период расчёта зарплат

1С:ЗУП КОРП ведёт себя совсем иначе и больше похожа на «спящую» систему. Двадцать пять дней в месяце активность минимальная, а на закрытии периода идёт массовый расчет начислений, страховых взносов и формирование платежек. В эти дни работа взлетает в десятки раз — и именно под пик подбирается железо, а не под среднюю величину.

Сравнительная таблица по четырем конфигурациям

Чтобы не дублировать одинаковые разделы про процессор, память и диски для каждого продукта по отдельности, ключевые параметры сведены в одну таблицу. Цифры даны на типовом масштабе 100 человек — это самый частый запрос при подборе.

Сравнение требований по конфигурациям
Параметр	1С:ERP	1С:УТ 11	1С:Бухгалтерия	1С:ЗУП
CPU	16–24 ядра Xeon Gold 4-го поколения	12–16 ядер Xeon Silver/Gold	8–12 ядер	12–16 ядер
RAM	64–128 ГБ ECC	48–96 ГБ ECC	32–64 ГБ ECC	48–96 ГБ ECC
Диски	NVMe + tempdb на отдельный том	NVMe для базы + tempdb	NVMe enterprise	NVMe enterprise + tempdb
СУБД	Postgres Pro Enterprise / MS SQL	PostgreSQL / MS SQL	PostgreSQL / MS SQL	PostgreSQL / MS SQL
Отдельный узел под СУБД	да, обязательно	желательно	от 50 человек	от 100 человек
Кластер	от 200 человек	от 200 человек	редко	в пик расчёта зарплат
Профиль работы	OLTP, постоянный	OLTP + сеть	OLTP, ровный с пиком на закрытии	OLTP, пиковый раз в месяц

Из таблицы видна общая логика. При равном штате флагман требует в 1,5–2 раза больше ресурсов, чем торговая или бухгалтерская система. Тактовая частота процессора от 3,0 ГГц для платформы важнее большого числа ядер — это особенность OLTP-профиля. И ещё одна деталь: tempdb выносится на отдельный быстрый накопитель уже на средних объемах, потому что без этого СУБД упирается в дисковую подсистему.

Как меняются требования с ростом штата

Кроме типа продукта, на конфигурацию сильно влияет число сотрудников. Для каждой массовой системы есть три типовых масштаба: малый, средний и крупный. Приводим в одной таблице, чтобы было видно общую картину.

Требования по масштабам штата
Продукт	25 человек	100 человек	200 человек
1С:ERP	12 ядер, 32 ГБ, NVMe	20 ядер, 96 ГБ, NVMe + tempdb	2 узла Xeon Gold, 256 ГБ, кластер
1С:УТ 11	8 ядер, 24 ГБ, NVMe	14 ядер, 64 ГБ, NVMe	20 ядер, 128 ГБ, raid 10
1С:Бухгалтерия	8 ядер, 24 ГБ, SATA SSD	12 ядер, 48 ГБ, NVMe	редко требуется
1С:ЗУП	6 ядер, 16 ГБ, SATA SSD	14 ядер, 64 ГБ, NVMe	16 ядер, 96 ГБ, кластер в пик

Под типовые задачи Бухгалтерии на 30 человек обычно берут сервер для 1С на 30 пользователей — это рабочая планка с запасом на пару лет. Для флагмана на 100 человек разумно подбирать сервер для 1С на 100 пользователей. А когда конфигурация растёт за 200 — собирается отдельный кластер.

Реальный кейс торгового холдинга на 1С:ERP

Чтобы цифры из таблиц стали понятнее, разберем живой пример. В торгово-производственный холдинг на 200 человек флагман пришел с конкретной проблемой: закрытие месяца занимало 8 часов, бухгалтерия работала по субботам, MRP периодически зависал.

Машина тогда была одна — Xeon Silver 8 ядер, 64 ГБ ECC, SATA SSD, MS SQL Server 2017 на том же узле. Apdex по замерам gilev.ru держался на 0,68 — глубокая красная зона.

После аудита нагрузки развернули двухузловую схему:

Платформа 1С — на машине с Xeon Gold 16 ядер и 128 ГБ ECC RAM.
СУБД — на отдельном узле той же конфигурации, движок сменили на Postgres Pro Enterprise с CFS-сжатием.
Под tempdb — отдельный NVMe enterprise.
Под журнал транзакций — ещё один NVMe в RAID 10.

Результаты через два месяца:

Закрытие месяца сократилось с 8 часов до 1 часа 30 минут.
Apdex поднялся с 0,68 до 0,92 в пиковые часы.
Загрузка процессора на пике MRP не превышает 75%.
Бухгалтерия перестала работать по выходным.

Совокупная стоимость владения за три года, по расчету заказчика, выросла примерно на 20% относительно старой схемы. Но окупилась только на экономии переработок и просадки продаж в дни закрытий — без учета остальной выгоды.

Когда нужен отдельный узел под СУБД и когда кластер

Из кейса виден общий принцип. При 100+ сотрудниках платформу и движок базы разносят на разные физические машины. Это снимает конкуренцию между rphost и СУБД за процессор и память. А когда штат переваливает за 200, собирается кластер из 2–3 узлов с общей базой данных — отказоустойчивость и горизонтальное масштабирование одновременно.

Главное правило подбора при этом — закладывать ресурсы под пик, а не под среднее. По правилу N+1 пиковые часы на закрытии и MRP в 1,5–2 раза тяжелее среднедневных. Если коробка «впритык» на обычных задачах, на закрытии она встанет колом. Поэтому до покупки железа разумно прогнать сценарий закрытия на тестовой базе.

Файловый или клиент-серверный режим для Бухгалтерии

Кроме параметров железа, для Бухгалтерии решается отдельный вопрос архитектуры. Файловый режим безопасен до 5 человек. От 10 уже обязателен клиент-серверный вариант с MS SQL, PostgreSQL или Postgres Pro — иначе блокировки сделают работу невозможной. А от 25–30 уже окупается разнос платформы и движка базы на разные машины.

Особенности нагрузки УТ 11 и ЗУП

Кроме базовой конфигурации, у управления торговлей и зарплатного приложения есть свои нюансы. УТ 11 постоянно обменивается с внешними партнерами: с маркетплейсами идут выгрузки остатков, с эквайрингом — авторизация платежей, с банковскими шлюзами — выписки и платежки. Основная активность здесь ложится на сеть и tempdb, а не на процессор. Под такие задачи обязательно закладывают быстрый накопитель для журнала транзакций — без него обмены становятся узким местом раньше процессора.

Если планируете обслуживать 50+ касс или несколько маркетплейсов параллельно, есть смысл сразу подобрать сервер с учетом нагрузки под целевое число одновременных интеграций. ЗУП в дни расчёта зарплат нагружается в 5–10 раз сильнее обычного. К расчету начислений добавляются страховые взносы, а затем формирование платежных ведомостей. Параллельно идут обмены с Бухгалтерией по проводкам и с кадровым учетом по штатному расписанию.

Что ещё учесть при подборе

Кроме самой прикладной конфигурации, есть три фактора, которые часто упускают на этапе расчёта.

Интеграции и веб-публикации

К базовой работе добавляются внешние потоки. С маркетплейсами и банками идут обмены по расписанию, со СБИС — отчетность в контролирующие органы. Веб-публикации параллельно обслуживают кабинеты клиентов. Каждая такая интеграция — это плюс 5–15% к работе процессора и сети.

Резервирование и отказоустойчивость

Для критичных внедрений к расчетной мощности добавляется второй узел через AlwaysOn или Patroni. Для флагмана в банковском секторе это уже требование к архитектуре, без которого систему просто не примут в эксплуатацию.

Импортозамещение

Для госсектора и КИИ оборудование подбирается из реестра российского ПО, а PostgreSQL и Postgres Pro идут под Astra Linux, ALT Сервер или РЕД ОС. Машины на отечественных процессорах Эльбрус-8СВ работают, но с просадкой производительности 30–50% относительно x86 — эту разницу нужно учитывать при расчёте. Под такие проекты планируется импортозамещение серверов с пересборкой инфраструктуры.

Три типовые ошибки подбора

Подбираете железо по обычному дню — и хороните закрытие месяца

Соблазн посмотреть на дневной мониторинг, увидеть утилизацию 30% и сэкономить на конфигурации очень понятен. Но именно в эту яму чаще всего и проваливаются: флагман в обычный день грузит коробку на 30–40%, а на закрытии месяца — на 90–100%. Машина, которая казалась «с запасом», в нужный момент превращается в бутылочное горлышко, и бухгалтерия уходит в субботу с надеждой, что хотя бы воскресным утром скрипт добежит до конца. Поэтому считать всегда нужно по пику, а на пик смотреть не по средним, а по самым тяжелым 3–4 дням в месяц.

«Сегодня хватает» через год превращается в «срочно нужен апгрейд»

Бизнес не стоит на месте — добавляются филиалы, маркетплейсы, обмены, доработки, плюс растет штат. Машина, которая в день покупки закрывала задачи на 100%, через год работает на 130% и тормозит, через полтора — на 150% и встает. Правило N+1 — это не педантизм, а защита от ситуации, когда железо нужно менять через 12 месяцев вместо запланированных 3–4 лет. Закладывайте 30% запаса по процессору, памяти и дисковой подсистеме сразу — это намного дешевле, чем экстренный апгрейд под уже падающую систему.

Tempdb на общем SATA SSD — типовой способ потерять половину скорости

Tempdb в MS SQL и аналогичные временные структуры в PostgreSQL — это самое горячее место движка базы. Сюда летят промежуточные результаты любого мало-мальски сложного отчета, временные таблицы, сортировки. Если разместить tempdb на том же диске, где живут основные данные, и при этом сэкономить на классе накопителя, получите типовую картину: отчеты, которые в тестах работали за 30 секунд, в продакшене считаются по 3–5 минут. Под tempdb выносят отдельный NVMe enterprise или хотя бы отдельный том на быстром SSD — это самое дешевое в инфраструктуре место, экономить на котором запрещено.

Заключение

Подбор железа для платформы — это всегда расчет под конкретное прикладное решение, а не «в общем под 1С». Флагман требует в 1,5–2 раза больше ресурсов, чем УТ 11 или Бухгалтерия. ЗУП — спящая система с резкими пиками раз в месяц.

Тактовая частота процессора важнее числа ядер, а быстрый накопитель для tempdb обязателен от 25 человек. Отдельный узел под движок базы окупается от 50–100 человек, кластер — от 200. Поверх всего закладывается запас 30% по правилу N+1. Следующий шаг — снять текущую активность через Apdex с gilev.ru, прогнать тестовую базу под пиковыми сценариями и под эти цифры подбирать сервер для 1С.

Ответы на частые вопросы

Какой сервер нужен для 1С:ERP на 100 пользователей?

16–24 ядра процессора (Xeon Silver или Gold 4-го поколения), 64–128 ГБ ECC-памяти, NVMe enterprise для базы и отдельный накопитель под tempdb. В качестве СУБД — Postgres Pro Enterprise или MS SQL Server 2019/2022. От 200 человек собирается кластер из двух узлов.

Чем нагрузка УТ 11 отличается от ERP?

УТ 11 легче по объёму регистров, но тяжелее по сетевым потокам. Флагман — полный комплекс производства, склада и финансов с интенсивной OLTP-работой. При равном штате он требует в 1,5–2 раза больше процессора и оперативки.

Стоит ли держать СУБД на одной машине с платформой?

До 30–50 человек — да, это нормально. Свыше 50 платформу и движок базы разносят на разные физические машины. На 100+ это обязательно — иначе rphost и СУБД начнут конкурировать за процессор и память.

Подойдёт ли коробка на Эльбрусе или Байкале под 1С:ERP?

Технически работает, но с просадкой производительности 30–50% относительно x86 на эквивалентном числе ядер. Для коммерческих внедрений это редко оправдано, для госсектора и КИИ — обязательный путь импортозамещения.