Администрирование · 12 мин
Какой сервер нужен для 1С 8.3: как выбрать и не переплатить
Как подобрать сервер для 1С 8.3: требования к процессору, памяти и дискам, выбор СУБД, расчёт нагрузки по числу пользователей и типичные ошибки при покупке.
Производительность 1С 8.3 в клиент-серверном режиме упирается не в «мощность сервера вообще», а в три конкретных компонента: частоту процессора, объём и скорость оперативной памяти, быстродействие дисковой подсистемы. Ошибка в любом из них приводит к характерным симптомам: медленному проведению документов, долгому формированию отчётов и жалобам пользователей на «зависания».
Ключевая особенность платформы 1С — большинство операций выполняется однопоточно. Запрос к базе, проведение документа, пересчёт итогов обрабатываются одним ядром процессора. Поэтому сервер с 32 медленными ядрами для 1С работает хуже, чем сервер с 8 быстрыми ядрами на высокой частоте. Это главный принцип, от которого зависит весь выбор.
Второй фактор — количество пользователей и характер нагрузки. Файловая база для пяти бухгалтеров и клиент-серверная база торгового предприятия с сотней одновременных сеансов требуют принципиально разного оборудования. Ниже разобраны критерии выбора, расчёт ресурсов и типичные ошибки.
Файловый или клиент-серверный режим: что определяет выбор железа
Прежде чем считать гигагерцы и гигабайты, определите режим работы. В файловом режиме база лежит в общей папке, а вся логика выполняется на компьютерах пользователей. Сервер здесь фактически выполняет роль файлового хранилища, и его требования минимальны — важнее сеть и диски. Файловый режим разумно использовать примерно до 5–10 одновременных пользователей и при размере базы до нескольких гигабайт.
В клиент-серверном режиме работает связка «сервер 1С:Предприятия + СУБД» (PostgreSQL, MS SQL Server, IBM Db2 или Oracle). Именно этот вариант требует полноценного сервера и правильного расчёта ресурсов. Признаки того, что пора переходить на клиент-серверный режим: база выросла, документы проводятся по несколько секунд, пользователи мешают друг другу блокировками, а регламентные операции приходится выполнять ночью.
Процессор: почему частота важнее количества ядер
Типичная ошибка — купить серверный процессор с большим числом ядер и низкой частотой «с запасом». Для 1С это деньги на ветер: один запрос или проведение документа обрабатывается одним потоком, и скорость этой операции определяется частотой и производительностью одного ядра. Ориентир — процессоры с частотой от 3 ГГц и выше с хорошим показателем производительности на ядро.
Количество ядер всё же нужно, но под параллельную нагрузку: одновременные сеансы пользователей, фоновые задания, работа СУБД. Практический ориентир для небольшой и средней компании — 8–16 ядер. Большее число оправдано только при сотнях одновременных сеансов и после анализа реальной загрузки.
Проверить, упирается ли система в процессор, можно штатными средствами мониторинга: если при жалобах на «тормоза» одно ядро загружено на 100%, а остальные простаивают — проблема именно в однопоточной производительности, и добавление ядер не поможет.
Оперативная память: сколько нужно на самом деле
Память расходуют три потребителя: рабочие процессы сервера 1С (rphost), буферный кэш СУБД и операционная система. Упрощённый расчёт: 1–2 ГБ на каждого активного пользователя для процессов 1С, плюс память под СУБД — желательно, чтобы рабочий набор данных (активно используемая часть базы и индексов) помещался в кэш.
Для базы в 50–100 ГБ разумно выделять СУБД десятки гигабайт под буферы. Общий объём для сервера на 30–50 пользователей обычно составляет 64–128 ГБ. Лучше брать память с запасом и с возможностью расширения: нехватка ОЗУ проявляется резко — система начинает использовать подкачку, и производительность падает катастрофически.
Используйте серверную память с коррекцией ошибок (ECC). Сбой в обычной памяти может незаметно повредить данные в буферах СУБД, что для учётной системы недопустимо.
Дисковая подсистема: главный резерв скорости
База данных 1С постоянно выполняет случайные операции чтения и записи небольшими блоками — это наихудший сценарий для механических дисков. HDD в качестве носителя для рабочей базы — гарантированный источник медленной работы, особенно при одновременной активности пользователей.
Правильный минимум — серверные SATA/SAS SSD, оптимально — NVMe-диски. Для журналов транзакций СУБД (где важна надёжность записи) желательны диски с защитой от потери питания или RAID-контроллер с энергонезависимым кэшем. Размещайте базу, журнал транзакций и временные файлы (tempdb в MS SQL) на отдельных физических устройствах или как минимум разделах — это снижает конкуренцию за дисковые ресурсы.
Избыточность обязательна: RAID 1 или RAID 10 для данных. RAID 5 на SSD использовать можно, но он медленнее на запись и дольше восстанавливается. Помните: RAID не заменяет резервное копирование — он защищает только от отказа диска, но не от удаления данных, вирусов и логических повреждений.
Выбор СУБД и её влияние на конфигурацию сервера
1С 8.3 поддерживает несколько СУБД, и выбор влияет как на стоимость, так и на требования к железу:
- PostgreSQL (в сборке, адаптированной для 1С) — бесплатный вариант, требователен к грамотной настройке конфигурации; без тюнинга параметров памяти работает заметно хуже своих возможностей.
- MS SQL Server — платный, но предсказуемый в настройке и сопровождении; редакция Standard покрывает потребности большинства средних компаний, Express имеет жёсткие ограничения по памяти и размеру базы и подходит только для небольших внедрений.
- IBM Db2 и Oracle — варианты для крупных организаций с существующей инфраструктурой этих вендоров.
На одной машине с СУБД сервер 1С и база данных будут конкурировать за память и процессор. До 20–30 пользователей совмещение допустимо при достаточном объёме ОЗУ. При большей нагрузке разнесение на два сервера даёт стабильный выигрыш и упрощает диагностику проблем.
Сравнение вариантов размещения
Подходит до 20–30 пользователей при объёме ОЗУ от 64 ГБ. Дешевле и проще в обслуживании, но компоненты конкурируют за ресурсы.
Оптимально от 30–50 пользователей. Позволяет независимо масштабировать и обслуживать компоненты, требует быстрой сети между серверами.
Удобно для управления и резервного копирования, но гипервизор добавляет накладные расходы; требуется выделение ресурсов без избыточной переподписки CPU.
Подходит при отсутствии своего помещения и администратора. Важно выбирать конфигурации с высокочастотными vCPU и быстрыми дисками, а не минимальные тарифы.
Расчёт конфигурации по числу пользователей
Ниже — ориентировочные конфигурации для типичных сценариев. Это отправные точки, а не нормативы: реальная нагрузка зависит от конфигурации 1С, размера базы и интенсивности работы.
| Сценарий | Процессор | Память | Диски |
|---|---|---|---|
| До 10 пользователей, файловый режим или небольшая база | 4–6 ядер, от 3 ГГц | 16–32 ГБ | 2 × SSD в RAID 1 |
| 10–30 пользователей, 1С и СУБД на одном сервере | 8 ядер, от 3 ГГц | 64 ГБ | SSD/NVMe в RAID 1 или RAID 10 |
| 30–80 пользователей, разнесённые 1С и СУБД | 8–16 ядер на каждый сервер | 32–64 ГБ на 1С, 64–128 ГБ на СУБД | NVMe под базу и журналы, RAID 10 |
| Более 100 пользователей | По результатам нагрузочного тестирования | От 128 ГБ на СУБД | NVMe RAID 10, выделенные диски под tempdb и журналы |
Обратите внимание на сеть: между сервером 1С и СУБД нужен канал от 1 Гбит/с, оптимально 10 Гбит/с при высокой нагрузке. Клиентские подключения менее требовательны, но нестабильная сеть у пользователей проявляется как обрывы сеансов и ошибки.
- 1Определите режим работы: файловый или клиент-серверный, и число одновременных пользователей
- 2Оцените размер базы и темп её роста за последний год
- 3Рассчитайте память: 1–2 ГБ на пользователя плюс буфер СУБД под рабочий набор данных
- 4Выберите процессор с высокой частотой ядра, а не с максимальным числом ядер
- 5Заложите SSD/NVMe в RAID для базы и журналов, отдельно продумайте резервное копирование
- 6После запуска снимите показатели нагрузки в часы пик и скорректируйте конфигурацию
Проверка результата после запуска
После развёртывания сервера работа не заканчивается — нужно убедиться, что конфигурация справляется. Снимите базовые показатели в часы пиковой нагрузки: загрузку каждого ядра процессора, использование памяти, дисковые очереди и время отклика типовых операций (проведение документа, формирование стандартного отчёта).
Полезный инструмент — технологический журнал платформы 1С: он позволяет найти длительные запросы и блокировки. Если сервер мощный, а конкретный отчёт работает медленно, причина часто в неоптимальном запросе или отсутствующем индексе, а не в железе.
Как проверить результат
Ни одно ядро не загружено постоянно на 100%, средняя загрузка до 60–70%
Отдельное ядро «прибито» к 100% — узкое место в однопоточной производительности
Файл подкачки практически не используется, есть свободный резерв
Активная подкачка, СУБД не хватает буферов — нужно добавить ОЗУ
Очередь небольшая, отклик в пределах единиц миллисекунд
Растущая очередь и отклики в десятки миллисекунд — диски не справляются
Документы проводятся быстро, отчёты формируются за приемлемое время без роста в часы пик
Время операций сильно деградирует при росте числа пользователей — ищите блокировки и нехватку ресурсов
Типичные ошибки при выборе и настройке
Отдельно выделим виртуализацию. Размещать 1С и СУБД в виртуальных машинах — нормальная практика, но избегайте переподписки ресурсов: если гипервизор выдаёт виртуальным машинам больше ядер и памяти, чем есть физически, в часы пик начинаются непредсказуемые просадки. Для нагруженных баз закрепляйте ресурсы за ВМ и используйте диски с фиксированным выделением.
Что важно запомнить
Для 1С 8.3 решают частота ядра процессора, достаточный объём памяти под сеансы и кэш СУБД, и быстрые SSD/NVMe-диски в отказоустойчивом массиве. Считайте конфигурацию от числа пользователей и размера базы, после запуска проверяйте загрузку в часы пик и не забывайте про резервное копирование.
Частые вопросы
Можно ли использовать обычный офисный компьютер как сервер для 1С?
Для файлового режима на несколько пользователей — да, если установить SSD и достаточный объём памяти. Для клиент-серверного режима и базы, от которой зависит учёт, лучше серверное оборудование: ECC-память, RAID, резервный блок питания и возможность работы 24/7 без деградации. Риск простоя и потери данных на офисном ПК обычно обходится дороже экономии.
Что лучше для 1С: PostgreSQL или MS SQL Server?
Обе СУБД официально поддерживаются. PostgreSQL бесплатен, но требует грамотной настройки и сопровождения; MS SQL Server платный, но проще в администрировании и предсказуемее «из коробки». Если в штате нет администратора, способного тюнинговать PostgreSQL, платная СУБД часто оказывается выгоднее по совокупным затратам.
Почему 1С тормозит, хотя сервер мощный?
Частые причины: медленные диски, нехватка памяти под кэш СУБД, настройки СУБД по умолчанию, неоптимальные запросы в конфигурации, блокировки при одновременной работе пользователей. Начните с мониторинга загрузки ядер, памяти и дисковых очередей, затем анализируйте длительные запросы через технологический журнал.
Сколько памяти выделить под СУБД?
Ориентир — чтобы активно используемая часть базы и индексов помещалась в буферный кэш. На практике СУБД выделяют значительную часть ОЗУ сервера, оставляя резерв под сервер 1С и операционную систему. Для MS SQL обязательно задайте максимальный объём памяти явно, иначе сервер может занять почти всю память машины.
Нужен ли отдельный сервер под резервные копии?
Копии должны храниться отдельно от основного сервера — на другом устройстве, NAS или в облачном хранилище. Копия на том же дисковом массиве не защищает ни от отказа оборудования, ни от шифровальщиков. Проверяйте восстановление из копий регулярно: непроверенная копия не считается копией.
Когда файловую базу пора переводить в клиент-серверный режим?
Сигналы перехода: больше 5–10 одновременных пользователей, заметный рост времени проведения документов, конфликты блокировок, размер базы в несколько гигабайт и продолжающийся рост, а также требования к бесперебойной работе и разграничению прав. Переход на клиент-серверный режим в этой ситуации дешевле, чем постоянные простои пользователей.