Для 1С не существует универсальной конфигурации «на 50, 100 или 300 пользователей». На требуемые CPU, RAM и СХД влияют версии платформы и конфигурации, число одновременно активных пользователей, характер операций, регламентные задания, СУБД, объём данных и допустимое время отклика. Подбор начинается с профиля нагрузки, а заканчивается проверкой производительности на тестовом стенде.
Исследовательская база: преимущественно 2020–2026 годы · Дата проверки исходных материалов: · Характеристики оборудования и поддерживаемые версии ПО необходимо сверять перед закупкой.
Как устроена клиент-серверная 1С
В клиент-серверном варианте «1С:Предприятия» работают три логических уровня: клиентское приложение, кластер серверов 1С и сервер базы данных. Клиент обращается к серверу приложений, а сервер приложений — к СУБД. Эти роли допустимо размещать совместно или раздельно, но их нагрузка различается. Основа — описание архитектуры 1С .
| Уровень | Основная задача | Что измерять |
|---|---|---|
| Клиенты (тонкий, толстый, веб) | Пользовательский интерфейс, ввод данных, клиентские вызовы | Количество и тип сеансов, время отклика, RDS/web-нагрузка |
| Кластер серверов 1С | Бизнес-логика, вызовы, rphost, фоновые и регламентные задания | CPU per-core и суммарно, RAM процессов, количество вызовов, concurrency |
| Сервер СУБД | Запросы, буферный кэш, транзакции, индексы, журналы и временные операции | CPU, память, SQL waits, IOPS, latency, блокировки, журнал/WAL |
Терминальный сервер (RDS) обслуживает пользовательские сеансы и клиентские процессы, но не заменяет кластер серверов 1С. Веб-клиент может добавлять отдельный веб-уровень. Их ресурсы рассчитывают отдельно.
Профиль пользователей и операций
Количество зарегистрированных пользователей, число лицензий, одновременных сеансов и число пользователей, которые одновременно выполняют тяжёлые операции, — разные показатели. Для расчёта нужны не просто «100 пользователей», а их действия, частота и пиковые периоды. Это прямо следует из методики расчёта 1С и анализа пользовательских сценариев .
| Роль / сценарий | Характер нагрузки | Что спросить у заказчика |
|---|---|---|
| Операционный пользователь | Ввод, проведение, поиск документов | Документов в час, строк в документе, параллельное проведение |
| Отчёты и аналитика | Тяжёлые выборки, группировки, временные структуры | Какие отчёты, за какой период, как часто, сколько одновременно |
| Расчёт и закрытие месяца | Циклические пики, массовое перепроведение, блокировки | Время расчёта зарплаты/себестоимости и целевое окно завершения |
| Интеграции и фоновые задания | Обмены, API, пакетные обработки, регламентные операции | Частота, расписание, объём и пересечение с рабочим временем |
Например, 70 пользователей с тяжёлым закрытием месяца могут создавать существенно более высокую пиковую нагрузку на СУБД, чем 150 пользователей, редко выполняющих ресурсоёмкие операции. Это иллюстрация различий профилей , а не формула «на пользователя».
Время отклика, APDEX и тестирование
Оборудование нужно выбирать под измеримые требования к конкретным операциям. Фирма 1С использует методику APDEX: выделяют ключевые операции, задают для них целевое время выполнения и оценивают фактические результаты. Число пользователей без целевого времени отклика не определяет производительность. См. методику APDEX .
| Бизнес-операция | Что фиксируем | Как проверяем |
|---|---|---|
| Открытие формы, создание документа | Целевое время и p95 фактического отклика | Тест реалистичного пользовательского сценария |
| Проведение документа | Время, блокировки, SQL-вызовы | Замеры в технологическом журнале 1С |
| Построение тяжёлого отчёта | Время отчёта, объём данных, число одновременных запусков | Нагрузочный тест с приближённой к реальной базой |
| Закрытие периода | Допустимое окно, объём операций, параллелизм | Отдельный сценарий тестирования расчётного пика |
Требуемое время проведения документа, расчёта зарплаты или формирования отчёта задаёт заказчик. Универсального числа «операция 1С обязана выполняться за X секунд» нет.
Сервер приложений и сервер базы данных
Кластер 1С исполняет бизнес-логику, управляет сеансами и процессами rphost, обрабатывает фоновые задания. СУБД выполняет запросы, хранит буферные страницы, обслуживает транзакции и временные операции. Поэтому CPU, RAM и дисковая подсистема для этих ролей рассчитываются отдельно .
| Схема | Преимущества | Риски и ограничения |
|---|---|---|
| Один сервер для 1С и СУБД | Меньше инфраструктуры, нет сетевого перехода app↔DB | Конкуренция за CPU/RAM, общая точка отказа, сложнее независимое масштабирование |
| Раздельные серверы/ВМ | Независимая RAM/CPU СУБД, проще диагностика и рост | Требуется надёжная сеть, больше узлов и администрирования |
| Несколько серверов приложений | Горизонтальное расширение по пользовательским и фоновым нагрузкам | Настройка кластера и балансировки; не устраняет узкое место СУБД |
Фирма 1С предупреждает о накладных расходах избыточного числа процессов rphost. Больше процессов не гарантирует пропорционального прироста производительности. Необходимо также оставлять RAM для перезапуска или замены процесса. Источники: настройка рабочих серверов и использование памяти rphost .
Процессор: частота, ядра и производительность
Для части последовательных операций 1С критична производительность одного ядра (single-thread/per-core) ; для одновременного обслуживания множества вызовов и фоновых заданий — достаточное число ядер. Официальная методика 1С требует учитывать обе характеристики. Частота в ГГц сама по себе не позволяет сравнивать разные поколения процессоров.
| Критерий CPU | Что он даёт | Где важен |
|---|---|---|
| Производительность на ядро | Скорость последовательного участка приложения или запроса | Интерактивные операции и цепочки server code → SQL → result |
| Физические ядра | Совокупная параллельная производительность | Множество активных пользователей, фоновые задания, несколько ИБ |
| Архитектура и кэш | Выполнение инструкций за такт, работа с данными | Сравнение CPU при одинаковой частоте |
| NUMA и пропускная способность памяти | Задержки доступа, локальность памяти | Крупные СУБД и большие виртуальные машины |
| Лицензии и платформа | Стоимость и совместимость выбранной схемы | Лицензируемые по ядрам СУБД и виртуализация |
Два CPU с одинаковыми 3,5 ГГц могут существенно различаться по производительности. Для выбора используйте тесты выбранной 1С-конфигурации либо сопоставимые независимые тесты с учётом поколения, памяти, числа потоков и длительной загрузки. Не существует подтверждённого правила «для 1С всегда нужно не менее 3,5 ГГц».
Оперативная память двух серверных ролей
Сервер приложений потребляет память на процессы rphost, сеансы, объекты бизнес-логики, кэши и фоновые операции. Сервер СУБД — на буферный кэш, планы и рабочую память запросов, сортировки, временные данные и обслуживание соединений. Нельзя рассчитывать обе роли по одной норме ГБ на пользователя.
| Роль | Источники потребления RAM | Что важно при подборе |
|---|---|---|
| 1С / rphost | Количество процессов, соединений, сеансов, отчётов, фоновых заданий | Пиковый Private Bytes/working set, запас на restart rphost |
| Microsoft SQL Server | Buffer pool, query memory, tempdb, ОС | Настройка max server memory, запас RAM для остальных служб |
| PostgreSQL-family | shared_buffers, work_mem по нескольким операциям, соединения, OS cache | Контроль общего потребления памяти и числа соединений |
| Виртуализированная схема | ОС, гипервизор, процессы 1С/СУБД, резерв после отказа | Memory contention, overcommit, NUMA и HA reserve |
Старая методика 1С приводит грубые усреднённые объёмы RAM на пользователей, но сама указывает ограниченную точность. Для современной ERP или доработанной конфигурации они не подходят в качестве готовой спецификации .
Диски: IOPS, latency и журнал транзакций
Дисковая подсистема СУБД может быть основным ограничителем производительности 1С. Важно разделять ёмкость и скорость операций ввода-вывода. Заявленная скорость SSD в ГБ/с не характеризует работу небольших случайных запросов, идущих параллельно.
| Вид I/O | Типичная нагрузка | Критические показатели |
|---|---|---|
| Файлы данных БД | Random read/write; часть операций обслуживается кэшем | IOPS, средняя и p95/p99 latency, размер блока |
| Transaction log / PostgreSQL WAL | Подтверждение транзакций и запись журнала | Стабильная write/fsync latency, надёжность записи |
| tempdb / временные файлы | Отчёты, сортировки, hash join, временные таблицы | Пиковые IOPS/throughput, свободный объём, задержка |
| Резервные копии | Последовательные чтения/записи, нагрузка на инфраструктуру | Throughput, временное окно, доступный объём |
| Текущие данные и рост | Объём базы, индексы, журнал, snapshots, maintenance | Полезная ёмкость, прогноз роста и запас |
Enterprise SSD и NVMe часто помогают при высокой чувствительности к latency и random I/O, но NVMe не является обязательным требованием платформы 1С . RAID выбирают по профилю записи, отказоустойчивости, контроллеру, стоимости полезной ёмкости и времени восстановления. RAID не заменяет резервное копирование.
База на 50 ГБ может работать медленно из-за неэффективных запросов и блокировок, а база на 2 ТБ — быстро при небольшом активном наборе данных. Это иллюстрация зависимости от нагрузки, а не сравнение конкретных систем.
СУБД: Microsoft SQL Server и PostgreSQL
Для 1С существуют разные поддерживаемые СУБД. Нельзя объявлять Microsoft SQL Server или PostgreSQL «всегда более быстрым»: итог зависит от конфигурации, версии, данных, настроек, запросов и оборудования. Актуальный список продуктов и версий опубликован в матрице поддержки 1С .
| Вопрос | Microsoft SQL Server | PostgreSQL / Postgres Pro для 1С |
|---|---|---|
| Память | Важно ограничить max server memory, оставив ресурс ОС и 1С | Учитывать shared_buffers, work_mem, число соединений, OS cache |
| Транзакционный журнал | Latency и размещение transaction log | Latency WAL/fsync и параметры checkpoint |
| Временная нагрузка | tempdb, планы запросов, конкуренция | Temporary files, work_mem, сложные запросы |
| Параметры настройки | Рекомендации 1С 2019 года сверять с версией SQL Server и нагрузкой | Рекомендации 1С от 19.06.2025 — стартовые, требуют tuning |
| Совместимость | Проверять конкретную ОС, версию СУБД и редакцию платформы 1С | Проверять версию с патчами 1С и матрицу ОС для выбранной сборки |
Важные ограничения совместимости
- Рабочие серверы кластера 1С под Linux, согласно официальной странице многоплатформенности 1С , не могут взаимодействовать с Microsoft SQL Server. Для проекта сверяйте это ограничение с конкретной версией платформы.
- Указание «PostgreSQL поддерживается 1С» не означает поддержки любой сборки PostgreSQL на любой ОС. Проверяется связка «платформа 1С → СУБД и патч → версия СУБД → ОС».
- Рекомендация 1С «MAXDOP=1» из документа для MS SQL Server 2019 года не является общим нормативом для любого приложения и версии SQL Server.
- Рекомендация 1С/Postgres Pro отключать Hyper-Threading относится к соответствующему профилю PostgreSQL + 1С, а не ко всем без исключения серверам приложений 1С.
- В методике PostgreSQL от 19.06.2025 прямо указано: параметры индивидуальны. Autovacuum не следует отключать — это ведёт к накоплению необработанных данных и ухудшению работы.
Виртуализация серверов 1С
Сервер приложений и СУБД можно размещать на виртуальных машинах при соблюдении требований поддержки и производительности. Дополнительные риски: CPU Ready/steal, конкуренция за RAM, NUMA/vNUMA, соседние ВМ, перегрузка общего хранилища и задержки в сети.
- Не задавайте фиксированный CPU overcommit без измерения нагрузки приложения и базы данных.
- Для latency-sensitive СУБД контролируйте реальное CPU contention и доступность RAM, особенно после отказа узла.
- Раздельно учитывайте ресурсы терминальных серверов, веб-уровня и резервного копирования.
- Проверяйте совместимость конкретной версии гипервизора, ОС сервера 1С и СУБД.
Подробная инженерная методика — в материале «Сервер для виртуализации: CPU, RAM, СХД и HA» .
Отказоустойчивость не равна резервной копии
Кластер серверов 1С может обеспечивать резервирование процессов и узлов, но он не делает автоматически отказоустойчивыми СУБД, сетевую инфраструктуру или хранилище. Отдельно проектируются доступность СУБД, репликация, backup, проверки восстановления, RPO и RTO.
| Механизм | Что защищает | Чего не гарантирует |
|---|---|---|
| Кластер 1С | Работу серверного уровня платформы | Автоматическую защиту единственного сервера БД |
| Кластер/репликация СУБД | Доступность данных при отказе части DB-компонентов | Резервную копию от логических ошибок и вредоносного ПО |
| RAID/SAN redundancy | Отказ отдельных дисков или путей — в рамках архитектуры | Восстановление удалённых/испорченных данных |
| Backup и тест восстановления | Возможность вернуть данные к точке восстановления | Мгновенное переключение работы без простоя |
Уровни HA выбирают по критичности операций и допустимому простою. В документации кластера 1С описаны механизмы отказоустойчивости; однако повышение уровня резервирования может увеличивать накладные расходы.
Как рассчитать производительность сервера
Официальная методика 1С использует измерения эталонной системы. Для сопоставимого многопользовательского внедрения расчёт условной потребности в физических ядрах задаётся формулой:
tCPU = mCPU × (mPT / 100) × (tU / mU)
mCPU — физические ядра эталонного сервера; mPT — его средняя загрузка CPU в процентах; mU — число активных пользователей эталона; tU — число активных пользователей целевой системы; tCPU — условное количество требуемых физических ядер.
Эта схема применима лишь при сопоставимости конфигурации, операций, СУБД, версии платформы и характера нагрузки. Она не включает автоматически требуемый запас производительности, смену CPU-архитектуры, пики закрытия месяца или HA. При отсутствии эталона создают тестовую базу и моделируют ключевые сценарии.
Условный расчёт — не готовая спецификация
Предположим: эталонный сервер с 16 физическими ядрами при 100 одновременно активных пользователях загружен в среднем на 50%. Для 150 пользователей с тем же профилем операций расчётная потребность составит 16 × 0,5 × 150 / 100 = 12 условных ядер . Это только масштабирование измеренной средней нагрузки; для покупки нужно проверить пиковые операции, скорость одного ядра и запас. Числа являются иллюстрацией формулы, а не рекомендацией оборудования.
В официальном руководстве по расчёту описаны также расчёты RAM и дисковой системы по эталону. Для циклической нагрузки (зарплата, закрытие периода) параметры определяются для каждой фазы, затем выбирается наибольшая потребность.
Мониторинг и поиск реального узкого места
Перед покупкой сервера собирают измерения в обычный период и во время пиковой нагрузки. В методике мониторинга 1С от 01.08.2025 используются технологический журнал, системные счётчики и инструменты анализа производительности. См. «Мониторинг на продукционных серверах» .
| Признак | Возможная причина | Что проверять сначала |
|---|---|---|
| Высокая CPU app в момент задержки | Вычисления серверного кода, недостаточная производительность ядра | CpuTime событий CALL, загрузка процессов 1С |
| Высокая доля DBMSSQL/DBPOSTGRS | SQL-запросы, индексы, ожидания | Планы запросов, DB waits, время SQL и блокировки |
| Дисковые задержки растут с очередью | Недостаточная IOPS/latency СХД | Read/write latency, queue depth, tempdb, WAL |
| RAM исчерпана, swap/pressure | Нехватка памяти или настройки процесса/СУБД | Private Bytes rphost, DB cache, память ОС |
| Тормозит одна операция при свободном CPU | Неэффективный алгоритм, сериализация, lock contention | Технологический журнал, TLOCK/TTIMEOUT/TDEADLOCK и запросы |
Апгрейд оборудования не исправляет плохой запрос, блокировки и неэффективную бизнес-логику. Если CPU и диски не загружены, но одна операция выполняется медленно, сначала нужен анализ кода и СУБД, а не покупка более мощного сервера. Источник: методика поиска блокировок 1С .
Ошибки при выборе сервера для 1С
- «100 пользователей — значит, достаточно 8 ядер и 32 ГБ RAM» — игнорирование состава операций и фазы пиков.
- «Чем больше ядер, тем быстрее любая операция» — не учитывается производительность отдельного ядра.
- «У CPU частота выше, значит он быстрее» — частоты без архитектуры и измерений несопоставимы.
- «Сервер 1С и сервер СУБД можно считать одинаково» — разные нагрузки и архитектура памяти.
- «NVMe исправит торможение 1С» — при lock contention или неоптимальном SQL диски не решают проблему.
- «Для 1С всегда нужен RAID10» — выбор зависит от записи, latency, стоимости и отказоустойчивости.
- «PostgreSQL любой версии работает на любом Linux» — нужны конкретные совместимые версии и сборки.
- «Загрузим RAM на 100%» — не останется ресурсов для rphost, SQL, пиков и резервирования.
- «Если кластер 1С отказоустойчив, то и данные в безопасности» — СУБД и backup требуют отдельных решений.
- «Минимальные системные требования 1С — достаточная конфигурация для крупной системы» — они не учитывают прикладное решение и нагрузку.
Чек-лист для запроса КП
Программная среда
- Версия платформы и конфигурации 1С
- Типовая или доработанная конфигурация
- ОС серверов приложений и СУБД
- Название, версия и сборка СУБД
Пользователи и пики
- Одновременно активные пользователи
- Основные роли и операции/час
- Закрытие месяца, зарплата, отчёты
- Регламентные задания и интеграции
Измеренные ресурсы
- CPU app и DB: avg/p95/peak
- RAM rphost и DB working set
- Read/write IOPS, latency, log/WAL
- Размер базы, рост и temp-операции
Надёжность и проект
- Физический сервер или виртуальные машины
- Допустимые RPO/RTO и HA
- Окно backup, проверка восстановления
- Совместимость модели, BOM и реестр
Конкретная модель РАМЭК и конфигурация (BOM), её действующая запись в реестре, совместимость с версией ОС/гипервизора/СУБД и условия сервиса проверяются отдельно. Этот исследовательский материал не является подтверждением характеристик или реестрового статуса конкретной модели.
Первичные источники
Подборка официальных материалов, на которых основаны инженерные выводы. Методики прошлых лет представлены как методики, а не как обязательные аппаратные нормы 2026 года. Для конкретного проекта всегда открывайте матрицу совместимости на дату закупки.
- 1С — клиент-серверный вариант работы
- 1С — расчёт параметров серверного оборудования (2015)
- 1С — анализ пользовательских сценариев
- 1С — инструкция по настройке рабочих серверов (2022)
- 1С — оценка производительности по APDEX
- 1С — аппаратные требования платформы
- 1С — поддерживаемые СУБД и версии
- 1С — матрица ОС для PostgreSQL-family
- 1С — PostgreSQL tuning (19.06.2025)
- 1С — MS SQL Server checklist (2019)
- 1С — особенности многоплатформенности
- 1С — мониторинг на продукционных серверах (2025)
- 1С — диагностика блокировок
- 1С — использование памяти rphost
- Postgres Pro — настройка сервера для 1С
- 1С — реальные внедрения (исторические примеры)