Когда 1С «тормозит», большинство рефлекторно ищут процессор с большим числом ядер. На практике упираются в другое: медленные диски, недобор оперативной памяти, гигабит в ядре сети и «смешанный» том, где базы дерутся за IOPS с бэкапами. Правильная конфигурация строится от профиля нагрузки: какие сессии преобладают, как часто идут отчёты, сколько активных пользователей в пике, где лежат общие файлы, как устроены окна обслуживания и резервного копирования. Мы разложим по полочкам, что действительно ускоряет 1С, и покажем ориентиры по CPU, RAM, хранилищу и сети без переплаты за лишние опции. Подобрать «железо» под ваш профиль 1С можно у kvan.tech.
Профили нагрузки 1С — с чего начинать расчёт
Начните с инвентаризации сценариев. «Бухгалтерия/склад» — это много коротких транзакций, чувствительных к латентности диска и частоте одного потока: здесь выигрывают частотные CPU, щедрая память и быстрый пул под БД. «Отчётность» создаёт пики: важны NVMe с предсказуемой задержкой и запас по RAM, чтобы кэш СУБД не вымывался во время ночных задач. В смешанных контурах (учёт + отчёты + веб-клиент) появляется сетевой фактор: отклик тонкого клиента зависит от стабильной сети и отсутствия конкуренции с бэкапами. Зафиксируйте, сколько одновременных пользователей в пике, какова средняя и максимальная масса документов, где лежат вложения и сканы, как часто считаются тяжёлые отчёты. Это определит, где добавлять память, где — ускорять диски, а где — поднимать пропускную способность линка от сервера к ядру.
CPU для 1С — частота важнее «много ядер»
Производительность одной сессии 1С чаще всего упирается в скорость одного потока, а не в абстрактную «сумму ядер». Быстрый ядро-на-ядро отклик ускоряет проведение документов и построение отдельных отчётов заметнее, чем добавление ещё четырёх–восьми ядер с меньшей частотой. Поэтому при одинаковом бюджете разумно брать процессор с высокой базовой частотой и достаточным, а не максимальным числом ядер.
Виртуализация добавляет нюансов: ВМ, растянутая через два NUMA-узла, платит латентностью межузловой шины и теряет кэш-локальность. Старайтесь укладывать критичные ВМ 1С в один NUMA-домен и не раздавайте vCPU «с запасом» — гипервизор начнёт мигрировать потоки, и выигрыш исчезнет. Там, где важна повторяемость, помогает пиннинг vCPU и фиксация планировщика, но только после замеров на пилоте.
Наконец, считайте лицензии: некоторые окружения лицензируются «за ядро». Частотный CPU с меньшим числом ядер иногда дает ту же или лучшую реальную скорость 1С при меньших затратах на лицензирование. Выбор процессора подтверждайте цифрами: сравнивайте время проведения типового документа, p95 отклика и длительность двух-трёх характерных отчётов на тестовой копии базы.
Память и каналы — «без свопа» как KPI
Для 1С недобор RAM бьёт сильнее, чем «нехватка ядер»: как только гостевая ОС уходит в своп, время проведения документов и построения отчётов растёт в разы. Закладывайте объём так, чтобы активные сессии и кэш СУБД умещались в память с запасом; гипервизору тоже нужен свой пул, иначе ballooning начнёт «красть» мегабайты у ВМ в часы пик. Практический ориентир: под типовой контур «учёт+склад» стартуйте от 64–96 ГБ на ВМ 1С и держите возможность нарастить до 128–192 ГБ без замены всех модулей.
Пропускная способность памяти определяется не «мегагерцами» в прайсе, а числом заполненных каналов. Лучше равномерно занять 8–12 каналов на сокет модулями умеренной ёмкости, чем поставить пару «толстых» планок высокой частоты: у 1С выигрыш приходит от ширины, а не от рекордных таймингов. Используйте ECC RDIMM/3DS, планируйте топологию так, чтобы апгрейд делался добавлением модулей, а не их полной заменой. Проверяйте фактические метрики: p95 времени ответа, долю page faults, давление на кэш базы — если эти показатели стабильны, вы попали в «зону без свопа», где 1С работает предсказуемо.
Хранилище — NVMe под базы, RAID10 под общий объём
Самое частое «узкое место» 1С — дисковая латентность. Базам и их журналам нужен отдельный «горячий» пул на NVMe-зеркале с предсказуемыми миллисекундами и быстрой деградацией без падения скорости. В этот слой кладут файлы БД, журналы/redo, темпы и индексы, чтобы короткие транзакции не упирались в очереди контроллера. Общие каталоги, вложения, архивы и «тёплые» данные выводите на отдельный массив, обычно RAID10 на HDD с достаточным кешем контроллера или SSD-кэшем — так последовательные копии и ночные задачи не давят транзакции днём. Один общий том «на всё» неизбежно создаёт конкуренцию за IOPS: в моменты бэкапа или массовой выгрузки отчётов время проведения документов растёт кратно. Следите за p95/p99 задержек и глубиной очереди на уровне гипервизора и СУБД, а не за «средней скоростью», и вынесите резервные копии на отдельный том или узел, чтобы окно копирования жило своей жизнью. Планируйте рост заранее: оставьте слоты под дополнительные NVMe и место под корзины, чтобы расширение выполнялось без переезда и недель простоя; проверяйте поведение массива в деградации и на восстановлении — 1С «сыпется» именно в эти дни, а не в бенчмарках.
Сеть и удалёнка
Когда базы и клиенты распределены по отделам и филиалам, сеть становится частью производительности 1С. Гигабит в ядре — частая причина «мистических» тормозов: один поток копирования или бэкап съедает канал, и веб-клиент/тонкий клиент начинают «ступать». Для серверного узла разумный минимум — 10GbE от хоста к коммутатору ядра; если есть активные репликации, ночные выгрузки и «тяжёлые» отчёты, точечно поднимайте участок до 25GbE. Агрегация нескольких 1GbE повышает суммарную пропускную способность, но не ускоряет одиночный поток, поэтому миграции ВМ, копирование образов и бэкапы всё равно упрётся в потолок.
Разделяйте трафик: продуктив (клиенты 1С), резервное копирование и администрирование идут по разным VLAN, чтобы бэкап не конкурировал с сессиями. Управляющие интерфейсы (IPMI/BMC) держите в out-of-band-сегменте под VPN с MFA. Для удалённых филиалов — терминальные сервисы/VPN с 2FA и политиками, ограничивающими доступ только к нужным серверам и портам; так вы снижаете латентность приложений и риски бокового перемещения. Jumbo Frames включайте только «сквозняком» (хост ↔ коммутатор ↔ сторидж) и после замеров: частичная настройка приносит потери пакетов и фантомные ошибки. Ключевые метрики — p95 задержек на интерфейсах, дропы/перегрузки очередей, время установления сессии, а не «средняя загрузка». Если хвосты растут в часы бэкапа — трафик разведён неверно или не хватает «жирного» линка.
Тестовые метрики — понимаем, «тянет» ли сервер
Сервер «быстрый» только тогда, когда это подтверждают цифры на вашей базе, а не синтетика. Снимите с продовой копии короткий срез и прогоните типичные сценарии: проведение партии документов, построение тяжёлого отчёта, одновременный импорт. Смотрите не на средние значения, а на хвосты: p95–p99 задержек диска и сети показывают, что будет в час пик. В гипервизоре контролируйте I/O wait и steal time — если эти показатели растут в момент отчётов, у вас конкуренция за «горячий» пул или ядра. Внутри СУБД полезны время ответов по запросам, доля чтений из кэша и частота попаданий в журнал; если кэш не держит рабочий набор, добавляйте память раньше, чем «вкручиваете» новые ядра. Для сети критична стабильность RTT между сервером и рабочими местами, а также отсутствие потерь в периоды резервного копирования. Итогом пилота должна стать таблица «до/после» с конкретными минутами и секундами на операции: именно она подскажет, куда вкладывать следующий рубль — в RAM, NVMe или линк до 10/25GbE.
Масштабирование без замены сервера
Растите по-этапно и предсказуемо. Вертикально — сначала память (чтобы кэш СУБД удерживал рабочий набор), затем второй/третьий NVMe под «горячий» пул: зеркала разносите по разным слотам/линиям PCIe и контролируйте температуры, чтобы rebuild не превращался в «улитку». Объёмный массив масштабируйте корзинами, а не заменой всех дисков: так расширение не требует долгих окон. Горизонтально — разносите роли на отдельные ВМ/узлы: база 1С, терминальные сессии, общий файловый объём, сервисы интеграций. Это снижает конкуренцию за ресурсы и упрощает обслуживание: обновляете терминальные серверы — база не трогается, и наоборот. Любое расширение сопровождайте контрольными замерами: таблица «до/после» по времени проведения документов и p95 диска показывает, достигли ли цель или нужен следующий шаг (например, 10→25GbE на участке сервер↔ядро).
Типовые конфигурации «с порога»
Бухгалтерия/склад до 40–60 пользователей. Частотный CPU, 64–128 ГБ ECC, NVMe-зеркало под БД/журналы, отдельный RAID10 на HDD под файлы/сканы, 10GbE к ядру, выделенный том для бэкапов.
Смешанный контур (учёт + отчёты + веб-клиент). Частотный CPU, 128–192 ГБ ECC, два NVMe-зеркала (БД и журналы/темпы отдельно), RAID10 под общий объём, 10GbE (готовность к 25GbE), разделение VLAN.
Рост к ERP/многим базам. 192–256 ГБ ECC, NVMe-пул из двух зеркал или RAID10 на NVMe, отдельный массив под файлы, 25GbE на участок с миграциями/бэкапами, вынос терминальных сессий на отдельную ВМ/узел.
Бэкапы и восстановление «на чистый стенд»
Защита существует только после успешного рестора. Держите 3-2-1: три копии, два типа носителей, одна — вне площадки; продуктив и резервный контур физически разделены. Базы и журналы уходят в «неприкосновенные» снимки, копии шифруются, ключи хранятся отдельно и ротуются. Раз в квартал проводите учебную сборку: на отдельной машине разворачиваете копию БД, прикладной слой и проверки доступов, фиксируете фактические RPO/RTO. Если восстановление превышает бизнес-окно — меняйте расписание и пропускную способность бэкапов (отдельный том/узел, 10/25GbE, дедупликация). В ежедневной рутины — отчёт о состоянии копий и алерты по ошибкам, иначе «зелёные галочки» превращаются в сюрпризы.
Вывод
Сервер под 1С не про «максимум ядер», а про баланс задержек: частотный CPU в одном NUMA-домене, щедрая RAM по всем каналам, отдельный NVMe-слой под базы и журналы, объёмный массив для файлов и сеть 10/25GbE без конкуренции с бэкапами. Решения подтверждаются метриками, а не ощущениями: p95/p99 диска и сети, время проведения, I/O wait и стабильность кэша. С таким подходом система ускоряется именно там, где это чувствуют пользователи, масштабируется без замены платформы и переживает сбои без потери данных.