Какой сервер нужен для 1С: конфигурация под число пользователей

Что в сервере решает для 1С

В отличие от виртуализации, где правят число ядер и объём памяти, 1С чувствительна к другому. Многие операции платформы — проведение документов, расчёты, отчёты — упираются в производительность одного потока, то есть в частоту ядра. А отклик интерфейса и тяжёлые выборки упираются в скорость дисков, на которых живёт база.

Отсюда практический вывод: для 1С связка «высокая частота ядра плюс быстрые NVMe-диски плюс достаточно ECC-памяти» обычно даёт больше, чем дорогой многоядерный процессор с медленными дисками. Число ядер тоже важно — но в первую очередь для многопользовательской нагрузки и фоновых заданий, а не для скорости отдельной операции. Как соотносятся узлы сервера в целом, разобрано в гайде по выбору сервера. Вывод: для 1С сначала частота и диски, потом число ядер.

Файловый или клиент-серверный режим

Требования к серверу сильно зависят от того, как развёрнута 1С.

Файловый режим — база лежит файлом, к которому обращаются клиенты. Прост в запуске, но плохо держит многопользовательскую нагрузку и большие базы: с ростом числа пользователей и объёма начинаются блокировки и замедления. Подходит для очень небольших внедрений.

Клиент-серверный режим — данные хранит полноценная СУБД (например, PostgreSQL или совместимая), а сервер 1С обрабатывает логику. Это рабочий вариант для серьёзной нагрузки: лучше масштабируется, надёжнее, корректнее работает с блокировками. Под него и подбирают серьёзный сервер. Правило простое: больше нескольких активных пользователей или растущая база — переходите в клиент-серверный режим, и сервер проектируйте уже под СУБД.

Процессор: частота против числа ядер

Это главный нюанс выбора под 1С. Поскольку многие операции платформы однопоточные, процессор с высокой частотой ядра часто даёт более «быструю» 1С, чем процессор с большим числом медленных ядер при той же цене.

Но крайности тоже вредны. Слишком мало ядер — и при многопользовательской работе, фоновых заданиях и регламентных операциях сервер начнёт упираться в параллелизм. Поэтому под 1С берут сбалансированный процессор: высокая частота плюс разумное число ядер под число пользователей, чаще в однопроцессорной конфигурации — она проще и без NUMA-нюансов. Подобрать серверный процессор можно в разделе серверные процессоры; конкретную модель под вашу нагрузку поможем выбрать в QC-Lab. Вывод: частота — в приоритете, ядра — под число пользователей и фон.

Диски: почему NVMe и RAID

Диски — вторая половина быстродействия 1С. База данных постоянно читает и пишет, и медленные диски становятся узким местом раньше процессора.

• NVMe SSD под базу. Для базы СУБД берут серверные NVMe-накопители: низкие задержки прямо ускоряют отклик 1С на тяжёлых операциях.
• RAID под надёжность. База в RAID 1 или RAID 10 переживает отказ диска без потери данных и без остановки работы. RAID не отменяет резервное копирование — это отдельная обязательная задача.
• Выносливость под запись. СУБД активно пишет, поэтому важна выносливость SSD (ресурс перезаписи); серверные диски рассчитаны на это, потребительские быстро вырабатываются.

Подобрать накопители — серверные SSD; выносливость и совместимость с контроллером проверяем в QC-Lab. Вывод: быстрые NVMe под базу и RAID под надёжность — обязательны для боевой 1С.

Память под 1С и СУБД

Памяти под 1С нужно достаточно, чтобы и серверу 1С, и СУБД хватало под кэш, и тяжёлые операции не упирались в нехватку. Серверная память обязательно с коррекцией ошибок (ECC) — для базы данных целостность критична.

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

Конфигурация по числу пользователей

Главный множитель требований — сколько человек работает в базе одновременно. Ниже ориентиры, от чего отталкиваться; точную конфигурацию считаем под вашу базу и сценарий.

Числа в таблице намеренно качественные: реальная конфигурация зависит от размера базы, интенсивности работы и типовых операций. Пришлите число пользователей и характер нагрузки — соберём конкретную машину и протестируем её в QC-Lab. Связка 1С и СУБД на одном сервере оправдана до определённого масштаба; на больших внедрениях их разносят, чтобы каждый узел не мешал другому.

Частые ошибки при выборе сервера под 1С

• Гнаться за числом ядер. Многоядерный процессор с низкой частотой не ускорит однопоточные операции 1С — частота важнее.
• Экономить на дисках. Быстрый процессор с медленными дисками под базу не раскроется: отклик упрётся в диск.
• Оставаться в файловом режиме при росте. С числом пользователей и объёмом базы файловый режим начинает тормозить и блокировать — пора в клиент-серверный.
• Ставить потребительские SSD под базу. Они быстро вырабатывают ресурс на интенсивной записи СУБД — нужны серверные диски.
• Забывать про бэкап. RAID спасает от отказа диска, но не от ошибки или шифровальщика — резервное копирование базы обязательно.

Когда отдельный сервер под 1С не нужен. Для двух-трёх пользователей в небольшой файловой базе мощный сервер избыточен: задачу закроет обычный надёжный компьютер или сетевое хранилище с регулярным бэкапом. Отдельный сервер оправдан, когда пользователей становится больше, база растёт, нужен клиент-серверный режим и важна непрерывность работы — то есть когда простой и потеря данных дороже самого сервера.

Частые вопросы