Пользователи сервера 1С: как понять, сколько сотрудников выдержит база

Количество пользователей сервера 1С зависит не от мощности «на бумаге», а от реальной нагрузки: типа операций, размера базы, настроек СУБД и дисковой подсистемы. Один и тот же сервер способен обслуживать 15 бухгалтеров или 80 операторов ввода — разница именно в характере работы, а не в числе подключений. Поэтому универсальной цифры «сервер держит N пользователей» не существует.

Почему нельзя считать сервер только по количеству пользователей

Ответ короткий: потому что нагрузку создают не подключения, а конкретные операции. Один бухгалтер, формирующий отчёт с десятками группировок, способен загрузить процессор сильнее, чем десять операторов, которые построчно вводят документы.

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

Есть и вторая причина. Разные конфигурации — «Бухгалтерия», «Управление торговлей», ERP, ЗУП — создают принципиально разный профиль нагрузки на процессор, память и диски. Сравнивать их напрямую по числу пользователей бессмысленно: 50 человек в ERP и 50 человек в типовой бухгалтерии — это две разные задачи для сервера.

Подключённые и активные пользователи 1С: в чём разница

Число купленных лицензий почти никогда не совпадает с реальной нагрузкой на сервер. Для расчёта важно разделять аудиторию на несколько групп.

Подключённые пользователи — это все сотрудники, за которыми закреплены лицензии на вход в систему. Большинство из них не создают нагрузку одновременно, а часть вообще открывает базу пару раз в день.

Отдельно стоят спящие сеансы — сессии, которые открыты, но ничего не вычисляют в текущий момент. Процессор они почти не трогают, зато удерживают память: по разным оценкам, от 200 до 500 МБ на один такой сеанс.

Активные пользователи — те, кто прямо сейчас проводит документы, строит отчёт или выполняет обработку. Именно на эту группу ориентируется расчёт процессорных и дисковых ресурсов, а не на общее число сотрудников в штатном расписании.

Отдельно нужно учитывать пиковую нагрузку — момент, когда доля активных сеансов максимальна. Обычно это утро понедельника, дни закрытия периода или начисления зарплаты. Сервер, комфортно работающий в обычный день, может «встать» именно в такой момент, если запаса производительности недостаточно.

Какие сценарии сильнее всего нагружают сервер 1С

Не все операции в 1С одинаково затратны. Есть сценарии, которые создают кратковременный, но резкий всплеск нагрузки, и есть те, что дают ровную, предсказуемую загрузку в течение дня.

Отчёты и аналитика

Построение отчётов с большим числом группировок и отбором по нескольким регистрам — одна из самых тяжёлых операций для СУБД. Такой запрос может сканировать значительный объём таблиц базы, даже если пользователь всего один. Проблема усиливается, если отчёт строится по «горячим» данным текущего периода, где индексы ещё не оптимальны.

Закрытие месяца

Регламентное закрытие периода — это десятки последовательных и параллельных операций: расчёт себестоимости, распределение затрат, формирование проводок. Нагрузка на процессор и диски в эти дни вырастает в несколько раз по сравнению со средним значением за месяц. Именно поэтому расчёт «по среднему» часто ошибается: сервер, который справляется 25 дней из 30, может не выдержать оставшиеся пять.

Обмены данными и ЭДО

Каждая внешняя интеграция — обмен с сайтом, маркетплейсом, системой электронного документооборота — фактически ведёт себя как ещё один пользователь. Разница в том, что такой «пользователь» подключается через API и может генерировать сотни запросов в минуту без пауз на раздумье, характерных для человека.

Здесь стоит выделить три типичных источника фоновой нагрузки:

• регулярные обмены с сайтом или маркетплейсами (обновление остатков и цен);
• получение и отправка документов через операторов ЭДО;
• синхронизация с внешними учётными системами и банк-клиентами.

Каждый такой канал нужно закладывать в расчёт отдельно, а не растворять в общем числе «пользователей».

Складские и производственные операции

Массовое проведение расходных накладных, пересчёт остатков, резервирование под заказы — операции, которые интенсивно пишут в регистры накопления. При высокой параллельности (несколько кладовщиков одновременно закрывают отгрузки) возникают блокировки на уровне таблиц СУБД, и именно они, а не процессор, чаще всего становятся причиной «зависаний».

Что ещё влияет на количество пользователей 1С

Профиль работы пользователей — только один из факторов. Итоговое число одновременных сессий, которое выдержит сервер, складывается из нескольких параметров инфраструктуры.

Размер информационной базы. Чем больше объём данных, тем интенсивнее чтение с диска и тем сложнее СУБД удерживать нужные данные в кэше памяти. База до 10 ГБ почти полностью помещается в оперативную память современного сервера; база свыше 100 ГБ требует отдельного внимания к дисковой подсистеме и регулярному обслуживанию индексов.

Тип СУБД. PostgreSQL и MS SQL Server по-разному ведут себя под нагрузкой. PostgreSQL при грамотной настройке параметров кэша и пула соединений (например, через PgBouncer) справляется с сотнями пользователей без лицензионных затрат. MS SQL обладает более развитым оптимизатором запросов и инструментами администрирования, но версия Standard Edition ограничена по числу ядер и объёму памяти.

Дисковая подсистема. Для 1С критична не столько пропускная способность, сколько скорость случайного доступа — показатель IOPS и задержка (latency). Жёсткие диски с показателем около 100–150 IOPS для современных внедрений практически не подходят. SATA SSD закрывает потребности большинства небольших и средних баз, NVMe нужен там, где идёт интенсивная параллельная запись.

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

Процессор. Для 1С важнее не количество ядер само по себе, а частота отдельного ядра — многие операции платформы плохо распараллеливаются. Восемь ядер с частотой 3,2 ГГц во многих сценариях обгоняют шестнадцать ядер с частотой 2,4 ГГц.

Сеть. При работе через терминальный сервер или удалённый доступ задержка свыше 20–30 мс уже ощущается пользователями как «подтормаживание» интерфейса, даже если сам сервер приложений не перегружен.

Признаки, что сервер уже не справляется с текущими пользователями

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

Со стороны пользователей это выглядит так: отчёты стали строиться заметно дольше, проведение документа занимает несколько секунд вместо доли секунды, интерфейс периодически «залипает» в часы пиковой нагрузки. Со стороны инфраструктуры это подтверждается высокой загрузкой процессора в пиках, ростом очередей SQL-запросов и увеличением времени выполнения транзакций.

Можно выделить несколько конкретных сигналов для проверки:

1. Проведение накладной занимает больше 3–5 секунд в обычное, непиковое время.
2. Формирование оборотно-сальдовой ведомости требует больше 30 секунд.
3. Ночные регламентные задания не укладываются в отведённое окно обслуживания.
4. Показатель Swap Usage регулярно превышает 5–10%.

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

Аренда сервера с подбором конфигурации вместо покупки железа

Покупка сервера «с запасом» — распространённое, но не всегда оправданное решение. Компания платит за капитальные затраты сразу, а фактическая нагрузка становится понятна только спустя несколько месяцев эксплуатации.

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

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