К основному содержимому

Сервер для 1С: требования к железу и настройке

Выделенные серверы · 24.09.2026
Иллюстрация к статье «Сервер для 1С: требования к железу и настройке»

Сервер для 1С: требования к железу

1С упирается в частоту одного ядра и в задержку дисков, а не в количество потоков. Для продуктивной базы на 20–30 одновременных сеансов берите 4–8 ядер с частотой от 3,2 ГГц, 32 GB ECC-памяти и два NVMe в RAID1. Память и диски добавить несложно, частоту процессора — нет, поэтому подбор конфигурации начинайте с CPU.

  • Частота ядра важнее их количества: один пользовательский запрос 1С выполняется в один поток.
  • Сервер приложений и СУБД на одной машине убирают сетевой round-trip и ускоряют проведение документов.
  • 32 GB ECC — практический минимум для клиент-серверной базы, 64 GB — для базы от 100 GB или от 50 сеансов.
  • Файловый режим на сетевой папке даёт почти все жалобы на медленную работу; переход в клиент-серверный режим обычно полезнее апгрейда железа.

Процессор

Платформа раскладывает по ядрам разные сеансы, но внутри одного сеанса проведение документа или пересчёт итогов идёт одним потоком. Отсюда правило: 8 ядер по 3,5 ГГц обслужат бухгалтерию лучше, чем 24 ядра по 2,1 ГГц. Смотрите базовую частоту и частоту под нагрузкой всех ядер, а не маркетинговое значение «до».

Кэш третьего уровня тоже влияет: регистры накопления и таблицы итогов читаются мелкими порциями. Разбор линеек и поколений — в статье как выбрать процессор для сервера.

СценарийСеансыCPURAMДиски
Бухгалтерия одной фирмыдо 104 ядра от 3,3 ГГц16 GB ECC2×SSD, RAID1
Торговля и склад10–308 ядер от 3,2 ГГц32 GB ECC2×NVMe, RAID1
ERP, несколько баз30–8016 ядер от 2,8 ГГц64 GB ECC4×NVMe, RAID10
СУБД отдельно от сервера 1С80 и большедва сервера64 GB на каждомNVMe RAID10 под СУБД

Оперативная память

MS SQL и PostgreSQL держат страницы базы в кэше, и разница между «база помещается в память» и «не помещается» — это разница в порядок по времени отчёта. Практическое правило: объём RAM не меньше половины размера файлов базы плюс 8 GB на сервер приложений и операционную систему.

Память обязательно ECC. Ошибка одного бита в кэше СУБД — это тихо испорченная страница, которая уедет в резервную копию и всплывёт через недели. Как работает коррекция и где смотреть счётчики ошибок, описано в материале ECC-память в сервере.

Диски

Профиль нагрузки 1С — мелкий случайный ввод-вывод: журнал транзакций пишется синхронно, индексы читаются страницами по 8 KB. На NVMe такие операции идут в 4–6 раз быстрее по IOPS на случайной записи, чем на SATA SSD, и на два порядка быстрее, чем на механическом диске.

Рабочая раскладка: система и сервер приложений на одном зеркале, файлы базы и журнал транзакций — на NVMe. RAID1 закрывает отказ накопителя, RAID10 добавляет запас по записи на больших базах. Детали раскладки файлов СУБД разобраны в статье выделенный сервер под базу данных.

Windows Server или Linux

Windows Server и MS SQL

Привычная связка: сервер приложений, SQL Server и терминальные сессии пользователей на одной машине. Минус — лицензии операционной системы, клиентские лицензии и SQL Server считаются отдельно и часто стоят дороже аренды самого железа.

Linux и PostgreSQL

Сервер приложений под Linux работает с PostgreSQL, в том числе со сборками, адаптированными под платформу. Лицензий ОС и СУБД здесь нет, но нужен администратор, который понимает autovacuum, блокировки и планировщик запросов. Базовая установка и настройка описаны в статье PostgreSQL на сервере.

# Debian/Ubuntu: смотрим реальную частоту ядер под нагрузкой
lscpu | grep -E 'Model name|MHz'

# RHEL/AlmaLinux: сервер приложений ставим из локального каталога
sudo dnf install -y ./1c-enterprise-server-*.rpm

# ключевые параметры PostgreSQL (postgresql.conf)
shared_buffers = 8GB
effective_cache_size = 24GB
work_mem = 64MB
max_connections = 200
# параллельные планы на типовых запросах платформы чаще вредят
max_parallel_workers_per_gather = 0

# применяем и проверяем
sudo systemctl restart postgresql
psql -U postgres -c 'show shared_buffers;' 2>&1

# разворачиваем выгрузку в чистую базу
createdb -U postgres -T template0 buh
psql -U postgres -d buh < buh.sql

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

Доступ, сеть и резервные копии

Пользователи подключаются тонким клиентом, по RDP или через веб-клиент за nginx. Публиковать терминальный доступ в Интернет на стандартном порту не стоит: поднимите VPN или хотя бы ограничьте подключения по списку адресов.

Отдельно спланируйте выгрузки: файл базы и дамп СУБД должны уезжать за пределы сервера, потому что RAID не защищает от ошибочного удаления. Готовые конфигурации под такие задачи собраны в разделе выделенные серверы: бухгалтерии до 10 сеансов хватает Dedicated Start DE (Xeon E3-1230v5, 16 GB ECC, 2×500 GB SSD в RAID1) за $49 в месяц, для торговли и склада берут Dedicated Pro DE или Pro FR с 32 GB ECC и NVMe.

Коротко

  • Сначала частота ядра, потом их количество: 8×3,5 ГГц лучше 24×2,1 ГГц.
  • RAM — половина размера базы плюс 8 GB, только ECC.
  • База и журнал транзакций живут на NVMe в RAID1 или RAID10.
  • Windows с MS SQL дороже по лицензиям, Linux с PostgreSQL дороже по администрированию.
  • Исключения антивируса и кэш записи контроллера проверяйте до того, как менять железо.
← Назад в базу знаний Задать вопрос поддержке