Тест Гилева — сферический конь в вакууме, или как мы выбирали инфраструктуру для 1С

Привет, Хабр! Меня зовут Анжелика Захарова, я руководитель практик 1С и кибербезопасности K2 Cloud. Мы занимаемся инфраструктурными проектами, и значительная часть подразумевает подбор и развертывание серверных платформ под 1С.

В конце 2025 года к нам пришел заказчик из среднего бизнеса, который мигрировал с SAP на 1С, но не знал, что выбрать: облако или выделенный сервер, Intel или AMD, и, главное, сколько это будет стоить в эксплуатации. Мы взяли две платформы — Intel Xeon Gold 6548Y и AMD EPYC 9274F — и прогнали тест Гилева. Intel показал 60 баллов, AMD — 58. Казалось бы все, можно брать Intel и начинать развертывание…

А потом мы запустили закрытие месяца на реальной базе 1С:ERP. И AMD, который по Гилеву не сильно, но проиграл, оказался на треть быстрее.

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

К нам обратился заказчик, который планировал миграцию с SAP на 1С. Задача была двойной: выбрать, где будет жить его 1С (в облаке или на выделенном сервере), и при этом не переплатить за инфраструктуру.

Для тех, кто работал с ПО для управления бизнес-процессами, укажу на важный нюанс. В SAP есть встроенный инструмент сайзинга: по параметрам бизнеса (количество пользователей, объем транзакций, характер операции), который позволяет рассчитать, сколько именно железа нужно еще до старта проекта.

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

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

Физика облака

Почему так происходит? Дело в том, что публичное облако — это общий ресурс, где на одном физическом сервере под гипервизором живут несколько заказчиков. Их виртуальные машины создают разную нагрузку на процессорные мощности, что делает поведение отдельной виртуалки во многом непредсказуемым.

Тесту Гилева в первую очередь нужен четырехъядерный процессор, а все остальное уже вторично. И когда вы запускаете этот тест в публичном облаке, вы не знаете, что происходит рядом с вашей машиной. Ваш «шумный сосед» может в этот момент перестраивать базу на миллион строк, и ваш результат просядет с 30 до 15 баллов, а через полчаса подскочит до 25.

Более того, сам Гилев в документации к тесту рекомендует проводить его на абсолютно пустой машине. Если используется виртуализация, гипервизор должен быть пустым: на нем должна быть запущена только тестовая виртуальная машина, а на этой машине ни одного процесса, кроме единственной базы 1С. Даже наличие второй базы 1С, в общем то, уже нарушение условий. В публичном облаке соблюсти эти условия не получается. В общем, если вы хотите спокойной жизни, вам нужно ехать в загородный дом, а не пытаться отгородиться от шумных соседей.

Это подтверждают и данные. В публикации на InfoStart, где разбирались результаты тестов на инфраструктуре нескольких облачных провайдеров, картина показательная: максимальный результат 60,24 показал физический сервер, а облачная инфраструктура дала 34,25 и ниже. Мы попытались воспроизвести это на своей задаче: меняли типы дисков, пробовали более быстрые процессоры, старались выжать максимум из облачной конфигурации. Результат? Во всех вариантах — ниже 34 баллов. Преодолеть этот порог не удалось.

Чтобы дать заказчику честный ответ, нам нужно было провести собственное тестирование на выделенных узлах, но одного Гилева нам было мало.

Методология тестирования

Тест Гилева представляет собой удобный легко воспроизводимый стандарт, который хорошо подходит для оценки производительности 1С в изолированных условиях. Все мы его знаем и активно используем. Осенью прошлого года мы даже приглашали команду Вячеслава Гилева тестировать инфраструктуру К2 Cloud. Однако этот тест не отражает реального поведения 1С с конкретной базой данных. В таком сценарии вмешивается слишком много факторов, которые бенчмарк просто не учитывает. Поэтому мы сознательно использовали два подхода.

Первый — синтетика: тест Гилева версии 2.1.1.30 для быстрого сравнения: два последовательных прогона на каждом стенде.

Второй — прикладной: закрытие месяца на базе 1С:ERP «Управление холдингом». Реальная (но упрощенная) база одного из наших заказчиков с бизнес-процессами бухгалтерии, логистики и производства. Два последовательных месяца закрытия. На ее примере мы смотрели на время расчета партий и себестоимости от запуска до получения результата.

Потому что профили нагрузки у этих тестов заметно различаются. Если Гилев — это прежде всего нагрузка на CPU, то закрытие месяца — массовые соединения таблиц, интенсивная работа с дисковой подсистемой, множество параллельных процессов, специфические паттерны чтения и записи, которые заставляют попотеть все железо.

Поэтому если взять две виртуальные машины: одну с большим количеством слабых ядер, и вторую с парой мощных, то Тест Гилева покажет лучший результат на второй машине, где выше тактовая частота. А реальные операции 1С с типичной пользовательской нагрузкой могут оказаться быстрее на первой. Дело в том, что 1С создает множество параллельных потоков, и на машине с большим числом ядер конкуренция за ресурсы между пользовательскими процессами будет не такой жесткой.

