Сервер для 1С: как выбрать CPU, память и диски без переплат

С чего начать: какие задачи будет делать сервер

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

Что обычно работает рядом с 1С

Кроме самой 1С почти всегда есть СУБД (чаще MS SQL Server или PostgreSQL), фоновые задания, обмены с сайтом или другими системами, печать, почта, интеграции с банком и ЭДО, а также тяжелые отчеты. Если все это живет на одном сервере, нагрузка складывается, и узкое место появляется неожиданно.

Одинаковое число пользователей не означает одинаковую нагрузку. 20 бухгалтеров, которые весь день проводят документы, дают одну картину. А 20 пользователей, где половина постоянно запускает отчеты «за год по всем складам», а пара человек гоняет обмены каждые 5 минут, легко перегружают даже более мощный сервер.

Что чаще всего тормозит

На практике чаще всего упираются в диск (много мелких операций и ожиданий), затем в память (вытеснение кэша и активное использование файла подкачки), и только потом в CPU. Сеть становится проблемой, когда база и пользователи на разных площадках или когда бэкапы и обмены идут в рабочее время.

Перед выбором железа соберите короткий набор данных:

• сколько одновременных пользователей и какие роли (бухгалтерия, склад, продажи, руководители)
• размер базы сейчас и прогноз роста на 1-2 года
• какие операции самые тяжелые (отчеты, закрытие месяца, обмены, загрузки)
• где будет СУБД (на этом же сервере или отдельно)
• требования по доступности (нужно ли резервирование и быстрое восстановление)

Эти ответы сразу подскажут, где нельзя экономить и где точно не стоит переплачивать за ядра, которые будут простаивать.

Типовые профили нагрузки 1С, ERP и баз данных

Сервер ведет себя по-разному в зависимости от того, что именно делают люди в системе. Полезно заранее понять, какой профиль нагрузки у вас основной: «много пользователей онлайн», «пик раз в месяц», «тяжелые отчеты» или «интеграции 24/7».

1) Ежедневная онлайн-работа

Это одновременная работа пользователей: ввод, проведение документов, печать, небольшие запросы. Здесь важны быстрая реакция на короткие операции и отсутствие «подвисаний» в час пик. Чаще всего упираются в производительность одного ядра CPU и задержки диска (особенно при активной записи).

2) Регламентные задания и закрытие периода

Ночью или в конце месяца запускаются пересчет себестоимости, закрытие периода, перепроведение, обмены. Нагрузка становится длинной и тяжелой, иногда хорошо распараллеливается, но не всегда. Частая ошибка - покупать много ядер «на всякий случай», хотя реальное ограничение может быть в нескольких потоках или в скорости дисков.

3) Тяжелые отчеты и произвольные запросы

Когда бухгалтер или аналитик строит сложный отчет, база читает много данных и сортирует их. Обычно особенно важны:

• достаточно памяти под кэш (чтобы меньше читать с диска)
• быстрые SSD (часто лучше NVMe) для временных операций
• понятные правила, кто и когда запускает самые тяжелые отчеты

4) Интеграции, терминальный доступ и виртуализация

Интеграции с ERP/CRM, EDI, API и файловые обмены дают ровную фоновую нагрузку и постоянные записи. Терминальный доступ или виртуализация добавляют «соседей» по CPU и памяти.

Типичный сценарий: днем 40 пользователей «жмут кнопки», а вечером стартует закрытие месяца и параллельно идут обмены. В таком случае разумнее вложиться в память и быстрые диски, а также запланировать окно для тяжелых заданий, чем переплачивать за ядра, которые днем простаивают.

Данные, которые нужно собрать перед покупкой

Перед тем как выбирать сервер для 1С, соберите факты о нагрузке. Без них легко купить лишние ядра, но упереться в медленные диски или нехватку памяти.

Начните с пользователей. Важно не сколько людей числится в штате, а сколько работает одновременно в самые загруженные часы. Один человек, который закрывает месяц и запускает тяжелые отчеты, может давать нагрузку как несколько «тихих» пользователей.

Дальше оцените базу: текущий размер, сколько занимают файлы базы и журналов, и как быстро это растет. Планируйте горизонт 1-3 года, чтобы не менять сервер слишком рано. Если рост рывками (после интеграции с сайтом, внедрения сканирования архивов и т.п.), это тоже важно отметить.

Зафиксируйте пики: конец месяца, утро понедельника, сезонные продажи, массовая загрузка документов. Отдельно запишите, что именно происходит в пик: проведение документов, расчет зарплаты, закрытие периода, регламентные задания, обмены.

Минимум, который стоит принести поставщику:

