Подбираем сервер под 1С:Предприятие 8.3 — процессор, память, диски и сеть под число пользователей
Содержание
Для 1С 8.3 сервер выбирают по трём параметрам: высокая частота процессора на одно ядро (от 3,5 ГГц в турбо), достаточно оперативной памяти под СУБД и рабочие процессы (от 32 ГБ уже на 20–30 пользователей) и NVMe-диски в зеркале. Число ядер важно, но вторично: одна тяжёлая операция — проведение документа, закрытие месяца — почти всегда выполняется в одном потоке.
Требования к серверу для 1С одинаковы для Бухгалтерии, ЗУП и Управления торговлей, а нагрузку задают число пользователей и размер базы. Речь о клиент-серверном варианте: сервер 1С:Предприятия плюс СУБД (MS SQL Server или PostgreSQL).
Процессор для сервера 1С: почему частота важнее числа ядер
Платформа 1С обрабатывает каждый серверный вызов одного пользователя в одном потоке. Если бухгалтер запустил закрытие месяца, это одна длинная цепочка вызовов, и 32 ядра её не ускорят. Ускорит быстрое ядро.
Ядра нужны для параллельной работы многих пользователей и фоновых заданий. Поэтому выбор — баланс:
- ⚡ Частота определяет скорость отдельной операции. Ориентир — базовая от 3 ГГц, турбо от 3,5–4 ГГц.
- 🧮 Ядра определяют, сколько людей одновременно работают без очереди. Грубая прикидка: 1 ядро на 8–12 активных пользователей сервера 1С плюс ядра под СУБД.
- 🗄️ Кэш L3 заметно влияет на работу СУБД и рабочих процессов, больше — лучше.
Из-за этого серверные процессоры с 40–60 ядрами на 2,0–2,4 ГГц часто проигрывают в 1С процессорам с 8–16 ядрами на 4+ ГГц. Для малого и среднего бизнеса нередко выигрывают «рабочие станции» серверного класса или процессоры с высокой частотой из серверных линеек.
Сравнить два сервера по-честному помогает тест Гилёва (gilev.ru, бесплатная обработка). Он показывает скорость однопоточной работы связки «1С + СУБД» в условных единицах. Запустите его на текущем сервере и на кандидате до покупки или в пробный период аренды.
Профиль энергопотребления
Самый частый тормоз нового сервера — экономия энергии. Процессор сбрасывает частоту, и 1С работает на 30–50% медленнее, чем могла бы.
- В BIOS/UEFI выберите профиль максимальной производительности (обычно
Maximum PerformanceилиPerformance). - В Windows:
Панель управления → Электропитание → Высокая производительность. Из командной строки:
powercfg /setactive SCHEME_MIN
- В Linux проверьте режим
cpufreq— должен стоятьperformance, а неpowersave:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Оперативная память: сколько ставить и как раскладывать по каналам
Памяти на сервере 1С обычно не хватает раньше, чем процессора. Её съедают три потребителя.
| Потребитель | Ориентир по объёму |
|---|---|
| Операционная система | 4–8 ГБ |
Рабочие процессы 1С (rphost) | 2–4 ГБ базово + 150–300 МБ на активного пользователя |
| СУБД | в идеале объём «горячих» данных базы; для баз до 50–100 ГБ — сопоставимо с размером базы |
| Терминальный сервер (если на той же машине) | 400–800 МБ на пользователя тонкого клиента |
Пример: 30 пользователей, база 40 ГБ, сервер 1С и СУБД на одной машине. ОС 6 ГБ, рабочие процессы 3 + 30 × 0,25 ≈ 10,5 ГБ, СУБД 32–40 ГБ. Итого около 50–56 ГБ, разумный выбор — 64 ГБ.
Каналы памяти
Объём — половина дела. Вторая половина — пропускная способность.
- 🔲 Заполняйте все каналы процессора одинаково. Если у процессора 8 каналов, 8 модулей по 16 ГБ быстрее, чем 4 по 32 ГБ.
- 🔲 Ставьте одинаковые модули — одна модель, объём и частота.
- 🔲 Используйте серверную память с ECC. Ошибка в памяти на сервере СУБД может испортить данные базы, а не просто «уронить» программу.
- 🔲 На двухпроцессорных платформах память ставят симметрично на оба сокета.
Ограничьте память СУБД. MS SQL Server по умолчанию забирает почти всю оперативную память и вытесняет рабочие процессы 1С в файл подкачки. Задайте параметр max server memory так, чтобы ОС и rphost остались 25–35% памяти. Для PostgreSQL отправная точка — shared_buffers около 25% RAM и effective_cache_size около 50–75% RAM.
Дисковая подсистема: скорость чтения и записи для базы
Для 1С важна не линейная скорость копирования больших файлов, а задержка на мелких случайных операциях и запись журнала транзакций. Отсюда требования.
- 💾 Только SSD, лучше NVMe. HDD для рабочей базы в клиент-серверном режиме — источник постоянных жалоб на «зависания».
- 🔋 Серверные SSD с защитой от потери питания (PLP). Бытовые диски на длительной записи сбрасывают скорость в разы и быстрее изнашиваются.
- 🪞 RAID 1 или RAID 10. RAID 5/6 плохо переносит интенсивную запись СУБД — его оставьте для архива и резервных копий.
- 📂 Раздельные тома при росте нагрузки: данные базы, журнал транзакций,
tempdb(для MS SQL), резервные копии.
Что куда класть
| Данные | Носитель | Комментарий |
|---|---|---|
| ОС и платформа 1С | RAID 1 из SSD | 200–500 ГБ достаточно |
| Файлы базы данных | RAID 1/10 из NVMe | запас ×2–3 от текущего размера |
| Журнал транзакций | отдельный NVMe или том | критична скорость записи |
tempdb MS SQL | быстрый NVMe | 1С активно пишет во временные таблицы |
| Каталог кластера 1С и журнал регистрации | SSD | журнал регистрации растёт быстро |
| Резервные копии | отдельный диск или сетевое хранилище | не на том же массиве, что база |
Ресурс записи (TBW или DWPD) смотрите обязательно. Сервер СУБД с активной базой на 50–100 пользователей пишет десятки и сотни гигабайт в сутки.
Проверить реальную задержку диска на Linux можно утилитой fio, на Windows — diskspd. Мерьте случайную запись блоками 8 КБ (страница MS SQL) с глубиной очереди 1–4: именно так нагружает диск СУБД при работе 1С.
Сеть и виртуализация сервера 1С
Сеть между клиентом, сервером 1С и СУБД
Связка состоит из трёх звеньев, и самое чувствительное — между сервером 1С и СУБД. Там идут тысячи мелких запросов на одну операцию, поэтому решает задержка, а не ширина канала.
- 🔗 Сервер 1С ↔ СУБД: лучше на одной машине или в одной виртуальной среде. Если на разных — 10 Гбит/с и минимальная задержка, без маршрутизаторов и VPN между ними. Для MS SQL на той же машине используется протокол Shared Memory, он быстрее TCP.
- 🖥️ Клиент ↔ сервер 1С: в локальной сети хватает 1 Гбит/с. Удалённым сотрудникам лучше давать терминальный доступ (RDP) или веб-клиент, а не толстый клиент через интернет .
- 🚪 Порты по умолчанию: агент сервера — 1540, менеджер кластера — 1541, рабочие процессы — диапазон 1560–1591 (задаётся в свойствах рабочего сервера). Их открывают в брандмауэре для клиентов и консоли администрирования.
Виртуализация
Сервер 1С и СУБД нормально работают в виртуальных машинах на VMware, Hyper-V, Proxmox или KVM. Потери производительности при правильной настройке небольшие, а потеря от неправильной — огромная.
- Не переподписывайте процессор. Сумма vCPU виртуалок с 1С и СУБД не должна превышать физические ядра хоста. Иначе машины ждут друг друга.
- Резервируйте память для виртуалки СУБД и отключите для неё динамическую память или ballooning.
- Укладывайте ВМ в один NUMA-узел. Виртуалка на 12 vCPU на хосте с двумя процессорами по 10 ядер будет работать с «чужой» памятью медленнее.
- Диски — фиксированного размера (thick), лучше на локальном NVMe хоста или проброшенные напрямую, а не тонкие файлы на медленной СХД.
- Профиль питания хоста — максимальная производительность, как и на физическом сервере.
Снимки виртуальной машины (snapshot) — не резервная копия базы. Держите отдельные бэкапы СУБД: полные, разностные и журналов транзакций.
Операционная система, СУБД и лицензии
Операционная система
Сервер 1С:Предприятия 8.3 работает на Windows и Linux. Список поддерживаемых версий ОС и СУБД меняется с релизами платформы — сверяйтесь с системными требованиями той версии платформы, которую ставите.
- 🪟 Windows Server 2016 и новее — привычный вариант, особенно с MS SQL Server и терминальным сервером на той же площадке.
- 🐧 Linux (Ubuntu, Debian, отечественные дистрибутивы вроде Astra Linux и РЕД ОС) — экономия на лицензиях ОС и MS SQL, обычно в паре с PostgreSQL.
СУБД
| СУБД | Когда выбирать | На что смотреть |
|---|---|---|
| MS SQL Server | Windows-инфраструктура, есть администратор MS SQL, уже есть лицензии | вопрос легальной покупки лицензий в РФ, настройка max server memory, tempdb |
| PostgreSQL (сборка с патчами для 1С) | Linux, импортозамещение, экономия | использовать сборку, адаптированную под 1С, и настраивать параметры под объём RAM |
| Postgres Pro | крупные базы, нужна поддержка вендора | платная лицензия, но поддержка и доработки для 1С |
Обычный PostgreSQL «из репозитория» без патчей для 1С не подойдёт: платформе нужны доработки, которые есть в специальных сборках.
Лицензии, которые влияют на выбор железа
Для клиент-серверного режима нужна лицензия на сервер 1С:Предприятия и клиентские лицензии на пользователей. Лицензия сервера бывает уровня ПРОФ и КОРП. У ПРОФ есть ограничения по масштабированию и части механизмов кластера, у КОРП их нет. Если вы планируете мощный многоядерный сервер или кластер из нескольких рабочих серверов, проверьте у партнёра, какие ограничения действуют для ПРОФ в вашей версии платформы, — иначе часть ядер может просто не использоваться.
Без действующей лицензии сервер 1С не будет обслуживать базы. Пробный «демо-режим» для рабочей эксплуатации не предусмотрен — заложите покупку лицензий в бюджет вместе с железом.
Конфигурации сервера под разный масштаб бизнеса
Числа ниже — ориентир для типовых конфигураций (Бухгалтерия, ЗУП, Управление торговлей) при одновременной работе указанного числа пользователей. Для ERP и сильно доработанных конфигураций берите следующую ступень.
| Пользователей | Процессор | RAM | Диски | Схема |
|---|---|---|---|---|
| до 10 | 4–6 ядер, турбо от 4 ГГц | 16–32 ГБ | 2 × NVMe в RAID 1 | часто хватает файлового режима; при переходе на сервер — всё на одной машине |
| 10–30 | 6–8 ядер, от 3,5–4 ГГц | 32–64 ГБ | 2 × NVMe RAID 1, отдельный SSD под бэкапы | сервер 1С + СУБД на одной машине |
| 30–100 | 12–16 ядер, высокая частота | 64–128 ГБ | NVMe RAID 10, отдельные тома под журнал и tempdb | одна мощная машина или две ВМ на одном хосте; терминальный сервер — отдельно |
| 100–300 | 2 сервера: 1С 16–24 ядра, СУБД 16–32 ядра | 128–256 ГБ на СУБД | NVMe RAID 10 с запасом по TBW | сервер 1С и СУБД раздельно, сеть 10 Гбит/с между ними |
| 300+ | кластер из нескольких рабочих серверов 1С | 256 ГБ+ на СУБД | NVMe, при необходимости СХД с низкой задержкой | кластер 1С, лицензия КОРП, нагрузочное тестирование до запуска |
Файловая база или сервер
Файловый режим проще и дешевле, но у него есть потолок. Переход на сервер обычно нужен, когда:
- 👥 одновременно работают больше 5–10 человек и начинаются блокировки;
- 📈 база перевалила за 10–20 ГБ и закрытие месяца идёт часами;
- 🌐 нужен доступ из нескольких офисов;
- 🔐 нужны резервное копирование без остановки работы и разграничение доступа на уровне СУБД.
Аренда или своё железо
Арендованный выделенный сервер или облачная ВМ закрывают вопрос замены дисков и питания. Но у облачных ВМ часто низкая частота ядер и общие диски. Перед переездом прогоните на арендованной машине тест Гилёва и реальную операцию — например, закрытие месяца на копии базы.
Ошибки при выборе сервера под 1С
Часть ошибок дорого обходится именно потому, что их замечают уже после покупки.
- ❌ Купили много медленных ядер. 48 ядер на 2,1 ГГц — отлично для виртуализации десятка сервисов, но 1С на таком сервере проводит документы медленнее, чем на старом офисном компьютере с 4,5 ГГц.
- ❌ Взяли бытовые SSD. Через несколько месяцев скорость записи падает, растёт время отклика СУБД, а ресурс диска уходит быстрее гарантийного срока.
- ❌ Поставили RAID 5 под базу. Чтение быстрое, запись медленная — проведение и закрытие периода тормозят.
- ❌ Терминальный сервер на той же машине без запаса. 40 тонких клиентов съедают 20–30 ГБ памяти, и СУБД уходит в своп.
- ❌ Разнесли сервер 1С и СУБД по разным площадкам. Даже 2–3 мс задержки между ними превращают секундную операцию в минутную.
- ❌ Не посчитали рост базы. Через два года база выросла втрое, места нет, а слоты под диски заняты.
Запас при покупке — минимум 30–50% по памяти и диску. Добавить память обычно дешевле, чем менять платформу целиком.