Стенды и конфигурации

В сети уже есть публикации, где сравнивается производительность серверных процессоров Intel и AMD применительно к 1С, например Intel Xeon Gold 6242R и AMD EPYC 9374F. Мы решили дополнить эту картину более свежей парой: Intel Xeon Gold 6548Y и AMD EPYC 9274F.

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

На обоих стендах использовалась одинаковая связка: ОС Debian 12 с утилитой tuned в профиле latency-performance (ориентирован на снижение задержек), СУБД PostgreSQL 15 (сборка с патчами от фирмы «1С») и платформа 1C Server версии 8.3.27.1606.

Несколько пояснений, важных для понимания результатов:

Почему Debian, а не РЕД ОС? Debian бесплатная, всегда под рукой, минимизирует затраты на тестирование. При этом результаты транслируемы на российские ОС на базе Linux. Это, по сути, одно семейство, пускай у них и есть значительные отличия.

Почему PostgreSQL с патчами? «Ванильный» PostgreSQL и 1С — не лучшие друзья. Код 1С исторически плохо оптимизирован под PostgreSQL: планировщик запросов строит неэффективные планы, а работа с временными таблицами вообще является известным узким местом. Специальные сборки с патчами от фирмы «1С» меняют логику планировщика, улучшают обработку временных таблиц и соединений. За версионностью этих сборок нужно внимательно следить: в каждой новой версии появляются патчи, которые улучшают конкретные операции.

Почему патченная сборка критична для сопоставимости результатов? Без патчей от «1С» и базового тюнинга 1С на Linux просто не полетит: дефолтные параметры Postgres рассчитаны на то, чтобы база просто запустилась на минимальном железе, буквально на одном ядре и гигабайте оперативки. Именно поэтому оба стенда использовали одну и ту же патченную сборку с одним и тем же набором базовых настроек. Это гарантирует, что мы сравниваем железо, а не степень оптимизации СУБД. Если вы будете воспроизводить подобное тестирование, следите за тем, чтобы версия патчей совпадала на всех стендах, иначе результаты будут несопоставимы.

Почему без глубокого тюнинга? Мы провели базовую оптимизацию: подобрали параметры СУБД на основе нашего опыта и рекомендаций из открытых источников, но в глубокий индивидуальный тюнинг под конкретную базу мы не погружались, хотели посмотреть, что получит заказчик с типовой конфигурацией провайдера, если к ней добавить базовый набор настроек PostgreSQL от опытного интегратора, но без отдельного проекта по глубокой оптимизации.

Результаты тестирования

Тестирование проходило по единой схеме. Сначала на каждом стенде — тест Гилева, два последовательных прогона, а затем загрузка тестовой базы 1С:ERP «Управление холдингом» и закрытие месяца за два последовательных периода.

Если смотреть только на Гилева, то оба стенда показывают очень близкую производительность, Intel оказался примерно на 6% быстрее.  AMD имеет более высокую тактовую частоту (4.3 GHz против 4.1 GHz у Intel), так что мы ожидали обратного. Тем не менее, разница небольшая и на сенсацию не тянула, но потом мы запустили закрытие месяца. AMD выполнил расчет партий и себестоимости на треть быстрее Intel. Причем оба месяца показали стабильное ускорение: 24,9 секунды против 32,85 в первом месяце и 29,3 против 42,74 во втором.

Как так вышло

Давайте разберемся, что здесь произошло. Мы ждали, что AMD за счет более высокой тактовой частоты и NVMe-накопителей покажет преимущество и по Гилеву тоже, но на деле получили паритет с небольшим перевесом Intel в синтетике и кратное преимущество AMD в прикладном сценарии.

Закрытие месяца чувствительно к частоте процессора, потому что многие операции выполняются в один поток. Но одновременно 1С создает множество параллельных процессов, и тут начинается конкуренция за ресурсы. Именно поэтому «GHz ≠ победа» и именно поэтому тест Гилева, которому хватает четырех ядер и чистого CPU, не может предсказать поведение системы при реальной регламентной нагрузке. Расхождение объясняется комбинацией факторов, и разделить их вклад мы не можем, но перечислим то, что точно играло роль.

На стенде Intel использовались блочные устройства io2 с заявленными 50 000 IOPS. Звучит внушительно, но есть нюанс, который легко упустить из виду: io2 обеспечивает максимальный IOPS только на больших объемах дискового пространства. У нашего заказчика предполагалась база около 200 ГБ, а на таком объеме те самые 50 000 IOPS сжимаются до значительно меньших значений. Заказчик с небольшой базой автоматически «попадает» на пониженное дисковое быстродействие, таково устройство хранилища. На стенде AMD стояли два NVMe-накопителя Intel в RAID1, которые этого ограничения не имеют.

