О пользе точной настройки перед проведением performance tests на Nutanix

Немного интересного о том, насколько важно для получения хорошего результата правильно и грамотно конфигурировать систему (а не просто поставить ее потыкав Enter и «Далее»), руководствуясь нашими Best Practices.

Нак коллега из Германии поделился своим опытом:

«Доброе утро. Хочу с вами поделиться результатами тестирования, которые хорошо иллюстрируют важность использования наших best practices.

Я запускал бенчмарк на MSSQL с использованием HammerDB. Использовался AOS 5 на AHV на 3x NX-3175-G4. CPU на 2.6 Ghz (2x 10 core) и каждая нода имела 692 GB RAM. Диски: 2x 1.5 TB SSD и 2x 2TB HDDs.

Все VM были созданы из шаблона Windows 2012 R2 x64 со всеми сежими патчами, VM имела 1 сокет и 8 виртуальных ядер, а также 64GB vRAM.

Я создал VM с SQL Server установленным по умолчанию (просто приняты все значения установки по умолчанию, просто жал «next» всегда), и база была поставлена на виртуальный диск, размером 1TB в контейнере по умолчанию.

Я также создал одну VM с SQL установленным и настроенным в соответствии с нашими best practices. Контейнер имел включенную inline compression, для базы созданы несколько виртуальных дисков, настроены параметры SQL Server, установлены trace flags, large pages, database memory allocation, и так далее.

Затем я установил HammerDB и выполнил транзакционный тест (TPC-C) с 40 пользователями и 254 warehouses, что, в общем, довольно невысокое число последних.

Так выглядел запуск теста на неоптимизированном сервере SQL. Мы получили примерно 90K transactions per minute, и уперлись в CPU.

А это тест на оптимизированной VM с SQL. Мы получили тут более миллиона транзакций в минуту, и все еще не уперлись в CPU.

В обоих случаях, OS и базовая конфигурация VM были идентичны, различалась только конфигурация контейнера, были добавлены дополнительные диски в VM, и были сделаны настройки базы данных. Подсистема хранения не была слишком нагружена, она выдавала всего около 4800 IOs или 290 MB/s.

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

Итак, просто за счет более правильной настройки VM для работы в Nutanix, получен двенадцатикратный прирост ее производительности.

О пользе точной настройки перед проведением performance tests на Nutanix: 6 комментариев

  1. Peter

    ну т.е. получается что с одной стороны всё просто и настраивается за 5 минут (судя по роликам в сети), а с другой стороны — чтобы получить хорошую производительность — надо довольно сильно «пердоли**ся в консоль».
    Вот она разница в маркетинге и жизни :(

    1. romx Автор записи

      Не, не так. Все просто, и настраивается за пять минут, после прочтения десятка страниц Best Practices, за еще 10 минут — да. Либо за две минуты тыканьем в Enter, и тогда в 12 раз хуже, хотя все равно работает.
      Нет, правда, вы много знаете (все еще не уволенных) сисадминов, которые ставят MS SQL Server для TPC-C-подобной задачи в performance critical, энтером, не читая документации?

  2. Vladimir Rodkin

    Запустите реальный workload, тот же Docsvision 5.x на 100 пользователях.
    Я не критикую этот тест, но у меня есть печальный опыт реальной нагрузки vs маркетинговые слайды именно под мою нагрузку.

    1. romx Автор записи

      Владимир, давайте начнем с того, что Nutanix никому ничего не должен доказывать. Доказывать должны себе вы сами. Что за постановка «_запустите_ какой-то интересный только мне тест, потому что _у меня_ с ним были проблемы»?
      Если вы заинтересованы в Nutanix — берите оборудование в тест, или арендуйте у нас в датацентре (последнее — быстрее), разворачивайте там, и тестируйте, доказывайте сами себе все, что необходимо.

      1. Vladimir Rodkin

        Роман, оборудование запросил на тест. Комментарий писал без негатива. Нагрузка показательна, т.к. нещадно эксплуатирует MSSQL.(вся логика внутри бд)

        1. romx Автор записи

          ОК, кажется, что резко ответил, извините.
          Строго говоря тут, в посте, основной акцент был на том, что, даже без особой настройки на _нашей_ стороне, только за счет корректной установки и настройки на стороне приложения (о чем иногда «забывают») можно достичь в разы лучших результатов. И целью было напомнит, что не от одного Nutanix зависит результат.

          Несколько другой и отдельный момент состоит в том, что, иногда, например, только ускорение database может не приводить к ускорению целиком задачи (теста), просто потому что она написана криворукими идиотами не вполне корректно, с такой ситуацией я встречался не раз. То есть db мы ускорим, но потом все равно приложение стоит и ждет, пока там софт отработает с данными, которые пришли в 20 раз быстрее и лежат. Так что не всюду платформа может помочь ускорить, где-то надо и руки прямить разработчикам. Но это уже не наша задача.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *