В мире 1С нет более известной фамилии, чем Гилев. Его тест — это своего рода «народный» стандарт, первое, что запускают администраторы для проверки производительности. Это простой и быстрый способ получить заветную цифру, которая говорит о скорости системы.
Мы и сами решили использовать этот тест, запуская новый высокопроизводительный сервис 1С. Нам нужно было понять, как себя проявят наши новые серверы с процессорами 4.0 ГГц.
Но вот в чём загвоздка: тест Гилева — это важный, но далеко не единственный и не всегда адекватный инструмент. Он как спидометр в машине: показывает скорость, но не говорит ничего о том, как авто поведет себя на повороте, при обгоне или с полным багажником.
Мы на практике убедились, что его результаты в отрыве от настоящих задач могут несколько отличаться от реальности, особенно в современной облачной среде. Давайте разберемся, почему красивая цифра из теста — это еще не гарантия того, что 1С будет работать быстрее.
Почему тесту не всегда стоит верить?
Тест Гилева — это как школьная контрольная по физике, которая проверяет знание одной конкретной формулы, но не скажет, сможете ли вы построить мост.
Если по-простому, это синтетический тест, который измеряет скорость выполнения одной операции — записи в регистр на почти пустой базе. Главные его недостатки:
Живет в идеальном мире: тест работает без ваших реальных данных, конфигураций и типичной нагрузки.
Устарел морально: он создавался для эпохи файловых баз и однопоточных серверов, а сегодня мы работаем с кластерами, мощными СУБД и виртуализацией.
Выдает просто цифру: его результат часто воспринимают как истину в последней инстанции, хотя на деле это лишь один из сотни возможных показателей.
Короче, он дает неполную и часто искаженную картину. Но раз уж он так популярен, мы решили пройти его до конца и посмотреть, что получится.
Полигон: как мы тестировали
Все тестирование проходило на сервере для 1С:
Процессоры: 2x EPYC 9274F с частотой 4.0 ГГц
Оперативная память: 16 модулей по 64GB DDR5 4800 ECC
Накопители: 8x Samsung PM1743 по 3.8TB
Сетевые адаптеры: 2x Mellanox Connect X5
Платформа: ASUS RS7202-E12-RS24U
Системный накопитель: высокоскоростной M2 SSD
После подготовки оборудования началось самое интересное:
Выбор гипервизора: мы использовали VMware Workstation
Установка и настройка гипервизора: после выбора гипервизора необходимо установить его на хост-машину. Затем нужно настроить параметры гипервизора, такие как количество выделяемых ресурсов (процессор, оперативная память, дисковое пространство) для каждой виртуальной машины. В нашем случае было 48 CPU, 256 RAM и 2048 SSD.
Создание новой виртуальной машины: в интерфейсе гипервизора создаётся новая ВМ. Для этого нужно указать параметры, такие как имя, операционная система, количество выделяемых ресурсов и другие настройки.
Установка операционной системы: после создания ВМ необходимо установить на неё операционную систему. Это можно сделать с помощью образа ОС, который можно загрузить с официального сайта производителя. В нашем случае Windows server 2022
Настройка параметров виртуальной машины: после установки ОС можно настроить параметры ВМ, такие как сетевые настройки, параметры хранения данных и другие.
Запуск виртуальной машины: после настройки можно запустить ВМ и начать работу с ней.
На развернутой виртуальной машине мы установили:
Платформу 1С версии 8.3.27.1606.
Две СУБД для сравнения: Microsoft SQL Server 2022 и PostgreSQL.
Сам тест Гилева последней версии.
Наша цель — прогнать тест в трех разных средах: на SQL Server, на PostgreSQL и на классической файловой базе.
Цифры на бумаге: что показал тест
Вот результаты, которые у нас получились. Спойлер: они говорят больше о самом тесте, чем о реальной производительности.
Сценарий 1: База на Microsoft SQL Server
Мы меняли количество виртуальных CPU у машины и смотрели на результат.
4 vCPU: 47.17
12 vCPU: 45.45
24 vCPU: 45.87
Наблюдение: Самый лучший результат тест показал при наименьшем количестве ядер! Как только мы добавили ресурсов, цифра если и выросла, то незначительно. Тест Гилева, по сути, не умеет эффективно использовать несколько потоков.



