Сколько мощности реально нужно вашей 1С?

1С требует ровно столько мощности, сколько диктуют количество одновременных пользователей, объём базы и режим работы — файловый или клиент-серверный. До 10-15 пользователей в файловом режиме хватает 8 ГБ ОЗУ и 4 ядер на SSD. От 20 пользователей нужен переход на клиент-серверную архитектуру с отдельным сервером СУБД — иначе программа тормозит независимо от мощности железа.

Вопрос актуален для любой компании, где 1С работает медленнее, чем год назад: при росте штата на 5-10 человек или увеличении объёма продаж нагрузка на базу растёт нелинейно, и момент, когда файловый режим или текущий сервер перестают справляться, наступает обычно резче, чем ожидают в отделе финансов, планировавшем бюджет на IT.

Почему 1С тормозит даже на «мощном» сервере

Частая ситуация: компания покупает сервер с 32 ГБ ОЗУ и современным процессором, а 1С всё равно зависает на проведении документов и формировании отчётов. Мощность процессора и объём памяти — не единственные параметры, от которых зависит скорость работы программы. В файловом режиме, когда база — это файл .1CD, а не SQL-сервер, узкое место чаще всего диск и блокировки записи: при одновременной работе больше 10-15 пользователей каждый клиент обращается к одному файлу базы по сети, и любая операция записи блокирует остальных на время транзакции. Добавление ядер процессора эту проблему не решает, потому что она архитектурная, а не ресурсная.

Второй частый источник тормозов — тяжёлые доработки и отчёты без индексов, написанные под старую версию конфигурации или без учёта роста базы. Запрос без индекса при объёме базы в несколько гигабайт начинает сканировать таблицу целиком, и это одинаково медленно что на сервере с 8 ГБ ОЗУ, что на сервере с 128 ГБ. Третья причина — диск с высокой задержкой: сетевые хранилища и HDD дают задержку в разы выше, чем локальный SSD, а 1С крайне чувствительна именно к задержке дисковых операций, а не только к их количеству.

Отличить архитектурное ограничение от банальной нехватки мощности помогают несколько признаков:

• ✓Проведение документов занимает 3-5 секунд и больше при обычных объёмах, хотя раньше занимало доли секунды.
• ✓Очередь блокировок в журнале регистрации растёт быстрее числа новых пользователей.
• ✓Отчёты, которые раньше формировались за секунды, теперь занимают минуты независимо от времени суток.
• ✓Диспетчер задач показывает высокую загрузку диска при невысокой загрузке процессора — это почти всегда узкое место дисковой подсистемы или сети, а не CPU.

Сколько ресурсов реально нужно: конфигурации по сценариям

Универсального ответа «нужно X ГБ ОЗУ» не существует — потребность зависит от режима работы базы и числа одновременных пользователей. Ниже — ориентировочные конфигурации, которые покрывают большинство сценариев малого и среднего бизнеса в Москве.

Файловый режим: до 15-20 пользователей

Для компании с 5-15 сотрудниками, работающими в 1С одновременно, файловый режим остаётся рабочим вариантом при условии, что база лежит на SSD, а не на сетевом диске с высокой задержкой. Требования здесь скромные: 4 ядра CPU, 8-16 ГБ ОЗУ, SSD от 128 ГБ. За порогом в 15-20 одновременных пользователей файловый режим начинает деградировать вне зависимости от мощности железа — это архитектурный потолок технологии.

Клиент-серверный режим SQL: от 20 пользователей

При 20 и более пользователях нужен переход на клиент-серверную архитектуру: сервер приложений 1С плюс отдельный SQL-сервер (MS SQL Server или PostgreSQL). Здесь мощность считается отдельно для каждого узла и растёт вместе с числом пользователей и типом конфигурации — 1С:ERP потребляет ресурсов ощутимо больше, чем 1С:Управление торговлей на сопоставимом числе пользователей за счёт более сложной бизнес-логики и большего количества фоновых регламентных заданий.

Как рассчитать нужную мощность под свою базу

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

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

Практический алгоритм: замерить текущую производительность тестом, сопоставить результат с числом одновременных пользователей и динамикой роста базы за последний год, и уже от этого считать запас мощности на 12-18 месяцев вперёд — а не покупать сервер с запасом на всякий случай, переплачивая за неиспользуемые ресурсы. Такой расчёт особенно важен перед покупкой оборудования: цена ошибки высокая в обе стороны — и при нехватке мощности, и при избыточных вложениях в железо, которое не понадобится ближайшие два года.

Что делать, если производительности не хватает даже после апгрейда железа

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

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

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

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

Как предотвратить нехватку мощности при росте компании

Правильный расчёт мощности закладывается не постфактум, а на этапе внедрения 1С — тогда же, когда выбирается сама конфигурация. Ошибка на этом шаге стоит дороже, чем недооценённый сервер: например, внедрение 1С:ERP для компании с 15 пользователями и простыми процессами избыточно и по стоимости лицензий, и по требованиям к железу, тогда как внедрение 1С:Управление торговлей для растущей розничной сети с прицелом на 100+ пользователей через два года потребует пересмотра архитектуры раньше, чем хотелось бы, если её не заложить заранее.

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

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

Хватит ли обычного офисного сервера для 1С на 10 человек?

Да, если база работает в файловом режиме и лежит на SSD, а не на сетевом диске или HDD. Для 10 одновременных пользователей достаточно 4 ядер CPU и 8-16 ГБ ОЗУ. Проблемы обычно начинаются не из-за нехватки мощности, а из-за медленного диска или сетевой задержки при доступе к файлу базы.

Что быстрее решит тормоза 1С: апгрейд сервера или переход на SQL?

Зависит от причины. Если пользователей меньше 15-20 и база работает в файловом режиме на медленном диске, часто достаточно перенести базу на SSD. Если пользователей больше 20, апгрейд процессора не поможет — нужен переход на клиент-серверную архитектуру с отдельным SQL-сервером.

Как понять, что пора переходить с файлового режима на клиент-серверный?

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

Почему 1С:ERP требует больше ресурсов, чем 1С:Управление торговлей?

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

Можно ли посчитать нужную мощность заранее, до покупки сервера?

Да. Официальные системные требования 1С дают минимальную планку, а тест Гилёва позволяет объективно сравнить разные варианты железа до покупки. Вместе с прогнозом роста базы на 12-18 месяцев это даёт рабочий расчёт мощности без покупки оборудования с большим избыточным запасом.