Сколько пользователей выдержит сервер 1С: точный расчёт мощности
2026-04-29 09:17
Правильный подбор аппаратных ресурсов напрямую определяет стабильность работы учетной системы. Ошибка в расчетах приводит либо к неоправданным затратам на избыточное железо, либо к постоянным жалобам персонала на медленный отклик.
Чтобы понять, сколько пользователей выдержит конкретный сервер, необходимо учитывать не только их количество, но и интенсивность работы с базой данных.
Почему нельзя ответить «в лоб»: переменные, влияющие на нагрузку
Производительность 1С - это динамическая величина. Она зависит от того, насколько эффективно платформа взаимодействует с СУБД и операционной системой. Один и тот же физический узел может показывать разную скорость в зависимости от настроек регламентных заданий и чистоты кода конфигурации.
Разница между «подключёнными» и «активными» пользователями
Для адекватного планирования мощностей важно использовать сегментированный подход к анализу аудитории:
Общее число сотрудников. Все специалисты, за которыми закреплены лицензии. Они редко создают нагрузку одновременно.
Спящие сессии. Сеансы, которые открыты, но не выполняют вычислений. Они практически не нагружают CPU, но удерживают объем оперативной памяти (от 200 до 500 МБ на сеанс).
Активные пользователи. Те, кто в данный момент проводит документы или строит отчеты. Именно на них ориентируется расчет процессорных мощностей.
Пиковая нагрузка. Момент, когда предприятие работает на пределе (например, утро понедельника или отчетный период), когда число активных сессий максимально.
Как тип конфигурации 1С (БП, УТ, ERP, ЗУП) меняет профиль нагрузки
Конфигурации на платформе 1С:Предприятие имеют разную ресурсоемкость. «Бухгалтерия предприятия» (БП) характеризуется редкими, но тяжелыми операциями закрытия периода. В то время как «ERP» требует значительно больше вычислительных мощностей из-за сложности алгоритмов планирования и большого количества фоновых заданий, которые нагружают sql-движок.
Влияние объёма информационной базы, сложности документов и регламентных операций
Чем больше объем базы, тем выше нагрузка на дисковую подсистему при поиске и чтении. Сложные документы с сотнями строк табличной части требуют длительного времени на проведение и блокируют таблицы в sql. Регламентные операции, такие как индексация или пересчет итогов, могут парализовать работу пользователей, если у сервера нет запаса производительности.
Базовая методика расчёта: от сценария использования к ресурсам
Расчет начинается с определения минимальных требований для комфортной работы одного специалиста. Затем эти данные масштабируются с учетом коэффициентов совместной нагрузки.
Процессор. Минимум 1 ядро с частотой от 3.0 ГГц на каждые 8–10 активных сессий.
Память. От 500 МБ до 1 ГБ на сеанс + буфер под операционную систему.
СУБД. Выделение до 60–80% всей доступной памяти под кэш базы данных.
Диски. Использование только SSD корпоративного класса с высоким ресурсом записи.
Формула расчёта нагрузки на процессор: ядра, частота и коэффициент параллелизма
Частота процессора критична для однопоточных операций (например, проведение одного документа). Однако для одновременной работы многих сотрудников важно количество ядер. При расчете учитывается коэффициент параллелизма: чем больше количество ядер, тем меньше вероятность возникновения очередей к CPU.
Для расчета необходимой суммарной частоты (GHz_total) можно использовать базовую зависимость:
GHz_total = (N_active × GHz_per_user) × K_par
Где:
N_active - количество активных пользователей;
GHz_per_user - требуемая частота на одного пользователя (обычно 0.1–0.2 ГГц);
K_par - коэффициент параллелизма (обычно от 1.1 до 1.3), учитывающий накладные расходы на переключение контекста процессора.
Расчёт оперативной памяти: формула на пользователя + буфер под СУБД и кэш
Общий объем необходимой RAM вычисляется как сумма памяти для работы ОС (4–8 ГБ), кэша sql (зависит от размера активных данных) и памяти для сеансов пользователей. Если работать в терминальном режиме, потребление памяти на стороне сервера возрастает, так как он берет на себя и отрисовку интерфейса.
Дисковая подсистема: IOPS, latency и пропускная способность в сценариях 1С
Для 1С критически важна скорость случайного доступа. Медленные диски создают «бутылочное горлышко», из-за которого процессор простаивает в ожидании данных. Профессиональные системы хранения данных позволяют достичь показателей задержки (latency) менее 1 мс.
Сетевые задержки: почему пинг >10 мс снижает воспринимаемую производительность
Для комфортной работы через удаленный рабочий стол или тонкий клиент задержка не должна превышать 10–20 мс. При локальном размещении в офисе пинг близок к нулю. Если же вы выбираете удаленный ЦОД, убедитесь, что задержки минимальны, иначе пользователи будут жаловаться на «замирание» интерфейса.
Сводная формула оценки максимального числа пользователей
Для предварительной оценки используется формула, учитывающая ограничивающий ресурс. Вы можете скопировать её для вставки в техническую документацию:
Разные программные продукты создают специфический профиль нагрузки на аппаратную часть.
Конфигурация
Нагрузка на CPU
Нагрузка на RAM
Нагрузка на Disk
Бухгалтерия (БП)
Низкая/Средняя
Средняя
Низкая
Управление торговлей (УТ)
Средняя
Средняя
Высокая (интенсивная запись)
ERP / УПП
Очень высокая
Высокая
Очень высокая
ЗУП
Пиковая (в дни з/п)
Средняя
Средняя
Бухгалтерия предприятия (БП): лёгкие транзакции, умеренная нагрузка на диск
Эта конфигурация считается одной из самых экономичных. Большую часть времени пользователи вводят первичную документацию, что не создает очередей к процессору. Основной всплеск активности происходит при формировании регламентированной отчетности.
Управление торговлей (УТ): средняя интенсивность, пиковые нагрузки при проведении документов
Здесь на первый план выходит скорость дисков. Большое количество отгрузок и заказов создает плотный поток транзакций. Если дисковая подсистема не справляется, проведение реализации может занимать несколько секунд вместо долей секунды.
ERP и комплексные автоматизации: высокая нагрузка на CPU и память, фоновые задания
В крупных системах один документ может порождать десятки записей в различных регистрах. Это требует огромных мощностей от сервера базы данных. При количестве сотрудников более 100 рекомендуется разделять роли на разные машины.
ЗУП и расчётные задачи: пиковая нагрузка в периоды начисления зарплаты
Особенность ЗУП - крайне неравномерная нагрузка. Весь месяц сервер может простаивать, но в дни расчета зарплаты и налогов нагрузка на CPU возрастает до 100% из-за сложных математических вычислений в многопоточном режиме.
Моделирование пиковых нагрузок и запас производительности
Расчет по средним показателям приведет к отказу системы в критические моменты.
Закрытие месяца, массовое проведение документов, выгрузка отчётов: как учесть в расчёте
При планировании ресурсов необходимо моделировать ситуацию, когда 80% сотрудников одновременно формируют тяжелые отчеты или проводят документы. В такие моменты потребление ресурсов процессора и дисковой очереди возрастает в 2.5–3 раза.
Коэффициент запаса: почему 20–30% резерва - необходимость, а не излишество
Аппаратная часть должна иметь свободную мощность для компенсации «всплесков» активности. Запас в 30% гарантирует, что при выходе из строя одного диска в RAID-массиве или в процессе фонового копирования базы данных, пользователи не заметят деградации скорости работы.
Прогнозирование роста: как заложить масштабирование при увеличении штата на 30–50%
Если ваша компания планирует расширение, выбирайте сервер для 1С с возможностью установки второго процессора и свободных слотов под ОЗУ. Это позволит масштабироваться вертикально без полной замены инфраструктуры через год.
Инструменты диагностики и сбора метрик для точного расчёта
Прежде чем проводить закупки, необходимо собрать данные о текущем потреблении ресурсов.
Журнал регистрации 1С: как анализировать время выполнения операций
Журнал позволяет выявить «узкие места» в коде конфигурации. Если проведение документа занимает более 2–3 секунд, это повод проверить настройки блокировок или производительность диска, на котором лежит файл данных.
Performance Monitor (Windows) и top/htop (Linux): ключевые счётчики для 1С
Системные утилиты позволяют мониторить длину очереди к диску (не должна превышать 2 на один физический диск) и утилизацию процессора. Если среднее значение CPU выше 70%, сервер работает на пределе возможностей.
Мониторинг СУБД: pg_stat_statements для PostgreSQL, DMV для MS SQL Server
Эти инструменты показывают самые ресурсоемкие запросы к базе. Оптимизация одного такого запроса может снизить нагрузку на сервер сильнее, чем покупка более мощного процессора.
Чтобы убедиться, что диски справляются, проводится замер IOPS в режиме случайного чтения и записи блоками по 4 КБ. Это наиболее близкий сценарий к тому, как работает 1С. Для баз с активной записью стоит использовать NVMe накопители корпоративного класса.
Практические примеры расчёта мощности
Рассмотрим типовые сценарии развертывания для разного масштаба организаций.
Пример 1. База БП на 25 пользователей, объём ИБ 15 ГБ, файловый режим
Для такого сценария достаточно процессора с 4 ядрами (высокая частота) и 32 ГБ оперативной памяти. Диски SSD (SATA или NVMe) обязательны, так как в файловом режиме блокировки особенно чувствительны к скорости записи.
Пример 2. УТ 11 на 60 пользователей, клиент-сервер, PostgreSQL, объём ИБ 80 ГБ
Здесь требуется 8–12 ядер и минимум 64–96 ГБ ОЗУ, чтобы большая часть базы помещалась в кэш. Дисковая подсистема должна быть собрана в RAID 10 для обеспечения высокой скорости чтения и записи.
Пример 3. Кластер 1С для 120 пользователей, разделение ролей, высокая доступность
Требуется разделение на сервер приложений и сервер баз данных. На каждом по 16+ ядер и 128+ ГБ памяти. Обязательно использование двухпортовых сетевых карт и дублирование всех узлов.
Типичные ошибки при оценке мощности и как их избежать
Ориентация только на количество пользователей без учёта сценариев работы
Это самая частая ошибка. 50 пользователей в режиме «просмотр отчетов» и 50 пользователей в режиме «ввод заказов» - это две разные конфигурации сервера. Всегда анализируйте тип операций.
Игнорирование дисковой подсистемы: почему медленный диск «убивает» даже мощный CPU
Если диск не успевает отдавать данные, процессор уходит в состояние iowait - он просто ждет. В итоге вы видите низкую загрузку CPU в мониторинге, но 1С при этом работает крайне медленно.
Отсутствие мониторинга в динамике: почему разовый замер недостаточно для планирования
Замер, сделанный в середине недели, не покажет нагрузку при закрытии месяца. Мониторинг должен длиться минимум один полный рабочий цикл (месяц), чтобы учесть все регламентные задачи.
Пошаговый чек-лист расчёта мощности сервера для 1С
Этап 1. Сбор данных о текущей нагрузке (если система уже работает)
Соберите метрики CPU, RAM и Disk за последние 30 дней. Определите часы пиковой активности и зафиксируйте максимальные значения потребления ресурсов.
Этап 2. Определение профиля пользователей и типовых операций
Разделите сотрудников на группы по интенсивности (активный ввод, отчеты, редкий просмотр). Присвойте каждой группе весовой коэффициент.
Этап 3. Расчёт ресурсов по каждому компоненту с учётом пиков и запаса
Используйте базовые формулы (ядро на 8–10 сессий, 1ГБ на сессию) и прибавьте к результату 30% на «запас прочности».
Этап 4. Валидация расчёта через нагрузочное тестирование или пилотное развёртывание
Перед финальной закупкой или переездом проведите тест. Можно использовать встроенный тест Гилева или специализированные инструменты для имитации многопользовательской работы.
Часто задаваемые вопросы (FAQ) по расчёту мощности сервера 1С
Как перевести «условных пользователей» в реальные требования к серверу?
Принимайте 1 «условного пользователя» за 1 ГБ ОЗУ и 0.1 ядра современного CPU. Но помните, что для ERP эти цифры нужно умножать на два.
Почему сервер «тормозит» при 50 пользователях, хотя по расчётам должен держать 80?
Проверьте настройки блокировок и план обслуживания SQL. Часто проблема кроется в фрагментации индексов или устаревшей статистике базы данных.
Влияет ли тип СУБД (PostgreSQL vs MS SQL) на количество поддерживаемых пользователей?
MS SQL лучше работает с памятью и имеет более продвинутый оптимизатор запросов, но требует дорогих лицензий. PostgreSQL - бесплатный аналог, который при правильной настройке выдает сопоставимую производительность.
Как учесть нагрузку от внешних интеграций (сайт, маркетплейсы, ЭДО)?
Каждая внешняя интеграция - это «виртуальный пользователь». Считайте каждое подключение через API как одну активную сессию с повышенным потреблением ресурсов CPU.
Можно ли использовать облачный сервер с «виртуальными ядрами» для точного расчёта?
С осторожностью. Виртуальные ядра (vCPU) могут быть переподписаны провайдером. Для 1С всегда запрашивайте выделенные (dedicated) ядра.
Как часто нужно пересчитывать мощность сервера при росте бизнеса?
Минимум раз в полгода или при каждом крупном обновлении конфигурации 1С, так как новые релизы часто становятся более требовательными к ресурсам.
Что делать, если расчёт показывает недостаточную мощность, но бюджет ограничен?
Оптимизируйте текущую базу: настройте свертку данных, очистите кэш и перенесите регламентные задачи на ночное время.
Как проверить расчёт на практике перед закупкой оборудования?
Возьмите аналогичный сервер в аренду на тест или разверните пробную версию в облаке. Это позволит на практике увидеть, как система ведет себя под вашей нагрузкой.