Сколько ядер и памяти нужно серверу 1С: расчёт по числу пользователей

Ориентировочно: на 10 активных пользователей типовой конфигурации (Бухгалтерия, Зарплата) хватает 4-6 ядер CPU и 8-16 ГБ RAM, на 30-70 — 8-16 ядер и 32-64 ГБ, на 100+ или ERP — от 32 ядер и от 128 ГБ с отдельным сервером СУБД. Точная цифра зависит от типа нагрузки и конфигурации.

Почему 1С тормозит, даже когда сервер выглядит мощным

Проблема редко в характеристиках сервера как таковых — 8 ядер и 32 ГБ звучат солидно на бумаге. Тормоза начинаются, когда конфигурацию считают по общей численности сотрудников, а не по числу активных пользователей 1С — тех, кто одновременно проводит документы, формирует отчёты и участвует в обменах. Из 50 человек в штате одновременно в базе работают 15-20, и именно эта группа создаёт пиковую нагрузку на кластер серверов 1С в конкретный момент времени.

Второй источник тормозов — тип нагрузки, а не только её объём. Пользователь, вносящий документы весь день, нагружает процессор иначе, чем тот, кто раз в сутки формирует отчёт по остаткам за год по всей номенклатуре. Конфигурации на базе БСП — ERP, Комплексная автоматизация, Управление торговлей 11 — требовательнее к ресурсам, чем простая Бухгалтерия или Зарплата: больше фоновых регламентных заданий, сложнее расчёт себестоимости, тяжелее блокировки при параллельном проведении документов одного вида.

Третий фактор — архитектура развёртывания. В клиент-серверном варианте нагрузка делится между сервером приложений (кластер 1С, процессы rphost) и сервером СУБД — MS SQL Server или PostgreSQL. Если оба компонента стоят на одной машине без запаса памяти, кластер и СУБД начинают конкурировать за одни и те же ядра в часы пик — и тормозит всё сразу, даже при формально приемлемых характеристиках железа.

Как рассчитать ядра и память сервера 1С по числу пользователей

Расчёт строится на трёх переменных: число одновременно активных сессий, доля тяжёлых операций (отчёты, обмены, регламентные задания) и тип СУБД. Официальные системные требования 1С задают только нижнюю границу — минимум, при котором платформа запускается, а не комфортно работает под реальной нагрузкой в рабочие часы.

Ниже — ориентировочные нормативы для типовых конфигураций (Бухгалтерия, Зарплата и управление персоналом, Управление торговлей) в клиент-серверном варианте на MS SQL Server или PostgreSQL. Для ERP и Комплексной автоматизации закладывайте следующую ступень по ядрам и памяти — фоновая нагрузка там выше при том же числе пользователей. Файловый вариант базы в эту таблицу не укладывается вообще: он не рассчитан на 10 и более одновременных подключений независимо от мощности железа.

Отдельно стоит развести два числа: количество приобретённых лицензий 1С и количество одновременно работающих пользователей. Лицензий может быть 60, а одновременно в базе — 18-22 в обычный день и до 35 в день закрытия месяца. Расчёт ядер и памяти ведите по пиковому значению, а не по среднему — иначе именно в день закрытия сервер гарантированно не справится.

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

Как исправить конфигурацию сервера, если он уже не справляется

Признаки, что ресурсов не хватает именно сейчас: документы проводятся заметно дольше обычного, при закрытии месяца сервер зависает на 20-30 минут, в консоли кластера растёт очередь по процессам rphost, СУБД периодически возвращает ошибки блокировки при параллельной работе нескольких пользователей с одним документом.

Прежде чем добавлять ядра и память, стоит проверить пять вещей:

• ✓Разнесены ли кластер 1С и СУБД по разным серверам — на одной машине они конкурируют за ядра именно в пиковые часы, когда нагрузка от обоих компонентов максимальна одновременно.
• ✓Настроено ли несколько рабочих процессов rphost с лимитом по памяти и по количеству соединений на процесс — один процесс на все сессии создаёт искусственную очередь даже при свободных ресурсах.
• ✓Использует ли СУБД доступную память — параметр max server memory в MS SQL Server или shared_buffers в PostgreSQL по умолчанию занижен и не позволяет задействовать всю установленную RAM.
• ✓Обновлялась ли статистика и переиндексация таблиц — на растущей базе без регулярного регламентного обслуживания сервер тормозит на операциях чтения даже при запасе по ядрам.
• ✓Добавляются ли ресурсы точечно, под конкретное узкое место, а не пропорционально всей конфигурации — часто достаточно увеличить память под кэш процессов, не трогая число ядер.

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