• число одновременных пользователей в обычный день и в пик
• размер базы и годовой прирост
• 3-5 самых медленных операций «по ощущениям» и когда они случаются
• какая СУБД и где будет жить база (локально на сервере, на отдельном хранилище, в виртуальной машине)
• есть ли фоновые задания, обмены, бэкапы в рабочее время

Пример: в офисе 60 сотрудников, но одновременно в 1С работают 18-25, а «тормозит» проведение и отчеты в конце месяца. В таком случае чаще важнее быстрые диски и достаточная память, чем максимальное число ядер.

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

Для задач 1С и SQL часто важнее не количество ядер, а скорость одного ядра. Многие операции выполняются последовательно: проведение документов, часть запросов, блокировки, логика приложения. Если ядро медленное, система будет «тормозить» даже на процессоре с большим числом ядер.

Дополнительные ядра тоже нужны, но по понятным причинам: много пользователей одновременно, тяжелые отчеты запускаются несколькими людьми сразу, активно работают фоновые задания, на сервере крутятся несколько баз.

Простой способ понять, что вы переплачиваете за ядра: посмотрите пиковую загрузку CPU в рабочее время. Если в тяжелые моменты загрузка редко поднимается выше 30-40%, а жалобы на скорость есть, причина обычно в дисках, памяти, производительности на ядро или настройках. И наоборот: если загрузка долго держится 80-90% и растет очередь задач, ядра действительно заканчиваются.

Полезно заранее решить, где будут роли. Сервер для 1С, сервер баз данных и терминальный сервер лучше не смешивать без необходимости: каждая роль по-своему ест CPU и может мешать другим.

Чтобы не ошибиться с запасом по CPU:

• оставляйте около 20-30% свободной мощности в типичный пик
• учитывайте сезонные нагрузки (закрытие месяца, квартала)
• закладывайте запас, если планируются новые базы, интеграции или отчеты
• проверяйте диски и память, прежде чем докупать ядра

Память: сколько нужно и что важнее объема

Нехватка RAM часто выглядит как «медленные диски». Система начинает активно выгружать данные в файл подкачки, а 1С и СУБД получают задержки на чтение и запись. В итоге можно купить быстрые SSD и не увидеть эффекта, потому что узкое место - память.

Ориентир простой: чем больше данных помещается в RAM, тем реже сервер ходит на диск. Для 1С и ERP память расходуют рабочие процессы 1С, кэш СУБД, фоновые задания (обмены, регламентные), плюс ОС и антивирус.

Практичные ориентиры по объему:

• 64 ГБ часто хватает для небольшого офиса: до нескольких десятков пользователей и умеренной базы, без тяжелых отчетов «по всему периоду».
• 128 ГБ обычно нужно, если пользователей много, база быстро растет, а регламентные задания и обмены идут почти без пауз.
• 256 ГБ и выше оправдано, когда база крупная, важен большой кэш СУБД, есть несколько информационных баз или параллельно работают аналитика и интеграции.

Важно не только «сколько», но и «как установлено». Современные платформы выигрывают от многоканальной памяти, поэтому лучше ставить одинаковые модули и заполнять каналы симметрично. Смешанные по объему и частоте планки могут снизить скорость без видимой причины.

Закладывайте запас под рост и обновления. Хорошее правило для 1С - держать свободными хотя бы 20-30% RAM в обычный рабочий день.

Пример: если сейчас 40 пользователей и база 150-200 ГБ, 64 ГБ могут работать «впритык». При росте базы и усложнении отчетов начнется подкачка. Переход на 128 ГБ часто дает больший эффект, чем замена дисков на более быстрые.

Диски и хранение: как не упереться в IOPS

В задачах 1С, ERP и баз данных часто «тормозит» не процессор, а дисковая подсистема. Смотрите не на «скорость до 7000 МБ/с» в паспорте, а на задержку (latency) и стабильные IOPS под смешанной нагрузкой. Если задержка прыгает, пользователи увидят это как долгие проведения, зависания форм и медленные отчеты, даже если CPU почти свободен.

Минимальная рабочая схема - разделить роли хранения, чтобы операции не мешали друг другу. Часто это выглядит так:

• ОС и служебные файлы на отдельном томе
• файлы базы данных на быстром томе
• журналы (лог) на отдельном быстром томе
• бэкапы на отдельном диске или массиве, где важнее объем, чем IOPS

Выбор между SATA SSD и NVMe простой по смыслу: SATA SSD подходит при умеренной нагрузке и когда важнее цена за гигабайт; NVMe нужен, когда много одновременных операций и критична минимальная задержка. Нередко разумно смешивать: базу и логи держать на NVMe, а ОС и бэкапы - на SATA SSD или HDD (если окно резервного копирования позволяет).

RAID важен не только для отказоустойчивости, но и для предсказуемой работы. RAID 1 закрывает базовый риск отказа диска. RAID 10 чаще выбирают, когда нужна надежность и высокая производительность на записи, особенно для активных баз и журналов.