Сценарий 2: Старая добрая файловая база
Здесь мы получили рекордный показатель: 121.95
Почему так много? Потому что тест Гилева был «заточен» именно под файловые базы. Он отлично работает в вакууме, но стоит перенести эту базу на многопользовательскую реальную нагрузку, и ее производительность рухнет.

Сценарий 3: База на PostgreSQL
С этой СУБД тест показал самый скромный результат: 38.76
Это не значит, что PostgreSQL — плохой выбор для 1С. Это значит, что алгоритмы теста не оптимизированы под работу с этой СУБД в условиях синтетической проверки.

Главный вывод: тест лукавит
Специфика работы на виртуальных машинах
Заниженные результаты: на виртуальных машинах показатели теста обычно существенно ниже, чем на физическом оборудовании.
Нелинейная зависимость: результаты теста не коррелируют напрямую с реальной производительностью системы при работе с реальными нагрузками.
Влияние настроек виртуализации: различные настройки гипервизора могут значительно искажать результаты теста.
При тестировании в облачной инфраструктуре выявляются следующие проблемы:
Влияние виртуализации. Тест не учитывает особенности работы виртуальных машин и облачных технологий.
Конфигурация системы. Результаты сильно зависят от настроек гостевой ОС, СУБД и параметров виртуальной машины.
Масштабируемость. Тест не показывает, как система будет вести себя при увеличении нагрузки.
Так как же тестировать по-взрослому?
Мы не предлагаем полностью отказаться от теста Гилева. Он может быть точкой входа для первичной, очень грубой оценки. Но для принятия бизнес-решений нужен комплексный подход.
Вот что мы рекомендуем нашим клиентам и делаем сами:
Нагрузочное тестирование на реальных данных. Берем рабочую базу (или ее копию) и нагружаем ее работой реальных пользователей: формирование сложных проводок, отчетов и максимальной фоновой активностью.
Мониторинг под нагрузкой. Смотрим не на одну «цифру Гилева», а на десятки метрик: загрузку CPU и RAM, скорость отклика дисковой подсистемы (IOPS), latency сети, время выполнения типовых операций.
Оценка в боевых условиях. Самый честный тест — это пилотная эксплуатация на ограниченной группе пользователей с активным сбором метрик.
Запуская новый высокопроизводительный сервис 1С, мы могли бы просто опубликовать впечатляющую цифру теста Гилева на файловой базе и почить в лучах славы. Но мы поступили иначе: провели честный разбор и доказали, что слепая вера в синтетические тесты — это путь в никуда.
Наша цель — дать клиентам не просто виртуальную машину с высокими частотами, а гарантированно работающее и производительное решение. И для этого мы смотрим на картину в целом, а не на одну красивую цифру. Но даже по результатам теста Гилева мы можем сказать, что 1С в облаке Nubes на серверах с процессорами 4.0 ГГц буквально летает. А дополнительные проверки это подтвердили.
Комментарии (21)

DikSoft
21.11.2025 10:42Ушла эпоха. Пришли "девопсы", которые тупо не понимают, что виртуалка тоже требует оптимальной тонкой настройки, как среды исполнения так и своих параметров. И вместо разбора "почему так", вываливают безапелляционное "тест устарел, верьте нам"
На Хабре уже были минимум две хорошие статьи, в которых глубоко разбирались настройки виртуализации под конкретные нагрузки. В частности под VMWare и под Hyper-V. Включая тонкие настройки сети, vCPU /памяти, в частности NUMA, и т.п.
А потом удивляемся, что "всё тормозит". Либо переплачиваем за ресурсы.
Статье и авторам минусы.

XLeshiy
21.11.2025 10:42Себе минус поставь.
А потом расскажи мне, почему у меня в кластере на физике 200 баз шустрят с производительностью под 300, а замечательный не устаревший ни разу тест показывает "удовлетворительно"?

