Администрирование · 11 мин
Как рассчитать сервер под 1С
Как рассчитать сервер под 1С: нагрузка пользователей, требования к CPU, RAM, дискам и СУБД, типовые конфигурации и ошибки при подборе оборудования.
Подбор сервера под 1С почти всегда страдает от двух крайностей: либо берут «с запасом» и переплачивают за ненужные ресурсы, либо экономят на дисковой подсистеме и получают жалобы пользователей на «тормоза» через месяц после запуска. Правильный расчёт начинается не с каталога оборудования, а с анализа нагрузки: сколько пользователей работает одновременно, какие конфигурации используются, файловый или клиент-серверный режим планируется, какой объём базы и как быстро она растёт.
Ключевой принцип: 1С предъявляет разные требования к разным компонентам сервера. Процессор важен для серверов приложений и тонких клиентов, оперативная память — для кластера 1С и СУБД, а дисковая подсистема критична для базы данных. Ошибка в любом из трёх пунктов сводит на нет вложения в остальные.
Ниже разобрана практическая методика расчёта: от сбора исходных данных до проверки готового сервера под реальной нагрузкой. Методика подходит для типовых конфигураций (ERP, УТ, КА, ЗУП, Бухгалтерия) в клиент-серверном варианте работы.
Шаг 1. Соберите исходные данные о нагрузке
Без исходных данных любой расчёт превращается в гадание. Зафиксируйте пять параметров: число одновременно работающих пользователей (не общее число учётных записей, а реальный пик), перечень конфигураций и режим работы, текущий и прогнозируемый размер базы, интенсивность документооборота (документов в день), а также требования к отказоустойчивости — допустим ли простой в несколько часов.
Число пользователей считайте по пиковой нагрузке: утренний вход, закрытие месяца, инвентаризация. Если в обычный день работают 30 человек, а в отчётный период — 50, рассчитывайте сервер на 50. Учтите и фоновые нагрузки: регламентные задания, обмены данными, веб-сервисы и интеграции потребляют ресурсы так же, как живые пользователи.
Объём базы измерьте фактически: посмотрите размер файла базы на текущем сервере и оцените темп роста за последний год. База в 100 ГБ с ростом 30% в год через два года потребует почти вдвое больше места — это нужно учесть и в дисках, и в объёме памяти под кэш СУБД.
Считайте по пиковым периодам, а не по среднему дню
Измерьте фактический размер и темп роста
От 20–30 пользователей клиент-серверный вариант практически обязателен
Требуют запаса CPU и RAM сверх базового расчёта
Шаг 2. Выберите архитектуру: файловая или клиент-серверная
Файловый режим допустим для небольших баз с числом пользователей до 5–10 человек. Здесь сервер фактически выполняет роль файлового хранилища, и требования к нему минимальны. Но уже при 10–15 пользователях файловый режим становится источником блокировок, ошибок и риска повреждения базы.
Клиент-серверный вариант (сервер 1С:Предприятие + СУБД, чаще MS SQL Server или PostgreSQL) — стандарт для 15–20 и более пользователей. Он снимает ограничения файлового режима, позволяет централизованно управлять нагрузкой и даёт нормальные механизмы резервного копирования. Расчёт дальше ведётся именно для этой архитектуры.
Отдельный вопрос — размещать ли кластер 1С и СУБД на одном физическом сервере. Для 20–50 пользователей это допустимо и экономично, если суммарной памяти хватает на оба компонента. При большей нагрузке или жёстких требованиях к отказоустойчивости сервер приложений и сервер СУБД разносят на разные машины (физические или виртуальные).
Варианты размещения компонентов
Подходит до 30–50 пользователей. Проще и дешевле, но компоненты конкурируют за память, а отказ сервера останавливает всё
Для 50+ пользователей или высоких требований к доступности. Гибче масштабируется, но дороже и сложнее в администрировании
Допустима при правильном резервировании ресурсов. Избегайте overcommit по памяти и дискам — для 1С это критично
Шаг 3. Рассчитайте оперативную память
Память — самый частый дефицит на серверах 1С. Рабочий ориентир для кластера 1С:Предприятия — 0,5–1 ГБ на активного пользователя в зависимости от конфигурации. Лёгкие конфигурации вроде Бухгалтерии ближе к нижней границе, ERP с тяжёлыми документами и отчётами — к верхней и выше.
Для СУБД закладывайте объём, достаточный для кэширования активной части базы. Практическое правило: память под СУБД должна быть сопоставима с размером «горячих» данных — обычно 20–30% от полного объёма базы, но не меньше 16–32 ГБ на средних внедрениях. Если база 200 ГБ, а под SQL Server выделено 8 ГБ, дисковая подсистема будет задушена чтением.
Пример расчёта: 40 пользователей ERP, база 150 ГБ. Кластер 1С: 40 × 0,75 ≈ 30 ГБ. СУБД: 32–48 ГБ под буферный пул. Операционная система и прочее: 8 ГБ. Итого минимум 80 ГБ, с запасом на рост — 96–128 ГБ. При совмещении на одном сервере суммируйте оба значения и добавьте 20%.
Шаг 4. Подберите процессор
Для 1С важнее частота ядра, чем их количество. Значительная часть операций (проведение документа, расчёт в запросе) выполняется одним потоком, поэтому процессор с высокой тактовой частотой на ядро даст больше, чем многоядерный, но медленный чип. Ориентируйтесь на современные серверные процессоры с частотой от 3 ГГц и выше по базовой частоте.
По числу ядер рабочие ориентиры такие: до 20 пользователей — 8 ядер, 20–50 пользователей — 12–16 ядер, 50–100 — 16–24 ядра. Помните, что лицензирование MS SQL Server привязано к ядрам, поэтому чрезмерное количество ядер резко удорожает проект без пропорционального выигрыша. Часто выгоднее взять меньше быстрых ядер, чем больше медленных.
При виртуализации выделяйте виртуальные процессоры без избыточного резервирования (overcommit): для нагруженного сервера 1С отношение vCPU к физическим ядрам не должно превышать 1:1–2:1, иначе возникнут задержки планирования, которые пользователи почувствуют как подвисания.
Шаг 5. Спроектируйте дисковую подсистему
Диски — самая недооценённая часть сервера под 1С. Требование простое: база данных должна лежать на SSD, лучше на NVMe-накопителях с высокой выносливостью (DWPD от 1 и выше для активных баз). SATA SSD допустимы для небольших баз, но дешёвые потребительские SSD без защиты от отключения питания на сервере использовать нельзя — при сбое питания рискуете потерять данные.
Разделяйте нагрузку: файлы данных и журнал транзакций СУБД желательно размещать на разных физических массивах. Журнал транзакций пишется последовательно и интенсивно, и его конкуренция с чтением данных заметно снижает производительность. Для резервных копий подойдут более ёмкие и медленные диски или отдельное хранилище.
Объём закладывайте с расчётом: размер базы × 2–3 (сама база, tempdb, бэкапы на диске, пространство для операций обслуживания вроде реиндексации). Для базы 150 ГБ это означает 400–500 ГБ полезного пространства на массиве базы данных.
Шаг 6. Проверьте расчёт и типовые ошибки
После запуска сервера расчёт нужно подтвердить мониторингом. Ключевые признаки недостатка ресурсов: утилизация CPU выше 70–80% в рабочие часы, свободной памяти меньше 10%, дисковая очередь стабильно выше 2, время отклика на типовые операции растёт к концу дня. Замеры делайте минимум неделю, включая пиковые дни закрытия периода.
Полезная проверка до покупки — тест на эталонной нагрузке. Существуют методики оценки производительности конфигураций 1С, позволяющие сравнить сервер с референсными показателями. Если планируете крупное внедрение, прогоните тестовую базу на арендованном сервере аналогичной конфигурации — это дешевле, чем ошибиться с закупкой.
Как проверить, что сервер рассчитан верно
Стабильно ниже 70%
Длительные периоды выше 85–90%
Не менее 10% от общего объёма
Активный свопинг, менее 5% свободно
В среднем до 2
Постоянно выше 2–4, растёт время отклика диска
Стабильно в течение дня
Заметная деградация к вечеру или в дни отчётности
Что важно запомнить
Расчёт сервера под 1С сводится к четырём шагам: посчитать пиковое число пользователей и объём базы, заложить 0,5–1 ГБ RAM на пользователя плюс память под кэш СУБД, выбрать процессор с высокой частотой ядра и поставить базу на серверные SSD/NVMe. Добавьте запас 30–50% на рост и подтвердите расчёт мониторингом после запуска.
Частые вопросы
Сколько пользователей потянет сервер с 64 ГБ RAM?
Зависит от конфигурации и размера базы. Для смешанной нагрузки (Бухгалтерия, ЗУП) с базой до 50–80 ГБ такой сервер обычно обслуживает 30–50 одновременных пользователей при условии SSD-дисков и грамотного распределения памяти между кластером 1С и СУБД. Для ERP с базой 200+ ГБ этого объёма уже недостаточно — память уйдёт под кэш СУБД.
Можно ли развернуть 1С на виртуальной машине?
Да, виртуализация — распространённая практика. Условия: резервируйте память виртуальной машины полностью (без ballooning и overcommit), выделяйте vCPU не больше, чем есть физических ядер с учётом других нагруженных ВМ, и размещайте виртуальные диски базы на быстром хранилище. Нарушение этих условий — главная причина «тормозов» 1С в виртуальных средах.
Что выбрать: MS SQL Server или PostgreSQL?
Обе СУБД поддерживаются платформой 1С. MS SQL Server проще в типовом администрировании и чаще встречается в инфраструктуре, но требует лицензий по ядрам. PostgreSQL бесплатен, но требует более внимательной настройки и опыта. По производительности при грамотной настройке обе справляются с нагрузкой среднего предприятия.
Нужен ли отдельный сервер под веб-публикации и сервисы 1С?
Для небольших внедрений веб-сервер можно разместить на том же сервере, что и кластер 1С. Если через веб-сервисы идут интеграции с внешними системами (сайт, мобильные приложения) или публикация открыта наружу, веб-компоненты лучше вынести на отдельную машину в демилитаризованной зоне — это требование безопасности, а не производительности.
Как понять, что существующий сервер уже не справляется?
Тревожные признаки: рост времени проведения документов и формирования отчётов при том же объёме работы, жалобы пользователей именно в пиковые часы, утилизация CPU или памяти выше 80% в рабочее время, дисковые очереди на массиве базы. Подтвердите диагноз мониторингом за 1–2 недели, прежде чем планировать апгрейд — иногда проблема решается настройкой СУБД, а не заменой железа.
Есть ли смысл брать сервер с большим запасом «на вырост»?
Запас нужен, но разумный: 30–50% сверх текущего расчёта. Покупка сервера вдвое мощнее необходимого означает замороженные деньги и переплату по лицензиям СУБД. Правильнее выбрать платформу, позволяющую нарастить память и диски без замены сервера целиком.