Однако мы не можем утверждать, что именно диски стали решающим фактором. Наша тестовая база была урезана (два месяца вместо полного года), и на таком объеме подключение NVMe не дало столь существенного прироста, как можно было бы ожидать. Если бы база была в 10 раз больше и для формирования остатков и отчетности нужно было бы считать значительно больший объем данных, скорость чтения диска стала бы более критичной, и разрыв между io2 и NVMe мог бы проявиться заметнее. Но в нашем конкретном тесте дисковый фактор, по всей видимости, не был доминирующим.

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

Еще один фактор — архитектура самих процессоров. Помимо тактовой частоты, на производительность влияет скорость работы с памятью, стратегии кэширования, профиль поведения при многопоточных нагрузках. Более высокочастотный процессор с более медленной памятью может проиграть менее частотному, но с лучшей подсистемой памяти. При этом сам по себе объем оперативки — 128 ГБ у AMD против 96 ГБ у Intel — по оценке наших инженеров, на результат повлиял слабо.

Наконец, не стоит сбрасывать со счетов дефолтные настройки провайдеров. Мы сознательно не лезли в глубокую оптимизацию ядра и PostgreSQL на каждом стенде, но у каждого провайдера свое окружение, и нельзя исключать, что эти настройки по-разному влияли на синтетику и на прикладной сценарий.

А что с экономикой?

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

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

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

Мы наблюдаем полноценный кризис цепочек поставок. Из-за взрывного роста инфраструктур под ИИ и ботов на рынке возник острый дефицит компонентов. Цены бьют рекорды: оперативная память с конца прошлого года подорожала в 2–4 раза, а SSD-накопители теперь стоят в 16 раз дороже жестких дисков. Ситуацию усугубляет и то, что Intel сокращает производство процессоров для обычных серверов в пользу узкоспециализированных линеек. В результате сроки поставок постоянно сдвигаются, разовые закупки идут с огромной накруткой, а уже оплаченные заказы могут просто отменить без объяснения причин. В таких условиях поиск поставщика с адекватным прайсом превращается в квест, а выделенный узел на практике оказывается не таким уж дешевым и доступным.

Плюс ко всему, железо устаревает быстрее, чем кажется. Профит от топового процессора может испариться уже через полгода-год: выходят новые поколения CPU, а база данных тем временем растет и «съедает» заложенный резерв мощности. Облако эту проблему снимает — вы всегда на актуальном оборудовании без капитальных затрат на апгрейд.

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

Что это значит на практике

Так что же делать, если вы стоите перед тем же выбором?

• Не полагайтесь на один бенчмарк.

Гилев хорош для базового сравнения «в вакууме» — процессор А против процессора Б в изолированных условиях, но для принятия бизнес-решения его недостаточно. Если вы тестируете инфраструктуру с целью улучшения показателей уже существующей базы, обязательно делайте дамп текущей базы, разворачивайте его на тестовой площадке и прогоняйте прикладной сценарий, критичный именно для вашего бизнеса. Закрытие периода, массовое проведение документов, расчет себестоимости. Выбирайте то, что болит сильнее всего.

• Облако ≠ плохо, выделенный узел ≠ хорошо, и наоборот.

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

• Закладывайте сайзинг в методологию проекта.

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

• Железо это полдела.

Если 1С тормозит, первое, что нужно делать, не покупать новый сервер, а анализировать запросы к базе данных и архитектуру системы. Можно залить проблему деньгами и получить прирост в тридцать процентов от нового процессора, но через полгода база разрастется, количество документов увеличится, и вы снова окажетесь в той же точке. Что будете делать — покупать еще более мощный сервер? Мощность железа и скорость развития рынка вендоров не бесконечна: и количество ядер ограничено, и частота ограничена, и новый процессор на рынок выходит не каждый день. Программная оптимизация запросов к базе, архитектуры системы, может быть, даже кода конфигурации зачастую дает сопоставимый результат и часто замедляет рост аппетитов 1С.

Вместо заключения

По результатам тестов выделенный узел на AMD оказался оптимальным вариантом для этого проекта. Но это ответ для этого конкретного кейса, с этим профилем нагрузки, на этом этапе проекта. Универсального рецепта, к сожалению нет. 1С до сих пор не имеет стандартизированного инструмента сайзинга и в каждом новом проекте можно  полагаться лишь на собственный опыт. Однако патчи PostgreSQL под 1С тем временем выходят регулярно, а связка Linux + PostgreSQL перестает быть «вынужденной мерой импортозамещения» и становится рабочей альтернативой: по производительности она все ближе к привычному стеку на Windows. Так что не нужно бояться Linux и PostgreSQL — нужно учиться с ними работать.

А какой тест, помимо Гилева, используете вы? Есть ли у вас свой «прикладной сценарий», который показывает реальную картину? Делитесь в комментариях — будет интересно сравнить подходы.