riv9231
21.11.2025 10:42По тому, что ваше "шустрят" по факту является удовлетворительным результатам. Проверить просто: берете скрипт, для простоты обновление или какую-нибудь эталонную последовательность действий и запускаете у себя, где 300 баз "шустрят", а потом запускаете то же самое на amd ryzen 9950x3d, 2 планки памяти 6000+ MT/S, optane 4800X с аппаратным форматом 4К и без виртуализации в 1 поток. Ну и какова разница в замерах? Скрипт отрабатывает в разы быстрее - вот это верх шкалы.
Насколько я помню, Гилёв делал этот тест именно для измерения конкретных узких мест оборудования. И до сих пор он показывает эти узкие места.

XLeshiy
21.11.2025 10:42За 25 лет в 1с я уж наверное способен определить шустрит у меня или не шустрит)
m0xf
Как и сама платформа 1С. Поэтому максимальное быстродействие получается на небольшом количестве ядер с максимальной частотой.
ngcloud Автор
Платформа 1С лицензии ПРОФ имеет ограничение в 16 потоков на 1 базу, а лицензия КОРП снимает эти ограничения
XLeshiy
12 физических проф
VenbergV
1) Есть предположение что вы ошибаетесь в ограничениях лицензии 1С ПРОФ.
ЕМНИП там ограничение в 12 ядер. Если конечно за год в 1С 8.5 что-то новое не ввели.
2) TPC - однопоточный тест! (Как и многие операции в 1С). Ждать от него реакции на увеличение ядер, мягко говоря, странно. Вы еще удивитесь, что и при КОРП лицензии, rphost не сможет использовать ядра с другой NUMA-ноды.
3) Нагрузочное тестирование, с эмуляцией реальной работы, никто не отменял!
XLeshiy
Нормально 1с использует многопоточность.
Это тест устарел давно.
riv9231
Нормально, в том смысле, что один процесс - одно ядро, а если запустить штук 20 1с-ок, то можно 20 ядер нагрузить?
XLeshiy
1с прекрасно умеет распараллеливать процессы даже на 1 базе, там даже настройка есть, сколько ядер использовать (по умолчанию 8)
12 физических или 24 виртуальных ядра на 1 сервер (ограничение ПРОФ).
У меня кластер из 3 серверов (физических).
Бывает и по 60-70 активных процессов.
Была бы лицензия КОРП, все бы скушала и не подавилась бы)
VenbergV
ЕМНИП rphost заперт в одной NUMA-ноде! Так что более одного процессора с одной базой не смогут работать. Если конечно в 1С 8.5. что-то новое не завезли.
XLeshiy
1 процесс rphost может делать много соединений, по умолчанию до 256 соединений для 8 баз. И это не 8.5, а давно уже. С выхода 8.1
VenbergV
Вы абсолютно правы. Но я говорил о процессорных ядрах. И о том, что один rphost не выходит далее одной NUMA-ноды. Что при высокопроизводительной настройке сервера равно одному физическому процессору.
ЕМНИП одна база не работает сразу с несколькими rphost.
На вскидку нашел https://its.1c.ru/db/metod8dev/content/5903/hdoc
И по докладам Антона Дорошкевича запомнил рекомендацию, что rphost должно быть в два раза больше, чем NUMA нод.
yukon39
NUMA-нода это не один процессор! В одной NUMA-ноде могут быть с полсотни процессоров.
И ограничение на работы в пределах одной NUMA-ноды справедливо для одного серверного процесса. А в кластере этих процессов могут быть десятки.
Так что не совсем понятно, откуда тезис, что используется не более одного процессора на одну информационную базу.
VenbergV
Возможно я ошибаюсь. Вы предлагаете на типовом двух-четырех процессорном сервере включить Node Interleaving? (С другими способами объединения памяти для всех процессоров не встречался). Но тогда можно на 30%-40% получить падения производительности из-за задержек операций с памятью.
acsent1
Расчет себестоимости, перерепроведение документов до сих пор однопоточные