Не забывайте про контроллер: кэш и грамотная настройка помогают держать ровную производительность, а защита кэша снижает риск потери данных при сбое питания.

Сеть, резервирование и масштабирование без переделок

Если сервер для 1С и база данных стоят в дата-центре, а пользователи работают по сети, узким местом часто становятся задержки. Для 1С важны короткие задержки и стабильность: даже небольшие скачки времени отклика ощущаются как «подвисания».

10GbE нужно не всегда. Оно оправдано, когда база большая, много одновременных пользователей, есть активный обмен с другими системами, бэкапы уходят по сети или используется сетевое хранилище. Если сервер и диски локальные, а офис до 30-40 пользователей и без тяжелых интеграций, часто достаточно 1GbE, но с запасом по портам и возможностью апгрейда.

Резервирование начинайте с ответа на вопрос: сколько простоя вы готовы терпеть и как быстро нужно восстановиться. Бэкап - это не только «сделать копию», но и иметь место под несколько точек восстановления и регулярно проверять, что восстановление реально работает.

Проверьте заранее:

• куда пишутся копии (отдельный диск, отдельный сервер, репозиторий в сети)
• сколько хранить и по какой схеме
• сколько времени занимает полный и инкрементальный бэкап
• как часто вы тестируете восстановление на отдельной базе

Иногда выгоднее два узла, чем один большой: отдельный сервер под SQL и отдельный под 1С (или терминалы) проще масштабировать и обновлять по очереди.

План роста лучше заложить сразу: свободные слоты под память, запас по дискам и возможность добавить второй сетевой интерфейс.

Варианты архитектуры: один сервер или несколько ролей

Первый выбор - ставить все роли на один сервер или разделять. Для небольшого офиса часто хватает одного сервера: на нем и приложение, и база, и файлы. Это проще в обслуживании и дешевле на старте.

Но по мере роста пользователей и базы данных соседство ролей начинает мешать: диски и память конкурируют, а любая перезагрузка бьет сразу по всем сервисам. Если 1С и база данных критичны, чаще выигрывает разделение: отдельный сервер под СУБД и отдельный под терминалы/приложение. Так проще дать базе быстрые диски и достаточно RAM, а приложению - частоту CPU. Плюс обновления и перезапуски можно делать по очереди.

Один сервер с виртуализацией или несколько физических

Виртуализация удобна, когда нужно несколько ролей, но нет желания покупать отдельные машины. Плюс - гибкость: ресурсы можно перераспределять, проще делать снимки и миграции. Минус - нужен запас по ресурсам и аккуратная настройка, иначе «шум» от одной виртуальной машины замедлит другую.

Минимальные правила:

• держите запас 20-30% по CPU и памяти
• давайте базе данных приоритет по дискам (лучше отдельный пул или том)
• заранее решите, как делаются резервные копии и где они хранятся
• проверьте ограничения по лицензиям 1С, Windows и СУБД для виртуальной среды

Форм-фактор, надежность и скрытые ограничения

Форм-фактор выбирают не по «красоте». Стойка удобна в серверной и для масштабирования. Башня подходит, если нет шкафа и важен низкий шум. Компактный сервер спасает, когда мало места, но он требовательнее к охлаждению.

Надежность лучше заложить сразу: два блока питания, горячая замена дисков, понятная схема вентиляторов. И не забудьте про бытовые ограничения: сколько реально есть питания, выдержит ли помещение тепло, и не будет ли сервер мешать людям шумом.

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

Самая дорогая ошибка - купить «самый мощный» процессор, а потом понять, что система тормозит из-за дисков. Для 1С и многих ERP задержки ввода-вывода важнее, чем лишние ядра. Если база на медленном хранилище, рост частоты CPU не даст заметного эффекта.

Вторая типовая проблема - экономия на памяти. Когда RAM не хватает, сервер уходит в подкачку. Это резко ухудшает отклик и создает иллюзию, что «не тянет процессор», хотя причина в памяти.

Еще одна частая ошибка - складывать в один массив все подряд: ОС, базу, журналы, временные файлы и резервные копии. В результате операции конкурируют за одни и те же IOPS, и в пиковые моменты все замедляется. Разнос по дискам или хотя бы по разным томам обычно дает более заметный эффект, чем апгрейд CPU.

И отдельный болезненный пункт - бэкапы «для галочки». Резервная копия без проверки восстановления не спасает, особенно если копии пишутся на тот же массив, где рабочая база.

Короткая самопроверка перед покупкой:

