Эксперты в подборе IT-оборудования
Вопрос звучит просто, а ответ на него регулярно обходится компаниям в лишние сотни тысяч рублей. Логика кажется железной: 1С тормозит, пользователей много, значит берём процессор помощнее - побольше ядер. Сервер приезжает, 1С работает ровно так же, а счёт за лицензии вырастает вдвое.
Разберёмся, от чего производительность 1С зависит на самом деле, как читать чужие тесты и почему ядра - это ещё и деньги.
Если коротко. Для 1С решает не количество ядер, а скорость одного ядра. Ориентируйтесь на высокую частоту и свежую архитектуру, а число ядер берите по количеству одновременных сеансов и фоновых заданий - с запасом, но без фанатизма. Каждое лишнее физическое ядро вы оплатите ещё раз в лицензии MS SQL и Windows Server.
Код на встроенном языке 1С исполняется последовательно. Когда пользователь проводит документ, пересчитывает итоги или формирует отчёт, эта работа не размазывается по всем ядрам сервера - она идёт в один поток. Сколько бы ядер ни стояло в сервере, конкретная операция конкретного пользователя выполняется на одном из них и упирается в его скорость.
Отсюда практическое следствие, которое ломает интуицию закупщика: процессор с 8 ядрами, работающий на 3,8 ГГц, проведёт документ быстрее, чем 64-ядерный на 2,2 ГГц. Не немного быстрее - заметно, потому что разница в частоте здесь работает почти линейно.
Ядра при этом нужны, просто отвечают они за другое. Частота определяет, как быстро выполняется одна операция. Количество ядер - сколько операций идёт одновременно, не мешая друг другу. Это две разные шкалы, и путать их дорого.
Частая ошибка. «Пользователей стало больше, значит нужно больше ядер». Больше пользователей - да, больше ядер. Но если жалуются на то, что «документ проводится минуту», ядра не помогут вообще: минуту занимает одна операция в одном потоке. Лечится частотой, индексами и настройками СУБД, а не наращиванием ядер.
Перегнуть палку в другую сторону тоже можно. Восьмиядерник на высокой частоте отлично держит небольшую базу и десяток пользователей, но разваливается там, где параллельной работы много.
Ядра начинают решать, когда на сервере:
Рабочий ориентир такой: сначала выбираем процессор по частоте, а потом внутри подходящих по частоте моделей берём тот, у которого ядер хватает под сценарий. Не наоборот.
В русскоязычном 1С-сообществе де-факто стандартом стал нагрузочный тест Гилева (TPC-1C). Результат он выдаёт в условных единицах, которые все называют «попугаями», и по ним принято сравнивать железо.
Устроен тест так: он нагружает один логический процессор и считает, сколько работы система успевает сделать за единицу времени в один поток. Именно поэтому он так хорошо предсказывает ощущения пользователя от 1С - и именно поэтому его результат почти не растёт от добавления ядер.
Это надо понимать буквально. Если вы прогоните тест на 64-ядерном сервере и получите цифру ниже, чем у коллеги на 8-ядерном, ошибки нет: у коллеги ядро быстрее.
Цифры из чужих замеров гуляют в разы, и виноват в этом обычно не процессор. Прежде чем сравнивать два результата, проверьте, совпадают ли условия.
Поэтому чужой результат годится как ориентир по порядку величины, но паспортной характеристикой процессора его считать нельзя. Полезнее сравнивать не абсолютные цифры из разных источников, а замеры, сделанные в одинаковых условиях. Шкала оценок и сам тест лежат на сайте автора, gilev.ru.
APDEX часто упоминают рядом с выбором железа, и это сбивает с толку. APDEX - не методика тестирования процессоров. Это индекс удовлетворённости от 0 до 1, который считается по порогу времени отклика T: операции быстрее T считаются комфортными, от T до 4T - терпимыми, медленнее 4T - неприемлемыми.
В 1С механизм APDEX встроен в платформу и работает по ключевым операциям вашей конкретной базы: вы сами задаёте, что считать быстрым проведением документа, а система копит статистику. Инструмент отличный, но для другой задачи - он показывает, где именно у вас болит, а не какой процессор купить.
Самый частый вопрос темы - и самый бесполезный в такой формулировке. «Intel лучше для 1С» и «AMD лучше для 1С» одинаково неверны: у обоих производителей есть и высокочастотные модели под базы данных, и многоядерные низкочастотные под виртуализацию. Сравнивать нужно не бренды, а конкретные характеристики.
| На что смотреть | Почему это важно для 1С | Чему отдать предпочтение |
|---|---|---|
| Базовая и турбо-частота | Прямо определяет скорость одной операции | Выше - лучше, это главный критерий |
| Производительность на ядро (IPC) | Свежая архитектура делает больше работы за такт на той же частоте | Поколение новее при прочих равных |
| Кэш на ядро | 1С и СУБД чувствительны к промахам кэша | Смотреть кэш на одно ядро, суммарный по процессору мало о чём говорит |
| Количество ядер | Определяет, сколько сеансов и заданий идут одновременно | По сценарию, не «побольше» |
| Каналы памяти | Узкое место при работе СУБД | Заполнять все каналы равномерно |
| Число сокетов | Два процессора дают NUMA, и 1С с СУБД от неё скорее теряют | Один сокет посильнее лучше двух послабее |
Последняя строка стоит отдельного пояснения. Двухпроцессорная конфигурация выглядит солиднее, но память в ней делится между сокетами, и обращение к «чужой» памяти медленнее. Для 1С один мощный процессор обычно предпочтительнее двух средних - и по скорости, и по лицензиям.
И ещё одно наблюдение из практики закупок. Линейка Xeon Scalable живёт уже несколько поколений, от Gen1/2 до Performance Gen6, и в пределах каждого есть и высокочастотные модели, и многоядерные. Так что выбор внутри поколения для 1С обычно важнее выбора между поколениями - свежий многоядерник на низкой частоте проиграет более старому высокочастотному.
Вот тот пункт, из-за которого «взять с запасом побольше ядер» превращается в дорогое решение.
MS SQL Server лицензируется по физическим ядрам сервера, лицензии продаются пакетами по два ядра, минимум - четыре ядра на каждый физический процессор. Считаются при этом все ядра процессора, включая те, до которых SQL никогда не дотянется. Windows Server тоже лицензируется по ядрам: минимум восемь на процессор и минимум шестнадцать на сервер - подробно разобрано в статье про редакции, ядра и CAL Windows Server.
Арифметика получается неприятная. Переход с 16-ядерного процессора на 64-ядерный - это учетверение лицензионной части по SQL. При том, что скорость проведения документа, как мы разобрали выше, от этого не изменится вообще.
Когда множитель не работает. На PostgreSQL лицензий по ядрам нет, и ограничение снимается - это одна из причин, по которой миграция с MS SQL стала массовой. Но Windows Server, если 1С живёт на нём, по ядрам считается всё равно. И сама лицензия сервера 1С:Предприятие к числу ядер не привязана - она на сервер.
Практический вывод простой: число ядер нужно обосновывать сценарием, а не брать «на вырост». Запас по частоте бесплатен, запас по ядрам - нет.
Точных рецептов здесь не бывает: два внедрения с одинаковым числом пользователей различаются в разы по нагрузке, потому что одни проводят десяток документов в день, а другие закрывают месяц по сотне тысяч строк. Поэтому ниже - не таблица моделей, а профиль, от которого стоит отталкиваться.
| Сценарий | Что важнее всего | На что обратить внимание |
|---|---|---|
| До 10 пользователей, файловая или лёгкая клиент-серверная база | Частота. Ядер хватит немногих | Часто достаточно однопроцессорной машины; не переплачивайте за многоядерность |
| 20-30 пользователей, клиент-серверная с СУБД рядом | Частота плюс достаточный запас ядер под СУБД и фоновые задания | Память и диски здесь уже тормозят чаще процессора |
| 50-100 пользователей, активные обмены и регламентные задания | Баланс: высокая частота при ощутимом числе ядер | Имеет смысл разносить сервер 1С и СУБД по разным машинам |
| Больше 100, несколько баз, закрытие месяца | То же плюс продуманная архитектура | Разделение ролей и кластер важнее выбора процессора |
Заметьте закономерность: чем крупнее внедрение, тем меньше решает сам процессор и тем больше - как построена система. На сотне пользователей выигрыш от правильно разнесённых ролей больше, чем от смены процессора на топовый.
Прежде чем закупать железо, стоит убедиться, что упирается система действительно в него. Проверка занимает вечер и часто экономит бюджет.
Начните с загрузки ядер в момент жалобы. Картина, при которой одно ядро загружено под сотню процентов, а остальные простаивают, - это упор в однопоточную производительность. Вот здесь смена процессора на более частотный и поможет. Если же загружены все ядра ровно и высоко, дело в количестве параллельной работы, и лечится это ядрами или разнесением ролей.
Дальше посмотрите на диски и память. Когда процессор скучает, а очередь к дискам растёт, виноваты диски. Когда память кончилась и пошёл свап, никакой процессор не спасёт.
Прогоните тест Гилева до покупки - цифра на текущей машине даёт точку отсчёта, без неё вы не узнаете, стало ли лучше после замены. Заодно сравните результат на сервере и на обычном рабочем компьютере рядом. Если настольная машина обгоняет сервер, проблема почти наверняка не в железе, а в настройках или виртуализации.
И включите замер ключевых операций через APDEX: он покажет, какие именно действия тормозят. Часто выясняется, что «вся 1С медленная» - это два конкретных отчёта, и правится это запросом, а не закупкой.
Бывает и обратный результат: процессор оказывается ни при чём, а виноваты отсутствующие индексы или регламентные задания, запущенные в рабочее время. Такой вывод тоже полезен - он стоит ноль рублей.
Ограничиваться выбором процессора не стоит: в реальных жалобах на «тормозящую 1С» он виноват далеко не всегда. Чаще упирается в память, диски под базу и настройки СУБД - а ещё в отсутствующие индексы и неоптимальные запросы, которые никаким железом не лечатся.
Что смотреть дальше: требования к серверу 1С, если нужен базовый набор; как собирается конфигурация целиком - память, диски, контроллер; и кластер серверов 1С, когда одной машины уже мало и пора разносить роли.
Подойдёт ли для сервера 1С десктопный процессор?
Для небольшой базы и нескольких пользователей - вполне, у десктопных моделей как раз высокие частоты. Ограничения в другом: официальной поддержки ECC-памяти обычно нет, каналов памяти и линий PCIe меньше, и такую машину сложнее обслуживать. Для рабочей базы, от которой зависит бизнес, серверная платформа надёжнее.
Сколько ядер нужно на одного пользователя 1С?
Универсального коэффициента нет, и формулы вида «одно ядро на пять пользователей» вводят в заблуждение: нагрузка зависит от конфигурации и характера работы, а число людей тут вторично. Считать нужно от реальной активности, а лучше - от замеров на текущей системе.
Что даст больше прироста: новый процессор или SSD под базу?
Если база до сих пор на HDD - диски, без вариантов и с большим отрывом. Процессор имеет смысл менять после того, как закрыты вопросы с дисками, памятью и настройками СУБД.
Помогает ли Hyper-Threading (SMT) для 1С?
Немного и не всегда. Логические потоки не удваивают производительность, а на однопоточных операциях не дают ничего. При лицензировании по физическим ядрам они, впрочем, и не считаются - так что вреда тоже нет.
Стоит ли брать два процессора вместо одного?
Обычно нет. Память делится между сокетами, обращение к «чужой» памяти медленнее, а лицензии считаются по обоим процессорам. Один процессор посильнее для 1С чаще выгоднее.
Не уверены, какой процессор возьмёт вашу нагрузку?
Назовите конфигурацию, число пользователей и характер работы - подберём машину под задачу, а не по прайсу. Соберём и протестируем под вашу нагрузку перед отгрузкой, с гарантией и поддержкой после продажи. 11+ лет на рынке серверов.