Что делать, если тормозов не становится меньше после апгрейда

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

Дисковая подсистема. Для tempdb в MS SQL Server и для журналов транзакций в PostgreSQL важны не ядра, а скорость и число операций ввода-вывода в секунду. На HDD или медленном сетевом хранилище даже 32 ядра не спасают от тормозов при интенсивной записи.

Неоптимизированный код и запросы. Тяжёлые обработки, отчёты без отбора по индексам или доработки, написанные без учёта блокировок, нагружают сервер вне зависимости от его мощности — проблему решает не апгрейд, а оптимизация конкретного запроса или обработки.

Сеть между сервером приложений и СУБД. Если они физически разнесены, а канал между ними медленный или перегружен, каждое обращение к базе добавляет задержку, которая ощущается пользователем как тормоза 1С, хотя оба сервера по отдельности не загружены.

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

Проверить гипотезу просто: прогоните тест Гилёва после апгрейда. Если баллы выросли пропорционально новым ядрам, а пользователи по-прежнему жалуются — дело не в железе, и следующий шаг это профилирование запросов, а не покупка ещё более мощного сервера. Для баз на ERP и Комплексной автоматизации, где нагрузка изначально выше, есть смысл сразу рассматривать сервер под 1С:ERP — там конфигурация и дисковая подсистема подобраны под характерную для ERP нагрузку, а не универсально.

Как предотвратить нехватку ресурсов при росте числа пользователей

Типовая ошибка — считать конфигурацию под сегодняшнюю численность и не закладывать резерв. Штат растёт, к базе подключают новые обмены и внешние сервисы, добавляются регламентные задания — и через полгода сервер, который справлялся идеально, снова начинает тормозить в пиковые часы.

Рабочий подход: закладывать резерв 20-30% по ядрам и памяти сверх текущего расчёта и раз в квартал сверяться с загрузкой через консоль кластера — сколько процессов rphost активно в пиковые часы и сколько памяти они реально потребляют. Сезонные всплески — закрытие периода, инвентаризация, сдача отчётности — стоит закладывать отдельно: в эти дни нагрузка кратно выше обычной.

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

Мы рассчитываем конфигурацию сервера под 1С исходя из числа активных пользователей и типа конфигурации, проверяем результат тестом Гилёва и сдаём сервер в работу с запасом под рост. Аренда стоит от 3300 руб./мес — итоговая цена зависит от ядер, памяти и СУБД. Если нужна разовая диагностика уже работающего сервера или тонкая настройка под нагрузку, это отдельная услуга сопровождения — от 3800 руб./час.

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

Хватит ли 4 ядер и 8 ГБ памяти для 15 пользователей 1С?

На практике нет — таких ресурсов достаточно примерно для 5-8 активных пользователей типовой конфигурации. Для 15 человек нужно 6-8 ядер и 16-32 ГБ, иначе при одновременном проведении документов сервер начнёт ставить операции в очередь.

Почему для ERP нужно в 2-3 раза больше ресурсов, чем для Бухгалтерии?

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

Можно ли рассчитать нагрузку без теста Гилёва?

Можно ориентироваться на таблицу по числу пользователей, но тест Гилёва даёт объективную цифру производительности конкретного железа — без него расчёт остаётся приблизительным, особенно при смешанной нагрузке из проведения и тяжёлых отчётов.

Что выгоднее — сразу взять сервер с запасом или расширять по мере роста?

При аренде выгоднее не переплачивать заранее: конфигурацию виртуального сервера можно увеличить за часы без простоя, поэтому логичнее стартовать с расчёта под текущее число пользователей и закладывать резерв 20-30%, а не покупать мощности на годы вперёд.

Сколько стоит аренда сервера под 1С с нужной конфигурацией?

От 3300 руб/мес — стоимость зависит от числа ядер, объёма памяти и типа СУБД под конкретную конфигурацию 1С. Донастройка кластера и СУБД под нагрузку считается отдельно, от 3800 руб/час.