Администрирование · 14 мин
Какой сервер выбрать для 1С:Предприятие
Как подобрать сервер для 1С:Предприятие: требования к процессору, памяти и дискам, расчёт по числу пользователей, выбор СУБД, RAID, виртуализация и типичные ошибки.
1С:Предприятие в клиент-серверном режиме чувствительно не к «мощности сервера вообще», а к трём конкретным вещам: однопоточной производительности процессора, объёму и скорости оперативной памяти и задержкам дисковой подсистемы. Сервер, который отлично справляется с файловым хостингом или веб-сайтом, может «захлёбываться» под нагрузкой 1С из-за медленных дисков или низкой тактовой частоты ядра.
Ошибка в выборе оборудования обходится дорого: база начинает тормозить в часы пик, проведение документов растягивается, пользователи жалуются на «зависания», а апгрейд сервера в разгар отчётного периода превращается в аврал. Поэтому сервер под 1С выбирают не «с запасом на всякий случай», а по расчёту: число активных пользователей, размер базы, тип конфигурации и режим работы.
Ниже — практический порядок подбора: какие параметры железа действительно важны, как рассчитать конфигурацию под своё число пользователей, какую СУБД и дисковую схему выбрать, когда оправдана виртуализация и как проверить, что сервер справляется с нагрузкой.
Какой режим работы 1С определяет требования к серверу
Прежде чем считать железо, определите режим работы. В файловом режиме база лежит в общей папке, а вся обработка идёт на компьютерах пользователей — сервер фактически работает как файловое хранилище. Такой вариант приемлем для небольшой базы и 5–10 одновременно работающих пользователей, но плохо масштабируется и уязвим к повреждению файла при сбоях сети.
В клиент-серверном режиме работают два компонента: сервер 1С:Предприятия (ragent, rphost) и СУБД (MS SQL Server, PostgreSQL или Oracle). Именно этот режим требует полноценного сервера: основная нагрузка ложится на СУБД, а сервер приложений 1С потребляет CPU на бизнес-логику. Для 10 и более пользователей, базы от нескольких гигабайт и любых конфигураций с интенсивным документооборотом (УТ, ERP, КА) клиент-серверный режим — фактически обязателен.
Оба компонента можно разместить на одной физической машине (для малой и средней нагрузки это нормальная практика) или разнести на два сервера. Разнесение имеет смысл при 30–50 и более активных пользователях, когда СУБД и сервер приложений начинают конкурировать за память и процессор.
Процессор: почему частота важнее числа ядер
Ключевая особенность 1С — значительная часть операций (проведение документа, расчёт в запросе) выполняется в одном потоке. Поэтому процессор с 4 ядрами на 3,5–4 ГГц для 1С обычно лучше, чем 16-ядерный на 2,1 ГГц. Многоядерные серверные CPU с низкой частотой — самая частая ошибка при покупке «настоящего сервера» под 1С.
Практические ориентиры: для 10–15 пользователей достаточно 4–6 ядер с высокой частотой; для 20–40 пользователей — 6–8 ядер; дальше нагрузка растёт в основном за счёт параллельных сеансов, и число ядер начинает иметь значение, но частота по-прежнему приоритетна. Технологии турбо-разгона полезны, гипертрейдинг даёт небольшой прирост и не заменяет физические ядра.
Обратите внимание на лицензирование: MS SQL Server лицензируется по ядрам, поэтому чрезмерное число ядер на сервере БД резко удорожает проект. Ещё один аргумент в пользу меньшего числа быстрых ядер вместо большого числа медленных.
Память и дисковая подсистема
Оперативная память уходит на три потребителя: операционную систему, СУБД и рабочие процессы сервера 1С (каждый rphost может занимать от сотен мегабайт до нескольких гигабайт). Рабочий ориентир для клиент-серверного режима: 2–4 ГБ на активного пользователя плюс резерв под кэш СУБД. Для 20 пользователей разумный минимум — 64 ГБ, для 40–50 — 128 ГБ. Память должна работать в многоканальном режиме — ставьте модули парами по каналам.
Диски — самое критичное место для СУБД. Жёсткие диски (HDD) под рабочую базу 1С в клиент-серверном режиме использовать не следует: случайные операции чтения/записи и запись журнала транзакций требуют низких задержек, которые дают только SSD. Оптимальная схема — SSD в RAID 1 или RAID 10 под базу и журнал транзакций, причём журнал желательно вынести на отдельный массив или хотя бы отдельный раздел.
Требования к SSD: серверные (enterprise) модели с высоким ресурсом записи (DWPD от 1 и выше для активных баз) и защитой от отключения питания. Дешёвые потребительские SSD деградируют под нагрузкой СУБД и могут стать узким местом через несколько месяцев. RAID-контроллер желателен аппаратный с кэшем и батареей/конденсатором (BBU/суперконденсатор) — это ускоряет запись и защищает данные при сбое питания.
| Компонент | До 10 пользователей | 10–30 пользователей | 30–60 пользователей |
|---|---|---|---|
| Режим | Файловый или клиент-серверный | Клиент-серверный | Клиент-серверный, возможно два сервера |
| CPU | 4 ядра, высокая частота | 6–8 ядер, высокая частота | 8+ ядер, высокая частота |
| RAM | 16–32 ГБ | 64 ГБ | 128 ГБ и более |
| Диски | 2 × SSD RAID 1 | SSD RAID 10, отдельный том под журнал | Enterprise SSD RAID 10, журнал на отдельном массиве |
| Сеть | 1 Гбит/с | 1 Гбит/с | 1–10 Гбит/с между сервером 1С и СУБД |
Выбор СУБД и операционной системы
1С:Предприятие поддерживает MS SQL Server, PostgreSQL (включая сборки Postgres Pro), Oracle и IBM DB2. На практике выбор почти всегда сводится к двум вариантам: MS SQL Server на Windows или PostgreSQL на Linux. MS SQL проще в администрировании для типового Windows-администратора, стабильно работает с 1С «из коробки», но требует лицензий, стоимость которых зависит от числа ядер.
PostgreSQL бесплатен в базовом варианте и при грамотной настройке показывает сопоставимую производительность, но требует администратора, который умеет его обслуживать: настраивать shared_buffers, work_mem, автовакуум, мониторить блокировки. «Поставил и забыл» с PostgreSQL под нагруженной 1С не работает — без тюнинга производительность может быть заметно ниже, чем у MS SQL.
Операционная система: Windows Server привычнее для большинства инфраструктур, Linux (поддерживаемые дистрибутивы) экономит на лицензиях ОС. Сам сервер 1С:Предприятия существует в версиях для обеих платформ, поэтому связка «Linux + PostgreSQL + сервер 1С» полностью рабочая и популярна у компаний, снижающих затраты на лицензии.
Сравнение вариантов СУБД
Проще внедрить и обслуживать, предсказуемая работа с 1С. Ограничение — стоимость лицензий, растущая с числом ядер.
Нулевая стоимость лицензий, хорошая производительность после настройки. Ограничение — нужен специалист по тюнингу и сопровождению.
Минимальные затраты и простота для 5–10 пользователей. Ограничение — плохая масштабируемость и риск повреждения базы при сбоях.
Виртуализация и размещение: физический сервер, ВМ или облако
Сервер 1С и СУБД можно разворачивать на виртуальных машинах (Hyper-V, VMware, KVM) — это штатная и распространённая практика. Виртуализация упрощает резервное копирование, миграцию и масштабирование, но добавляет требований: виртуальному диску с базой нужны гарантированные IOPS, а не «общий» медленный пул хранения, иначе тормоза гостевой СУБД будут необъяснимы с точки зрения самой ВМ.
Правила для виртуализации под 1С: выделяйте ВМ фиксированные ресурсы CPU и RAM без агрессивного оверселлинга, размещайте диски базы на SSD-хранилище хоста, отключайте экономию энергии на гипервизоре (режим High Performance). Динамическая память (dynamic memory) для ВМ с СУБД не рекомендуется — СУБД рассчитывает кэш исходя из доступного объёма.
Облачный вариант (аренда ВМ или готовые сервисы 1С) подходит компаниям без своего серверного помещения и штатного администратора. Плюсы — быстрый старт и включённое резервное копирование, минусы — ежемесячная оплата, зависимость от канала связи и ограниченный контроль над производительностью дисковой подсистемы. Для распределённых команд и удалённой работы облако часто удобнее собственного сервера в офисе.
Как выбрать вариант размещения
Расчёт конфигурации и проверка под нагрузкой
Порядок расчёта: посчитайте число одновременно активных пользователей (не общее число сотрудников, а тех, кто реально работает в базе в пике), оцените размер базы и темп её роста, определите самую тяжёлую операцию (проведение больших документов, закрытие месяца, пересчёт итогов). От этих трёх чисел выбираются CPU, RAM и диски.
После развёртывания сервер нужно проверить до перевода пользователей. Минимальный набор: тест дисковой подсистемы на задержки (для СУБД критичны миллисекунды на операцию записи в журнал), синтетическая проверка однопоточной производительности CPU и нагрузочный тест самой 1С — например, массовое проведение документов в копии базы с замером времени.
В эксплуатации контролируйте типовые метрики: загрузку CPU в часы пик, свободную память (СУБД не должна вытесняться в swap), длину дисковой очереди и время отклика транзакций. Рост дисковой очереди и swap — первые сигналы, что сервер достиг предела и пора планировать апгрейд, а не ждать жалоб пользователей.
- 1Посчитайте активных пользователей и измерьте размер базы
- 2Выберите режим: файловый или клиент-серверный
- 3Подберите CPU с высокой однопоточной производительностью
- 4Рассчитайте RAM: 2–4 ГБ на пользователя плюс резерв под СУБД
- 5Заложите enterprise SSD в RAID 1/10 с отдельным томом под журнал
- 6Выберите СУБД и ОС исходя из бюджета и компетенций администратора
- 7Проведите нагрузочное тестирование на копии базы до запуска
Типичные ошибки и ограничения
Самая дорогая ошибка — покупка сервера «по классу», а не по задаче: двухпроцессорная машина с медленными ядрами и HDD-массивом стоит дорого и работает под 1С хуже, чем однопроцессорная система с быстрым CPU и SSD. Вторая распространённая ошибка — экономия на памяти: СУБД, которой не хватает RAM под кэш, начинает читать данные с диска, и производительность падает в разы.
Отдельная группа ошибок — эксплуатационные: отсутствие ИБП и корректного завершения работы при отключении питания, размещение базы и бэкапов на одном массиве, отсутствие регламентного обслуживания СУБД (обновление статистики, перестроение индексов, контроль журнала транзакций). Сервер, выбранный правильно, но не обслуживаемый, через год работает заметно хуже.
Помните и о лицензионных ограничениях: для клиент-серверного режима нужны лицензии на сервер 1С:Предприятия и на СУБД (для MS SQL — по ядрам или Server+CAL), а число пользовательских лицензий 1С должно покрывать одновременные сеансы. Экономия на лицензиях при росте компании приводит к невозможности легально расширить систему.
Как проверить, что сервер справляется
Стабильно в пиковые часы, без роста в разы
В часы пик проведение замедляется в несколько раз
Очередь близка к нулю, задержки в единицах миллисекунд
Постоянная очередь, задержки десятки миллисекунд и выше
Swap не используется, кэш СУБД стабилен
Активный swap, ОС вытесняет СУБД из памяти
До 60–70% с запасом на всплески
Устойчиво выше 85–90%, очереди к процессору
Что важно запомнить
Сервер под 1С выбирают по трём осям: быстрые ядра CPU, достаток RAM (2–4 ГБ на активного пользователя плюс СУБД) и enterprise SSD в отказоустойчивом RAID. До 10 пользователей возможен файловый режим, дальше — клиент-серверный с MS SQL или PostgreSQL. После развёртывания обязательно нагрузочное тестирование и регулярный мониторинг дисков, памяти и CPU.
Частые вопросы
Можно ли разместить сервер 1С и СУБД на одной машине?
Да, для малой и средней нагрузки (примерно до 30–40 активных пользователей) это нормальная и распространённая схема — главное, чтобы памяти хватало обоим компонентам. При дальнейшем росте нагрузки СУБД и сервер приложений начинают конкурировать за ресурсы, и их разносят на разные серверы.
Сколько пользователей выдержит файловый режим 1С?
Комфортная граница — 5–10 одновременно работающих пользователей при небольшой базе. Дальше растут блокировки и риск повреждения файла при сбоях сети. Если пользователей больше или планируется рост, сразу закладывайте клиент-серверный режим — миграция позже всё равно потребуется, но пройдёт болезненнее.
Что лучше для 1С: MS SQL или PostgreSQL?
При наличии бюджета и Windows-администратора MS SQL обычно проще во внедрении и предсказуемее. PostgreSQL исключает затраты на лицензии СУБД, но требует специалиста, способного настроить и сопровождать его под нагрузкой 1С. По итоговой производительности при грамотной настройке варианты сопоставимы.
Нужен ли отдельный сервер под терминальный доступ к 1С?
Если пользователи подключаются через RDP, терминальный сервер лучше держать отдельно от сервера СУБД: сеансы пользователей непредсказуемо потребляют память и CPU, что мешает стабильной работе базы. Для небольшой компании допустимо совмещение терминального сервера и сервера 1С при достаточном запасе ресурсов.
Как понять, что пора менять или расширять сервер?
Тревожные признаки: устойчивая загрузка CPU выше 85% в часы пик, активное использование swap, рост дисковой очереди и задержек записи, замедление проведения документов без изменений в конфигурации. Сначала проверьте обслуживание СУБД (индексы, статистика, журнал) — часто «нехватка сервера» оказывается отсутствием регламентных работ.
Можно ли запустить сервер 1С на обычном офисном компьютере?
Для файлового режима на несколько пользователей — да, мощный офисный ПК с SSD справится. Для клиент-серверного режима это рискованно: нет отказоустойчивого RAID с аппаратным контроллером, ECC-памяти, дублированного питания и корректного охлаждения под постоянной нагрузкой. Отказ такого «сервера» останавливает работу всей компании.