• измерили дисковую нагрузку (IOPS и задержки), а не только загрузку CPU
• посчитали запас RAM под рост базы и пользователей, чтобы не уходить в своп
• разделили базу, журналы и бэкапы так, чтобы они не мешали друг другу
• сделали тестовое восстановление и зафиксировали реальное время простоя
• продумали сценарий роста на 6-12 месяцев (что добавляем и как)

Короткий чеклист перед заказом оборудования

Перед тем как заказывать сервер, зафиксируйте требования на бумаге. Это помогает не переплатить за ресурсы, которые не будут использоваться, и не упереться в узкое место через пару месяцев.

Проверьте спецификацию по пяти пунктам:

• CPU и реальная нагрузка. Для 1С и многих ERP важнее высокая частота и быстрые ядра, чем их «много». Оставьте запас под пик, а не «в два раза на всякий случай».
• Память и рост на 1-3 года. Оцените текущий объем данных и сколько памяти уже ест СУБД и кэш. Заложите резерв под рост базы, новые отчеты и интеграции.
• Диски и схема томов. Разнесите данные БД и журналы по разным томам, подберите RAID под вашу нагрузку и проверьте, что хранилище дает стабильные IOPS и низкую задержку.
• Сеть и задержка. Уточните, где будут пользователи и терминальные серверы, и какая задержка между ними и сервером. Иногда настройка сети дает эффект быстрее, чем апгрейд CPU.
• Надежность и восстановление. Два блока питания, мониторинг, понятный план бэкапов и регулярная проверка восстановления.

Пример: подбор конфигурации для среднего офиса

Сценарий: 60 пользователей работают в 1С и ERP в одной базе. В обычные дни все ровно, но в конце месяца появляются пики из-за закрытия периода, отчетов и массовых перепроведений. Цель - выдержать пики без переплаты за ресурсы, которые в обычные дни простаивают.

Перед выбором железа соберите метрики хотя бы за неделю (включая один загруженный день). Смотрите не только средние значения, а пики:

• загрузка CPU по ядрам и частота (важно, упираетесь ли вы в 1-2 потока)
• занятая RAM и есть ли своп
• очередь диска и задержки чтения/записи (latency)
• время выполнения типовых операций в 1С
• размер базы и скорость роста, объем журналов и временных файлов

Сбалансированная конфигурация для такого офиса часто выглядит так: процессор с упором на высокую частоту и умеренное число ядер (нередко 8-12 «быстрых» ядер дают больше пользы, чем 24 «медленных»), 128 ГБ RAM и быстрые диски. Для базы выделяют NVMe SSD, а журналы выносят на отдельный том, чтобы запись не мешала чтению. Под бэкапы и архив используют отдельный массив или отдельные диски попроще.

Как понять, что конфигурация не избыточна: в пике CPU не держится стабильно «в потолок», нет устойчивой очереди диска, а RAM не заканчивается и не уходит в своп. Если CPU низкий, а тормозит, чаще всего виноваты диски, блокировки в базе или неудачное соседство ролей.

План улучшений при росте нагрузки обычно такой: сначала приводят в порядок дисковую подсистему, затем добавляют RAM, и только потом думают о CPU. Когда пользователей станет заметно больше, разделение ролей (база отдельно, терминалы отдельно) почти всегда упрощает жизнь.

Следующие шаги: как согласовать конфигурацию и бюджет

Согласование сервера чаще ломается не на «железе», а на ожиданиях. Сначала зафиксируйте требования в одном коротком документе: какие роли будут на сервере (1С, SQL, терминалы, файловые сервисы), какой рост пользователей и базы вы ждете за 1-2 года, когда можно делать бэкапы и насколько критичен простой.

Полезно сразу договориться о границах. Например: «не больше 2 часов простоя в год» и «ночное окно для бэкапа 3 часа». Эти две фразы напрямую влияют на диски, резервирование и поддержку.

Дальше просите расчет не одной, а 2-3 конфигураций с понятным пояснением, за что вы платите. Сравнивайте не только цену покупки, но и стоимость владения: запас по росту, энергопотребление, обслуживание, поддержку.

Чтобы разговор был предметным, держите порядок:

• подтвердите узкое место (CPU, память или диски) и что именно вы улучшаете
• выберите базовый вариант и «плюс-минус» вариант с понятными компромиссами
• заранее решите, как будет организован мониторинг и поддержка
• проверьте сроки поставки, сервис и наличие запчастей в вашем регионе
• зафиксируйте план роста: что добавляем через год (RAM, диски, второй сервер) и как это делается без остановки

Если вы в Казахстане и важны локальные поставки и обслуживание, имеет смысл обсудить конфигурацию с производителем и интегратором, который умеет закрывать и «железо», и внедрение. Например, GSE.kz производит серверы и занимается системной интеграцией, поэтому можно собрать решение под нужный профиль нагрузки и заранее продумать поддержку и расширение.