В мире 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. Платформу 1С версии 8.3.27.1606.

  2. Две СУБД для сравнения: Microsoft SQL Server 2022 и PostgreSQL.

  3. Сам тест Гилева последней версии.

Наша цель — прогнать тест в трех разных средах: на SQL Server, на PostgreSQL и на классической файловой базе.

Цифры на бумаге: что показал тест

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

Сценарий 1: База на Microsoft SQL Server

Мы меняли количество виртуальных CPU у машины и смотрели на результат.

  • 4 vCPU: 47.17

  • 12 vCPU: 45.45

  • 24 vCPU: 45.87

Наблюдение: Самый лучший результат тест показал при наименьшем количестве ядер! Как только мы добавили ресурсов, цифра если и выросла, то незначительно. Тест Гилева, по сути, не умеет эффективно использовать несколько потоков.

При использовании 4 потоков и Microsoft SQL результат 47.17
При использовании 4 потоков и Microsoft SQL результат 47.17
При использовании 12 потоков и Microsoft SQL результат 45.45
При использовании 12 потоков и Microsoft SQL результат 45.45
При использовании 24 потоков и Microsoft SQL результат 45.87
При использовании 24 потоков и Microsoft SQL результат 45.87

Сценарий 2: Старая добрая файловая база

Здесь мы получили рекордный показатель: 121.95

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

Тест Гилева на файловой базе выдал показатель в 121.95
Тест Гилева на файловой базе выдал показатель в 121.95

Сценарий 3: База на PostgreSQL

С этой СУБД тест показал самый скромный результат: 38.76

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

Тест Гилева на базе при использовании Postgresql  выдал показатель в 38.76
Тест Гилева на базе при использовании Postgresql  выдал показатель в 38.76

Главный вывод: тест лукавит

Специфика работы на виртуальных машинах

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

  • Нелинейная зависимость: результаты теста не коррелируют напрямую с реальной производительностью системы при работе с реальными нагрузками.

  • Влияние настроек виртуализации: различные настройки гипервизора могут значительно искажать результаты теста.

При тестировании в облачной инфраструктуре выявляются следующие проблемы:

  • Влияние виртуализации. Тест не учитывает особенности работы виртуальных машин и облачных технологий.

  • Конфигурация системы. Результаты сильно зависят от настроек гостевой ОС, СУБД и параметров виртуальной машины.

  • Масштабируемость. Тест не показывает, как система будет вести себя при увеличении нагрузки.

Так как же тестировать по-взрослому? 

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

Вот что мы рекомендуем нашим клиентам и делаем сами:

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

  2. Мониторинг под нагрузкой. Смотрим не на одну «цифру Гилева», а на десятки метрик: загрузку CPU и RAM, скорость отклика дисковой подсистемы (IOPS), latency сети, время выполнения типовых операций.

  3. Оценка в боевых условиях. Самый честный тест — это пилотная эксплуатация на ограниченной группе пользователей с активным сбором метрик.

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

Наша цель — дать клиентам не просто виртуальную машину с высокими частотами, а гарантированно работающее и производительное решение. И для этого мы смотрим на картину в целом, а не на одну красивую цифру. Но даже по результатам теста Гилева мы можем сказать, что 1С в облаке Nubes на серверах с процессорами 4.0 ГГц буквально летает. А дополнительные проверки это подтвердили.

