Сервер под 1С:Предприятие 8.3: процессор, память, диски и сеть без переплаты
Содержание
Для сервера 1С главное — высокая частота каждого ядра процессора, быстрые NVMe-диски под базу СУБД и достаточно памяти, чтобы данные помещались в кэш. Ориентир для 20–30 пользователей: процессор с частотой от 3,5 ГГц под нагрузкой и 8–12 ядрами, 64 ГБ памяти, два NVMe в зеркале. Сотня ядер с частотой 2,1 ГГц для 1С почти бесполезна: отдельная операция проведения выполняется в одном потоке и упирается в скорость ядра.
Конфигуратор сервера 1С — это не программа, а подбор комплектующих под задачу. Каждую часть — процессор, память, диски, сеть и лицензии — считают отдельно, от нагрузки и числа пользователей. Чаще всего деньги теряют на многоядерных процессорах с низкой частотой и на потребительских SSD.
Как устроен сервер 1С и что он нагружает
Клиент-серверная 1С — это минимум два сервиса. Сервер 1С:Предприятия исполняет код конфигурации. СУБД (PostgreSQL или Microsoft SQL Server) хранит данные. Они могут жить на одной машине или на разных.
Как идёт запрос:
- Клиент обращается к агенту сервера 1С на порт
1540. - Агент передаёт его менеджеру кластера на порт
1541. - Менеджер направляет сеанс в рабочий процесс
rphost. Диапазон портов рабочих процессов задают в свойствах рабочего сервера, по умолчанию это1560:1591. - Рабочий процесс выполняет код и шлёт запросы в СУБД.
Что из этого следует для железа:
- 🧠 Сервер 1С нагружает процессор и память. Каждый вызов сервера выполняется в одном потоке, поэтому важна частота.
- 💾 СУБД нагружает диски, память под кэш страниц и процессор на тяжёлых запросах. Здесь многопоточность уже работает.
- 🔗 Связка между ними чувствительна к задержке сети. Проведение документа — это десятки и сотни мелких запросов. Лишняя миллисекунда на каждом складывается в секунды.
Файловый вариант на сервер не опирается: клиенты сами читают файл 1Cv8.1CD по сети. Для него «мощный сервер» почти ничего не даёт, важны диск и сеть. Всё дальнейшее — про клиент-серверный вариант.
Процессор для сервера 1С: частота против числа ядер
Главное правило: частота одного ядра важнее количества ядер. Отчёт, закрытие месяца , проведение документа идут в одном потоке. Если у процессора 32 ядра по 2,2 ГГц, конкретный пользователь получит ровно одно ядро на 2,2 ГГц.
Ядра нужны для параллельной работы многих пользователей и фоновых заданий. Поэтому считаем так:
| Нагрузка | Ядер под 1С и СУБД | Частота под нагрузкой |
|---|---|---|
| до 10 пользователей | 4–6 | от 3,5 ГГц |
| 10–30 пользователей | 8–12 | от 3,5 ГГц |
| 30–80 пользователей | 12–24 | от 3,3 ГГц |
| 80–200 пользователей | 24–48, часто на двух серверах | от 3,0 ГГц |
Цифры ориентировочные. Тяжёлая ERP с регламентными заданиями съест больше, чем Бухгалтерия на тех же пользователях.
Что смотреть в характеристиках:
- ⚡ Частота в турбо-режиме при загрузке всех ядер, а не пиковая на одном ядре. Серверные процессоры с большим числом ядер часто держат 2,5–3 ГГц под полной нагрузкой.
- 🧩 Объём кэша L3. Для СУБД он заметно влияет на скорость.
- 🖥️ Одна сокетная платформа для малого и среднего бизнеса. Два процессора добавляют задержку между ними (NUMA) и выгодны, только когда одного уже не хватает.
Хороший выбор для небольшой компании — серверные или рабочие станции с высокой частотой: линейки с суффиксами для высоких частот у Intel Xeon и AMD EPYC, а для малых офисов — платформы класса рабочей станции.
Перед покупкой и после сборки прогоните тест Гилёва (бесплатная обработка от независимого автора). Он меряет именно однопоточную производительность связки «1С + СУБД». Сравните результат с публичными таблицами: так видно, недожал процессор или узкое место в диске и сети.
Отдельно про настройки питания. В BIOS выставьте профиль максимальной производительности, в Windows — план электропитания «Высокая производительность». Режим экономии энергии снижает частоту между запросами, и 1С ощутимо «тормозит» на коротких операциях.
Сколько оперативной памяти нужно серверу 1С
Память делят между тремя потребителями: операционной системой, рабочими процессами 1С и кэшем СУБД.
Примерный расчёт:
- 🪟 ОС — 4–8 ГБ.
- ⚙️ Сервер 1С — около 150–300 МБ на активного пользователя для Бухгалтерии и ЗУП, до 500 МБ и больше для ERP и УТ с тяжёлыми отчётами.
- 🗄️ СУБД — в идеале столько, чтобы активная часть базы помещалась в кэш. Для базы на 50 ГБ это 32–48 ГБ, для 200 ГБ — 64–128 ГБ.
Пример. 25 пользователей Бухгалтерии и ЗУП, суммарный объём баз 60 ГБ:
- ОС: 8 ГБ;
- сервер 1С: 25 × 0,3 ГБ = 7,5 ГБ, с запасом под фоновые задания — 12 ГБ;
- СУБД: 40 ГБ под кэш.
Итого 60 ГБ, то есть ставим 64 ГБ, лучше 96 ГБ с запасом на рост.
Про скорость памяти:
- заполняйте все каналы контроллера. Четыре модуля по 16 ГБ быстрее двух по 32 ГБ на платформе с четырьмя каналами;
- используйте серверную память с коррекцией ошибок (ECC). Сбой бита в кэше СУБД — это риск повреждения данных, а не просто зависание;
- частота модулей вторична по сравнению с числом каналов и объёмом.
Если СУБД и 1С стоят на одной машине, ограничьте память СУБД вручную. В MS SQL — параметр максимальной памяти сервера, в PostgreSQL — shared_buffers и effective_cache_size. Иначе СУБД заберёт почти всё, и рабочие процессы 1С начнут уходить в файл подкачки.
Диски и RAID-массивы под базы 1С
Диск — самое частое узкое место у серверов, собранных «по остаточному принципу». СУБД постоянно пишет журнал транзакций и читает случайные страницы. Здесь решает не скорость линейного копирования, а число операций ввода-вывода в секунду и задержка.
Как разложить данные:
| Что хранится | Носитель | Массив |
|---|---|---|
| Система и программы | SSD SATA или NVMe | RAID 1 |
| Файлы данных баз | NVMe серверного класса | RAID 1 или RAID 10 |
| Журнал транзакций | NVMe, по возможности отдельный | RAID 1 |
tempdb (MS SQL) | NVMe | RAID 1 или отдельный диск |
| Резервные копии | HDD большого объёма | RAID 1 или отдельное хранилище |
Правила, которые спасают данные при отказе:
- Только серверные SSD с защитой от потери питания и ресурсом перезаписи от 1 DWPD. Потребительские NVMe быстро деградируют под журналом транзакций.
- Не используйте RAID 5 и RAID 6 под файлы данных и журналы. Запись на них медленная, а восстановление массива после отказа диска растягивается на часы под нагрузкой.
- Резервные копии храните не на том же массиве, что и базы. Отказ контроллера уносит и базу, и копию.
- Кэш контроллера на запись включайте, только если есть батарея или флеш-защита кэша.
Сколько места заложить: объём баз × 3. Сюда входят рост за 2–3 года, временные таблицы и журналы. Для копий — объём баз × число хранимых копий.
Файл базы на сетевой папке или NAS в клиент-серверном варианте — плохая идея. Данные СУБД должны лежать на локальных дисках или в хранилище с гарантированной задержкой.
Сеть между клиентами, сервером 1С и СУБД
Сеть влияет на 1С сильнее, чем кажется. Клиент обменивается с сервером 1С относительно небольшими порциями. А вот между сервером 1С и СУБД идёт плотный поток мелких запросов.
Что закладывать:
- 🔌 Клиенты → сервер 1С: 1 Гбит/с в офисе достаточно. Для удалённых филиалов тонкий клиент работает и на 10–20 Мбит/с, если задержка до сервера стабильная.
- 🚀 Сервер 1С → СУБД, если это разные машины: 10 Гбит/с, один коммутатор, без маршрутизации и межсетевых экранов посередине. Задержка должна быть в доли миллисекунды.
- 🖧 Одна машина под 1С и СУБД часто быстрее двух на небольших нагрузках: обмен идёт без сети. В MS SQL для этого есть протокол общей памяти (Shared Memory).
Разносить 1С и СУБД на разные серверы имеет смысл примерно от 50–80 активных пользователей или когда одна машина упирается в процессор.
Балансировка нагрузки в кластере 1С появляется, когда рабочих серверов несколько. Менеджер кластера распределяет сеансы по рабочим процессам и серверам. Для этого в свойствах рабочего сервера задают число информационных баз и соединений на процесс, а для разделения ролей — требования назначения функциональности. Пример такого разделения: фоновые задания на одном сервере, пользователи — на другом.
Перед изменением параметров рабочего сервера или перезапуском службы предупредите пользователей. Перезапуск службы агента обрывает все сеансы, несохранённые документы пропадут. Делайте это вне рабочего времени.
Терминальный сервер для пользователей держите отдельно от сервера 1С и СУБД. Браузеры, офис и печать на одной машине с СУБД отнимают память и процессор у баз.
Операционная система, СУБД и лицензирование
Железо — только половина бюджета. Вторая половина — лицензии.
Серверная лицензия 1С
Для клиент-серверного варианта нужна лицензия на сервер 1С:Предприятия. Есть два уровня:
- ПРОФ — для типичной компании с одним сервером. У неё есть ограничения по масштабированию, в том числе по числу используемых ядер. Перед покупкой мощного процессора сверьте условия у партнёра.
- КОРП — открывает расширенные механизмы кластера: требования назначения функциональности, тонкую настройку балансировки, работу больших кластеров.
Плюс клиентские лицензии на число одновременных подключений. Они не зависят от выбора железа, но без них база не откроется.
Выбор СУБД
| СУБД | Плюсы | Минусы |
|---|---|---|
| PostgreSQL (сборка, рекомендованная фирмой 1С, или Postgres Pro) | Бесплатная, работает на Linux и Windows | Нужна настройка параметров под 1С, меньше привычных инструментов |
| Microsoft SQL Server Standard | Привычная, удобные инструменты, хорошо держит нагрузку | Лицензия на ядра или пользователей, вопрос доступности покупки |
| Microsoft SQL Server Express | Бесплатная | Ограничения по памяти, ядрам и размеру базы — для рабочей 1С не годится |
PostgreSQL берите в той сборке, которая официально поддерживается вашей версией платформы. Обычная сборка из репозитория дистрибутива без патчей для 1С работать не будет.
Операционная система
- Windows Server 2016 и новее — привычный выбор, если нужны терминальный сервер и MS SQL. Учитывайте, что лицензия Windows Server считается по ядрам, минимум 16 ядер на сервер.
- Linux (Debian, Ubuntu, Astra Linux, РЕД ОС и другие поддерживаемые) — экономит на лицензиях ОС, хорошо работает в паре с PostgreSQL.
Если сервер виртуальный, выделяйте виртуальной машине ядра без переподписки и закрепляйте память. Иначе 1С получает «чужое» процессорное время, и замеры скачут.
Готовые варианты сервера 1С под число пользователей
Ориентиры для Бухгалтерии, ЗУП и УТ. Для ERP поднимайте память и диск на одну строку.
| Пользователей | Процессор | Память | Диски | Сеть |
|---|---|---|---|---|
| до 10 | 4–6 ядер, от 3,8 ГГц | 32 ГБ | 2 × NVMe 1 ТБ, RAID 1 | 1 Гбит/с |
| 10–30 | 8–12 ядер, от 3,5 ГГц | 64 ГБ | 2 × NVMe 2 ТБ, RAID 1 + HDD под копии | 1 Гбит/с |
| 30–80 | 16–24 ядра, от 3,3 ГГц | 128 ГБ | 4 × NVMe, RAID 10 + отдельно журнал | 1–10 Гбит/с |
| 80–200 | 2 сервера: СУБД 24–32 ядра, 1С 16–24 ядра | 256 ГБ на СУБД, 128 ГБ на 1С | NVMe RAID 10 на СУБД | 10 Гбит/с между серверами |
Как проверить, что железо подобрано правильно, уже после запуска:
- 📈 Загрузка процессора в рабочие часы держится ниже 70%.
- 💽 Очередь к диску почти всегда близка к нулю, задержка записи журнала — единицы миллисекунд.
- 🧮 Свободная память не падает до нуля, файл подкачки почти не растёт.
- ⏱️ Тест Гилёва даёт результат на уровне похожих конфигураций из публичных таблиц.
Если одна из метрик выбивается, узкое место найдено. Добавлять ядра, когда упираются в диск, бесполезно.