Виртуальные машины и тест Гилева

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

    Введение

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

    Более того, тест в первую очередь разрабатывался для проверки дискретных серверов (поскольку именно их рекомендует использовать производитель платформы), а однопоточный тест изначально разрабатывался для проверки файловой архитектуры хранения баз 1С. И если по настройке дискретных серверов и операционных систем на сайте авторов имеются рекомендации, хотя и неполные и отчасти устаревшие, то по виртуальным и облачным технологиям присутствует только приглашение к заключению договора с авторами теста на проведение работ по оптимизации.

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

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

    Исходные данные

    Тест Гилева – синтетический тест, позволяющий оценить быстродействие платформы «1С:Предприятие». В основном используется для оценки производительности при использовании СУБД для хранения баз данных 1С, но может использоваться и для файлового варианта хранения баз данных 1С. Поставляется в виде файла конфигурации (*.cf) для дальнейшей загрузки в конфигураторе «1С:Предприятие».

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

    Первая часть – однопоточный тест, оценивает производительность выполнения операций в один поток, что является характерной особенностью платформы «1С:Предприятие». По результатам теста строится график в виде столбчатой диаграммы, в котором слева направо представлены текущий результат теста и результаты, соответствующие оценкам «плохо», «удовлетворительно», «хорошо» и «отлично». «Оценочные» результаты имеют фиксированные значения (10, 15, 35 и 60 соответственно). Результат однопоточного теста предоставляется в неких условных единицах.

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

    Дополнительно тест позволяет сохранить результаты в облако авторов теста и получать результаты других пользователей теста для сравнения.

    Среда тестирования

    Для тестирования в «обычном» облаке Cloud4Y мы создали виртуальную машину с гостевой ОС Windows Server 2019. ВМ развернули из стандартного шаблона в варианте с паравиртуальным драйвером дисков. Данный тип контроллера не даёт преимуществ по скорости работы в сравнении с LSI Logic SAS, но активно продвигается вендором и может стать типом контроллера по умолчанию в будущем.

    В качестве СУБД использовали Microsoft SQL Server 2019 редакции Standard. Редакция Express даёт схожие результаты тестирования, однако неприменима на реальных базах из-за ограничений редакции. Следовательно, использовать её в шаблоне виртуальной машины не имеет смысла.

    На виртуальной машине установили сервер «1С:Предприятие» и настроили кластер серверов 1С. Также установили дополнительные средства администрирования серверов 1С. В качестве единственной конфигурации использовался тест Гилева.

    Для тестирования раздельной конфигурации, где сервер 1С и СУБД размещаются на отдельных ВМ, мы клонировали исходную ВМ, после чего в гостевой ОС каждой из получившихся виртуальных машин удалили лишние компоненты и провели дополнительную настройку.

    Оптимизации

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

    2. Оптимизировали гостевую ОС. Все оптимизации делались на основании рекомендаций с сайтов https://its.1c.ru и https://gilev.ru. Также учитывались данные с других тематических ресурсов. При внесении изменений в гостевую ОС мы проверяли актуальность рекомендаций, так как значительная их часть относится к устаревшим версиям операционных систем. В итоге мы а)полностью отключили все функции энергосбережения в гостевой ОС и включили режим максимальной производительности, б) отключили на уровне системы протокол IPv6, в реестре по адресу HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters создали ключ DisabledComponents типа DWORD (32 бита) со значением 0xffffffff, что соответствует отключению всех компонент IP версии 6, кроме интерфейса замыкания на себя. При этом значении также будет использоваться в политиках префиксов протокол IP версии 4 вместо IPv6.

    3. Оптимизировали СУБД. В частности, мы:

    • Установили минимально необходимый набор компонентов СУБД MSSQL

    • Установили лимит потребления памяти сервером СУБД: минимальное значение равное половине объёма оперативной памяти, максимальное – полный размер RAM, за вычетом 1 ГБ на каждые выделенные 16 ГБ оперативной памяти

    • Установили максимальную степень параллелизма равную 1

    • Базу tempdb, пользовательскую базу данных, лог базы данных разнесли на отдельные файловые системы на отдельных виртуальных дисках

    • Выполнили тонкую настройку параметров баз model и tempdb: значения начального размера базы от 1 ГБ до 10 ГБ, начальный размер журнала транзакций от 1 ГБ до 2 ГБ и авторасширение в 512 МБ

    • В СУБД разрешили операции по обслуживанию томов

    • Для раздельной архитектуры для пользователя, от имени которого запускался сервер СУБД, дополнительно установили политику «Блокировка страниц в памяти». Для совместной архитектуры эта политика не должна использоваться, что подтверждается результатами тестов

    • Для совместной архитектуры отключили все протоколы обмена данными, кроме shared memory, для раздельной – все, кроме tcp

    Тестирование

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

    Влияние виртуальных процессоров и сокетов

    Рис.1
    Рис.1
    Рис. 2
    Рис. 2
    Рис. 3
    Рис. 3

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

    Рис. 4
    Рис. 4
    Рис. 5
    Рис. 5

    На рис. 4 и 5 показано слияние увеличения количества виртуальных процессоров. Как можно увидеть, значительного выигрыша в результатах теста Гилева увеличение количества виртуальных процессоров не даёт.

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

    Влияние объёма RAM

    Теперь давайте оценим влияние объёма оперативной памяти на результаты теста

    Рис. 6
    Рис. 6

    Как можно увидеть, увеличение памяти не даёт ощутимого влияния на результаты теста.

    Примечание: но при работе с реальной базой данных и при подключении более одного пользователя объём оперативной памяти будет существенно влиять на производительность, и это нужно учитывать.

    Влияние размера кластера файловой системы тома с базой данных

    Рис. 7
    Рис. 7
    Рис. 8
    Рис. 8
    Рис. 9
    Рис. 9

    На рис. 7-9 представлено влияние размера кластера файловой системы тома с базой данных. Как вы видите, размер кластера файловой системы не даёт ощутимого влияния на результаты теста.

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

    Влияние совместной или раздельной архитектуры

    Рис. 10
    Рис. 10

    На рис.10 представлены результаты теста Гилева для раздельной архитектуры (отдельный сервер СУБД). Обратите внимание, тест никак не учитывает в однопоточном тесте конфигурацию сервера СУБД, учитывается только конфигурация сервера, где развёрнута платформа «1С:Предприятие». В целом, производительность в тесте Гилева у раздельной архитектуры несколько ниже, чем у совместной, поскольку используется протокол tcp вместо более быстрого протокола shared memory.

    Влияние нагруженности кластера и выделения ресурсов

    Рис. 11
    Рис. 11

    На рис. 11 представлены результаты теста Гилева на виртуальной машине, расположенной на изолированном от основного кластера хосте. Результаты существенно выше предыдущих, поскольку все ресурсы хоста гарантированно предоставляются единственной виртуальной машине.

    Рис. 12
    Рис. 12

    На рис. 12 представлены результаты теста в общем кластере с включенными политиками гарантированного предоставления ресурсов. Как вы видите, результат существенно ниже, чем на изолированном хосте.

    Итоги исследований

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

    2. Нагруженность кластера, в котором работает виртуальная машина, может существенно влиять на результат теста Гилева

    3. Совмещённая архитектура даёт более высокие результаты по сравнению с раздельной за счёт использования более быстрого протокола shared memory. Однако, при использовании такой архитектуры нужно внимательно следить за ресурсами, потребляемыми отдельными компонентами системы, чтобы избежать конкуренции

    4. Значительная часть рекомендаций, представленных на сайтах https://its.1c.ru и https://gilev.ru, неактуальна при использовании современных версий операционных систем и СУБД

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


    Что ещё интересного есть в блоге Cloud4Y

    → В тюрьму за приложение

    → 20000 петабайт под водой: есть ли перспективы у подводных центров обработки данных

    → Определённо не Windows 95: какие операционные системы поддерживают работу в космосе?

    → Рассказываем про государственные защищенные сервисы и сети

    → Как настроить SSH-Jump Server

    Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

    Cloud4Y
    #1 Корпоративный облачный провайдер

    Комментарии 12

      0

      Картинки с мелким текстом лучше бы сделать кликабельными.


      В начале есть утверждение:


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

      Очень надеялся увидеть хоть какие-то реальные подтверждения в тексте статьи. А их и нет. И как итог, утверждение начинает выглядеть голословным.

        +2
        Но ведь утверждение не голословное. На старом сервере тест показывает 10.6. На новом 11.8. На ноуте 24. 1С упп на 80 пользователей на старом сервере работает приемлемо, на новом — летает. На ноуте, понятно, не запускали, но даже один пользователь работает существенно медленнее, чем на новом сервере.
          0

          У вас явно нет понимания области применения синтетических и индивидуально написанных тестов под конкретную базу. Ни какой синтетический тест не будет отражать вашу индивидуальную операцию 1 в 1, да это и не требуется. Задача синтетического теста сделать первую быструю экспресс оценку без вкладывания больших сил и денег.
          Тест однопоточный потому что большинство OLTP операций в 1С выполняются однопоточно и тест достаточно показателен для большинства баз небольшого размера.
          Есть другие тесты, например "объемные тесты", которые решают схожие задачи, но они тоже достаточно индивидуальный, и нет цели всем налево и направо их делать.
          Понятно, что вы в 1С можете написать вообще уникальный код и говорить что он не коррелирует с нашим тестом. Но тут же вопрос репрезентативности выводов. Ну и толку что вы оцените свою уникальную операцию, да для вас это будет полезно, а остальным сильно интересно знать скорость операции, которая у них никогда выполняться не будет?
          "на сайте авторов имеются рекомендации, хотя и неполные и отчасти устаревшие" — давайте конкретней, чего нет? многие вещи мы отвечаем в форуме, я сомневаюсь что вы его целиком перечитали.
          "Как можно увидеть, значительного выигрыша в результатах теста Гилева увеличение количества виртуальных процессоров не даёт." — вы явно не понимаете область применения теста
          если вы хотите тестировать количество соединений/сеансов, количество одновременных фоновиков и т.п. то вам надо делать не синтетический тест, так как он все равно не будет учитывать блокировок в вашей реальной базе, а индивидуально написанный тест.
          но даже в этом случае нашим тестом вы видите скорость одного потока, и если там скажем 8 баллов то и многопоточный тест на такой железки хороших результатов не выдаст
          "Как можно увидеть, увеличение памяти не даёт ощутимого влияния на результаты теста." — вот тут очень спорное утверждение — если вы нарезаете в виртуалке гигабайт и он физически выделаяется на той же планке памяти то с какого перепугу будут изменения? их не будет. А вот если вы втыкаете к существующим планкам еще новые — наши замеры показывают ухудшение скорости. И это связано с падением частоты на планках памяти что можно объективно замерить вне нашего теста специализированными инструментами.
          Ну и напоследок по замерам на вашем ноутбуке. Внедряйте апдекс и демонстрируйте реальные цифры. Я уверен что ваши реальные операции ведут себя по разному по отношению к друг другу. Может быть так что одни значительно ускорятся, другие очень мало, а третьи вообще не ускорятся. Вы же делаете очень субъективную оценку с далеко идущими выводами.
          Многие тестируют нашим тестом потому что остальные жмутся что то сделать достойное и бесплатно.
          И да, вы ругаете тест, но альтернативы не предлагаете. Поверьте, я тоже так могу )))

            0
            Непонятно почему вы принимаете меня за автора статьи.
            Я всего лишь рассказал о своей конкретной ситуации, где двухъядерный ноутбучный процессор 8gb DDR3 и sata ssd показывает лучшие результаты в тесте, чем 2 8 ядерных серверных процессора с 64gb DDR4 и SAS ssd.
              0

              считайте это ответом и вам и автору статьи

        +1
        тонкую настройку параметров баз model

        А что можно настроить в model?
        Для совместной архитектуры отключили все протоколы обмена данными, кроме shared memory

        Сервер СУБД и приложений были на одном хосте кластера?

        К сожалению, все картинки нечитаемые — низкое разрешение.
          +1
          Всегда любил 1С-ников вот за это:
          Установили максимальную степень параллелизма равную 1
            0
            «Основная сложность работы с большими базами данных в 1С — это временная блокировка таблиц при обращении к ним множества пользователей. Решить эту проблему можно только с помощью планирования дисковой системы.» — когда 1Сники пишут о причинах тормозов в 1С
            0

            Включите unsafe writeback, отключите spectre mitigations в гипервизоре, включите hyperthreading, и, вуаля, у вас отличный бенчмарчонок. До первого залётного дятла всё будет летать. После тоже, но только в направлении ускорения свободного падения.

              0
              Что нисколько не мешает делать это на dev базах.
                0

                Разумеется, CI прямо просит unsafe writeback. Но вот dev-базы… Вот писал человек конфигурацию, шмяк, ребут, вместо написанного какашка. Обидно?

              0

              Разносить файлы баз по дискам — это правильно. Для чистоты эксперимента надо ещё и диски по разным контроллерам разнести.

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

              Самое читаемое