Комментарии (21)


  1. m0xf
    21.11.2025 10:42

    Тест Гилева, по сути, не умеет эффективно использовать несколько потоков.

    Как и сама платформа 1С. Поэтому максимальное быстродействие получается на небольшом количестве ядер с максимальной частотой.


    1. ngcloud Автор
      21.11.2025 10:42

      Платформа 1С лицензии ПРОФ имеет ограничение в 16 потоков на 1 базу, а лицензия КОРП снимает эти ограничения


      1. XLeshiy
        21.11.2025 10:42

        12 физических проф


      1. VenbergV
        21.11.2025 10:42

        1) Есть предположение что вы ошибаетесь в ограничениях лицензии 1С ПРОФ.
        ЕМНИП там ограничение в 12 ядер. Если конечно за год в 1С 8.5 что-то новое не ввели.
        2) TPC - однопоточный тест! (Как и многие операции в 1С). Ждать от него реакции на увеличение ядер, мягко говоря, странно. Вы еще удивитесь, что и при КОРП лицензии, rphost не сможет использовать ядра с другой NUMA-ноды.
        3) Нагрузочное тестирование, с эмуляцией реальной работы, никто не отменял!


    1. XLeshiy
      21.11.2025 10:42

      Нормально 1с использует многопоточность.

      Это тест устарел давно.


      1. riv9231
        21.11.2025 10:42

        Нормально, в том смысле, что один процесс - одно ядро, а если запустить штук 20 1с-ок, то можно 20 ядер нагрузить?


        1. XLeshiy
          21.11.2025 10:42

          1с прекрасно умеет распараллеливать процессы даже на 1 базе, там даже настройка есть, сколько ядер использовать (по умолчанию 8)

          12 физических или 24 виртуальных ядра на 1 сервер (ограничение ПРОФ).

          У меня кластер из 3 серверов (физических).

          Бывает и по 60-70 активных процессов.

          Была бы лицензия КОРП, все бы скушала и не подавилась бы)


          1. VenbergV
            21.11.2025 10:42

            ЕМНИП rphost заперт в одной NUMA-ноде! Так что более одного процессора с одной базой не смогут работать. Если конечно в 1С 8.5. что-то новое не завезли.


            1. XLeshiy
              21.11.2025 10:42

              1 процесс rphost может делать много соединений, по умолчанию до 256 соединений для 8 баз. И это не 8.5, а давно уже. С выхода 8.1


              1. VenbergV
                21.11.2025 10:42

                Вы абсолютно правы. Но я говорил о процессорных ядрах. И о том, что один rphost не выходит далее одной NUMA-ноды. Что при высокопроизводительной настройке сервера равно одному физическому процессору.
                ЕМНИП одна база не работает сразу с несколькими rphost.
                На вскидку нашел https://its.1c.ru/db/metod8dev/content/5903/hdoc
                И по докладам Антона Дорошкевича запомнил рекомендацию, что rphost должно быть в два раза больше, чем NUMA нод.


            1. yukon39
              21.11.2025 10:42

              NUMA-нода это не один процессор! В одной NUMA-ноде могут быть с полсотни процессоров.

              И ограничение на работы в пределах одной NUMA-ноды справедливо для одного серверного процесса. А в кластере этих процессов могут быть десятки.

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


              1. VenbergV
                21.11.2025 10:42

                Возможно я ошибаюсь. Вы предлагаете на типовом двух-четырех процессорном сервере включить Node Interleaving? (С другими способами объединения памяти для всех процессоров не встречался). Но тогда можно на 30%-40% получить падения производительности из-за задержек операций с памятью.


      1. acsent1
        21.11.2025 10:42

        Расчет себестоимости, перерепроведение документов до сих пор однопоточные


  1. XLeshiy
    21.11.2025 10:42

    Тест Гилева уже давным давно показывает фигню.


  1. anonymous
    21.11.2025 10:42


  1. DikSoft
    21.11.2025 10:42

    Ушла эпоха. Пришли "девопсы", которые тупо не понимают, что виртуалка тоже требует оптимальной тонкой настройки, как среды исполнения так и своих параметров. И вместо разбора "почему так", вываливают безапелляционное "тест устарел, верьте нам"

    На Хабре уже были минимум две хорошие статьи, в которых глубоко разбирались настройки виртуализации под конкретные нагрузки. В частности под VMWare и под Hyper-V. Включая тонкие настройки сети, vCPU /памяти, в частности NUMA, и т.п.

    А потом удивляемся, что "всё тормозит". Либо переплачиваем за ресурсы.

    Статье и авторам минусы.


    1. XLeshiy
      21.11.2025 10:42

      Себе минус поставь.

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


      1. riv9231
        21.11.2025 10:42

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

        Насколько я помню, Гилёв делал этот тест именно для измерения конкретных узких мест оборудования. И до сих пор он показывает эти узкие места.


        1. XLeshiy
          21.11.2025 10:42

          За 25 лет в 1с я уж наверное способен определить шустрит у меня или не шустрит)


  1. HADGEHOGs
    21.11.2025 10:42

    Тест Гилева точечно показывает, что от погонщиков "облаков" клиентам сложнее ларька у метро нужно держаться подальше.


    1. XLeshiy
      21.11.2025 10:42

      Обязательно расскажу это одному своему "ларьку" на 20 баз и сотню пользователей, успешно и давно крутящемуся в облаке)