Администрирование · 13 мин
Как выбрать процессор для сервера 1С с SQL
Как подобрать процессор для сервера 1С с SQL: частота против числа ядер, требования конфигураций, расчёт нагрузки, типичные ошибки и проверка результата.
Процессор — один из главных факторов скорости связки «1С:Предприятие + СУБД». При этом схема «больше ядер — быстрее работа» здесь не работает: большинство операций 1С и типичные запросы SQL Server или PostgreSQL упираются в производительность одного потока, а не в суммарную мощность всех ядер. Поэтому выбор процессора для 1С SQL-сервера строится вокруг тактовой частоты, архитектуры и разумного числа ядер, а не вокруг рекордных многопроцессорных конфигураций.
Вторая особенность — лицензирование. SQL Server лицензируется по ядрам, а избыточное число медленных ядер увеличивает стоимость владения без прироста скорости. Правильно подобранный процессор с высокой частотой и умеренным числом ядер часто оказывается и быстрее, и дешевле в эксплуатации, чем «топовый» многоядерный чип.
Ниже разобраны критерии выбора: как оценить нагрузку, на какие характеристики смотреть, как отличить процессорную проблему от нехватки памяти или медленных дисков и как проверить результат после замены оборудования.
Почему частота важнее числа ядер
Архитектура 1С:Предприятия устроена так, что ключевые операции — проведение документа, пересчёт итогов, выполнение запроса — выполняются преимущественно в одном потоке. Пользователь, нажимающий «Провести», ждёт завершения одной последовательной цепочки вычислений. Распараллелить её на 32 ядра платформа не сможет, поэтому скорость этой операции определяется производительностью одного ядра.
SQL Server и PostgreSQL умеют параллелить отдельные запросы, но в типовых базах 1С параллелизм включается редко: запросы обычно короткие и многочисленные, а не тяжёлые аналитические. Планировщик запросов сам решает, стоит ли распараллеливание накладных расходов, и для маленьких запросов ответ почти всегда отрицательный.
Практический вывод: процессор с 16 ядрами на 3,5 ГГц для 1С почти всегда предпочтительнее процессора с 32 ядрами на 2,2 ГГц. Разница в частоте напрямую превращается в разницу во времени отклика, а лишние ядра будут простаивать.
На какие характеристики смотреть при выборе
Первый параметр — базовая и турбо-частота. Для сервера 1С ориентир — базовая частота от 3 ГГц и турбо-частота от 4 ГГц и выше. Турбо-режим важен, потому что однопоточные операции 1С как раз выполняются на повышенной частоте одного ядра, пока остальные относительно свободны.
Второй параметр — поколение архитектуры. Производительность на гигагерц растёт от поколения к поколению, поэтому новый процессор на 3 ГГц быстрее старого на тех же 3 ГГц. Сравнивать «гигагерцы в лоб» между разными поколениями и разными производителями некорректно — ориентируйтесь на результаты независимых однопоточных тестов (single-thread benchmark) конкретных моделей.
Третий параметр — объём кэша третьего уровня. Большой кэш ускоряет работу СУБД с «горячими» данными. Четвёртый — поддержка нужного объёма и частоты оперативной памяти: процессор определяет, сколько каналов памяти и какой максимальный объём RAM доступен, а для SQL-сервера память критична не меньше процессора.
| Характеристика | Рекомендуемый ориентир | Почему это важно |
|---|---|---|
| Базовая частота | От 3 ГГц | Определяет скорость однопоточных операций 1С |
| Турбо-частота | От 4 ГГц | Ускоряет проведение документов и запросы |
| Физические ядра | 8–16 для типовой базы | Запас на фоновые задания и параллельные сессии |
| Кэш L3 | Чем больше, тем лучше | Ускоряет доступ СУБД к часто используемым данным |
| Поколение | Актуальное или предыдущее | Рост производительности на гигагерц |
Как оценить нагрузку и число ядер
Число ядер подбирается не по числу пользователей «в справочнике», а по числу одновременно активных сессий и фоновых задач. Сто пользователей, из которых одновременно работают двадцать, создают нагрузку двадцати, а не ста. Плюс добавляются регламентные задания, обмены данными, полнотекстовый поиск и обслуживание самой СУБД.
Грубый практический ориентир: для базы с 10–30 активными пользователями обычно достаточно 8 ядер, для 30–80 активных — 12–16 ядер, для более крупных систем — 16–24 ядра с обязательным анализом фактической загрузки. Это не норматив, а отправная точка: точное число определяется замером.
Замер делается штатными средствами. В Windows — через Performance Monitor (счётчики Processor и Process), в Linux — через top, htop, vmstat. Смотрите загрузку в часы пик: если суммарная загрузка CPU стабильно выше 70–80% в рабочее время — ядер не хватает. Если общая загрузка низкая, но отдельные ядра «прибиты» к 100%, а пользователи жалуются на медленную работу — проблема в частоте, а не в количестве ядер.
- 1Включите сбор счётчиков производительности на сервере СУБД и сервере 1С на период не менее рабочей недели.
- 2Найдите часы пиковой нагрузки и зафиксируйте среднюю и максимальную загрузку CPU в эти периоды.
- 3Проверьте загрузку отдельных ядер: 100% на одном ядре при низкой общей — признак упора в частоту.
- 4Параллельно проверьте ожидания СУБД (locks, disk I/O): если процессор свободен, а запросы ждут диск или блокировки — замена CPU не поможет.
- 5Сопоставьте число активных сессий в пике с числом ядер и рассчитайте запас 20–30% на рост.
Один сервер или разделение ролей 1С и СУБД
Для небольших внедрений сервер 1С и SQL-сервер часто размещают на одной физической машине. Это допустимо при 10–20 пользователях и экономит лицензии, но требует осознанного распределения ресурсов: рабочие процессы 1С (rphost) и процесс СУБД конкурируют за ядра и память.
При разделении ролей на два сервера требования к процессорам различаются. Серверу приложений 1С нужна высокая частота и память под рабочие процессы — именно здесь выполняется код конфигурации. SQL-серверу нужны частота, большой кэш и быстрый доступ к памяти — здесь выполняются запросы. Экономить на частоте нельзя в обоих случаях.
При виртуализации добавляется отдельное требование: выделяйте виртуальным машинам 1С и СУБД зарезервированные vCPU, избегайте сильного oversubscription (когда суммарные vCPU всех машин многократно превышают физические ядра). Конкуренция виртуальных машин за ядра даёт непредсказуемые задержки, которые сложно диагностировать изнутри гостевой системы.
Как выбрать конфигурацию
Лицензии SQL Server и стоимость ядер
SQL Server в редакции Standard и Enterprise лицензируется по ядрам (либо по схеме «сервер + CAL» для Standard). Каждое дополнительное ядро — это прямые расходы на лицензии, и для Enterprise-редакции сумма по ядерной модели может многократно превысить стоимость самого «железа». Поэтому процессор с 32 ядрами «про запас» — это не только бесполезная для 1С мощность, но и ощутимые лишние затраты.
Практический приём — выбирать модели с меньшим числом ядер и максимальной частотой внутри одной линейки. Производители серверных процессоров выпускают специальные «частотно-оптимизированные» модели именно под лицензируемые по ядрам приложения: они дороже за штуку, но дешевле в сумме с лицензиями.
PostgreSQL и другие СУБД с открытой лицензией этим ограничением не обременены, но физический закон остаётся: медленные ядра не ускоряют однопоточные операции. Экономия на лицензиях не отменяет требования к частоте.
Типичные ошибки при выборе процессора
Самая распространённая ошибка — покупка многоядерного процессора с низкой частотой «с запасом». На бумаге 32 ядра выглядят солиднее 12, но пользователи 1С почувствуют только частоту, а бухгалтерия — только счёт за лицензии.
Вторая ошибка — перенос сервера на старое «железо» из резерва. Серверные платформы пяти-семилетней давности проигрывают современным даже при той же частоте из-за архитектуры, а их энергопотребление и риск отказа выше. Третья ошибка — игнорирование теплового пакета: высокочастотный процессор в плохо охлаждаемом корпусе будет сбрасывать частоту (троттлинг), и заявленная производительность останется на бумаге.
Четвёртая ошибка — диагностика «на глазок»: решение о замене CPU принимается по жалобам пользователей без замера счётчиков. Жалобы на «медленную 1С» в половине случаев связаны не с процессором, а с дисками, памятью, блокировками или неоптимальным кодом конфигурации.
Как проверить результат после замены
До и после замены процессора зафиксируйте измеримые показатели: время проведения типового крупного документа, время выполнения регламентных заданий, длительность типовых отчётов, загрузку CPU в часы пик. Без «до» невозможно доказать, что «после» стало лучше.
После ввода нового сервера проверьте, что турбо-режим реально работает: под нагрузкой частота ядер должна подниматься до заявленных значений, а не упираться в лимиты энергосбережения или температуры. В BIOS/UEFI выберите профиль производительности, отключите агрессивные режимы энергосбережения (C-states, power saving) — для серверов 1С это стандартная рекомендация.
Итоговая проверка — поведение системы в пиковый период: закрытие месяца, массовый ввод документов, обмены. Если в пике загрузка CPU держится ниже 70%, время отклика сократилось, а отдельные ядра не «прибиты» к 100% — конфигурация подобрана верно.
Как проверить результат
Стабильно ниже 70–80%, без длительных плато на 100%
Постоянные 90–100% — ядер не хватает
Нагрузка распределена, нет ядер, «прибитых» к 100%
Одно ядро на 100% при свободных остальных — упор в частоту или однопоточный код
Ядра выходят на турбо-частоту, близкую к паспортной
Частота ниже базовой — троттлинг или энергосбережение
Проведение документов и отчёты стали заметно быстрее, чем до замены
Время не изменилось — узкое место было не в CPU
Преобладают ожидания, связанные с CPU, при его умеренной загрузке
Доминируют ожидания диска и блокировок — нужна работа с дисками и запросами
Часто задаваемые вопросы
Хватит ли для 1С сервера с процессором на 4 ядра?
Для файловой работы или базы с 3–5 активными пользователями — да, при условии высокой частоты. Для клиент-серверного варианта с SQL и десятком одновременных сессий 4 ядра — нижняя граница: фоновые задания и обслуживание СУБД начнут конкурировать с пользовательскими операциями. Практичный минимум для SQL-связки — 8 ядер.
Что лучше для 1С: Intel Xeon или AMD EPYC?
Обе платформы подходят, решают конкретные модели, а не бренд. Сравнивайте однопоточную производительность (результаты независимых тестов), частоту, объём кэша и стоимость конфигурации с учётом лицензий SQL Server. Модели с максимальной частотой и умеренным числом ядер предпочтительнее флагманов с десятками ядер.
Ускорит ли 1С переход на процессор с большим числом ядер?
Только если текущая загрузка CPU в пике стабильно превышает 70–80% равномерно по всем ядрам. Если при этом отдельные ядра загружены на 100%, а остальные простаивают — добавление ядер ничего не даст, нужна более высокая частота. Сначала снимите счётчики производительности, потом принимайте решение.
Влияет ли процессор на скорость проведения документов?
Да, напрямую: проведение — преимущественно однопоточная операция, и её длительность почти линейно зависит от производительности одного ядра. Но если база большая и данные не помещаются в память, узким местом могут стать диски — тогда эффект от быстрого CPU будет ограничен.
Можно ли размещать сервер 1С и SQL Server на одной машине?
Можно при небольшой нагрузке (примерно до 15–20 активных пользователей). Выделите достаточно памяти обоим компонентам и ограничьте максимальное потребление RAM сервером СУБД, чтобы он не вытеснял рабочие процессы 1С. При росте нагрузки планируйте разделение ролей на отдельные серверы.
Нужно ли отключать энергосбережение на сервере 1С?
Да, это стандартная практика. Режимы энергосбережения (C-states, динамическое понижение частоты) добавляют задержки при выходе ядер из «сна» и снижают отзывчивость. В BIOS/UEFI и в схеме электропитания ОС выберите профиль максимальной производительности — расход электроэнергии вырастет незначительно, а отклик станет предсказуемым.
Что важно запомнить
Для сервера 1С с SQL решает частота и однопоточная производительность, а не число ядер. Ориентир — 8–16 физических ядер с базовой частотой от 3 ГГц и турбо от 4 ГГц. Перед покупкой замерьте фактическую загрузку и исключите другие узкие места: память, диски, блокировки. Учитывайте стоимость лицензий SQL Server по ядрам и проверяйте результат замерами «до» и «после».