В сентябре компания DataCore представила новую линейку продуктов MaxParallel и первый продукт из серии — MaxParallel for SQL Server. MaxParallel делает простую вещь – ускоряет работу базы данных MS SQL, не требуя для этого никаких изменений самой базы (ее оптимизации и тп.) или аппаратной части (увеличения числа процессоров, памяти и тп.).

В чем идея: практически все современные сервер БД являются многоядерными, и приложения с успехом используют эти ядра для параллелизации вычислений. Но процесс ввода-вывода остается последовательным и использует одно процессорное ядро. И если заставить планировщик ввода-вывода использовать больше процессорных ресурсов, БД будет работать быстрее. По крайней мере, сможет работать быстрее. Уникальность MaxParallel состоит не только в том, что она ускоряет БД без серьезного вмешательства, но также в том, что она устраняет «узкое место», которое по-другому не устранить. Ни увеличение числа ядер в сервере, ни ускорение дисков на бэк-энде не изменит тот факт, что сама ОС использует для обработки ввода вывода только одно процессорное ядро. Единственным решением было бы распределение нагрузки между множеством серверов – больше серверов, следовательно, больше инстансов ОС и как следствие более производительная подсистема ввода-вывода. Но это подход дорогой и даже очень.

Еще до официального анонса продукта мы организовали закрытое тестирование продукта у ограниченного круга заказчиков. И у одного из них была следующая задача: с базой данных работают пользователи. Таких пользователей около 40. Нужно увеличить число пользователей, сохранив при этом приемлемое время отклика (или уменьшив его) а также увеличив число транзакций на пользователя (или опять таки, увеличив его). Вот что компания имела в начале:



При увеличении числа пользователей на 10 человек, отклик увеличился почти в 5 раз, а число транзакций снизилось на ~20%. А это неприемлемо. Попробовали включить кэширование. Это дало прирост производительности, но не тот на который рассчитывал заказчик.



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



Внедрение DataCore имело положительный эффект:



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

Инсталляция


Процесс установки MaxParallel довольно простой, но все-таки нужно учесть несколько моментов:

  • Сервер должен состветствовать минимальным системным требованиям: 4 ядра (или виртуальных процессора, если ставим на ВМ) поддерживаются только процессоры x86 (т.е. никаких Itanium, RISC и т.д). 8ГБ или более оперативной памяти. Поддерживаются операционные системы Windows Server 2008, 2008 R2, 2012 и 2016, а базы данных могут быть MS SQL 2008, 2012, 2014, 2016 и 2017. Ускорению могут быть подвержены любые диски (блоки 512 и 4 байта, MBR и GPT, Basic и Dynamic), любые файловые системы и любое количество разделов, но НЕ отчуждаемые носители.
  • Нельзя ставить MaxParallel на общие диски (shared storage)
  • На текущий момент MaxParallel не поддерживает работу с кластером.
  • Для работы требуется .Net Framework 4.6.1. Если он уже не установлен, он будет автоматически инсталлирован при развертывании MaxParallel.

Для установки MaxParallel требуется, чтобы на том же сервере была установлена БД Microsoft SQL, это обязательно и мастер установки это проверяет. Если все хорошо, то мастер продолжает процесс инсталляции. Дальше процесс довольно прямолинейный: «Далее» -> «Далее» -> «Готово». Сам дистрибутив занимает 135 МБ. В процессе инсталляции потребуется одна перезагрузка для вступления в силу новых драйверов.

Интерфейса управления как такового у MaxParallel нет, есть только иконка в трее которая открывает окошко с одной только настройкой – «Вкл/Выкл» и окном для активации лицензии.



Управление решением производится через командную строчку, для чего предусмотрена утилита DcsMpAdmin.exe. С ее помощью можно включать/выключать сервис, выбрать диски для ускорения, ограничить объем памяти для сервиса MaxParallel. Но большинству эта утилита не понадобится.



Кому это поможет?


MaxParallel лучше всего проявляет себя ускоряя базу данных MS SQL 2008, чуть меньше на версиях 2012 и выше т.к. в них интенсивно используется in-memory. Но и тут эффект видно невооруженным глазом. Особенно хорошо ускоряются параллельные нагрузки на БД т.е. те случае когда производится много INSERT/UPDATE, а также создаются огромные отчеты.

Когда MaxParallel не поможет:

  • последовательные нагрузки: один пользователь, один процесс в один момент времени (serial batch job)
  • нет ресурсов которые можно использовать для ускорения: почти 100% загрузка процессора, и почти такая же по памяти.
  • малая интенсивность работы с дисками (все производится либо в памяти (in-memory), либо производится большое число вычислений с малым числом обращений к самой базе т.е. к дискам)

Как попробовать


MaxParallel можно бесплатно попробовать в течении 30 дней, для чего имеется полнофункциональный триальный период. Самый простой способ понять, подходит ли MaxParallel для вашего окружения, это замерить параметры текущей работы MS SQL в терминах транзакций в секунду, времени отклика и времени создания отчетов, а также измерить потребление системных ресурсов, таких как память и процессорное время. После этого поставить MaxParallel, запустить его и провести повторные измерения, и сравнить результаты.

Можно также попробовать версию MaxParallel развернутую в MS Azure, надо только иметь аккаунт на Azure (это бесплатно). Там вам на час дадут виртуальную машину Windows Server 2012R c 8 ядрами на базе Intel Xeon E5-2673v3, 28ГБ памяти, с MS SQL 2014, MaxParallel и HammerDB. Можно самостоятельно проверить разные сценарии, но только на синтетике.

Для примера:

Работа HammerDB до MaxParallel.



Работа HammerDB после запуска MaxParallel.



В довесок предлагается довольно понятный документ, описывающий по шагам процесс тестирования. Но, при наличии знаний и навыков работы с MS SQL можно воплотить любой сценарий.

Лицензирование


MaxParallel продается по подписке сроком на один год и лицензируется также как MS SQL т.е. по ядрам и редакциям – Standard, Enterprise, Web, Express, Developer. Лицензия на MaxParallel должна совпадать с редакцией MS SQL. Стоимость озвучена на сайте:



Также, для пользователей облачных ресурсов Azure можно купить виртуальные машины с MaxParallel на Azure Marketplace:



Заключение


Компания DataCore выпустила на рынок интересный инструмент, который найдет свое место в инфраструктуре. Это не универсальное решение, но сфера его применения ясна и четко определена. В дальнейшем компания планирует выпустить аналогичные решения для других областей: файловый сервер, Exchange (от инженеров я слышал даже слова “Linux”). Я призываю всех попробовать MaxParallel, и если на это нет аллергии, поделиться результатами тестирования. С Наступающим Новым Годом и успехов вам!

Антон Иванов
Региональный представить DataCore.
Anton.Ivanov@datacore.com

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


  1. Listrigon
    29.12.2017 23:38

    А у вас случаем скриншоты Работы HammerDB до и после не перепутаны, как-то судя по тому, что есть, всё стало гораздо хуже.


    1. alex0rus
      31.12.2017 09:52

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


    1. akivan
      31.12.2017 09:52

      Добрый день! Нет, все правильно. MaxParallel подключает к обработке ввода-вывода неиспользуемые ресурсы ядер. Как следствие возрастает нагрузка на CPU (с ~10% до ~45%) и как результат увеличивается число TPM и NOPM.


  1. DSolodukhin
    30.12.2017 02:03

    сама ОС использует для обработки ввода вывода только одно процессорное ядро

    Замените «ОС» на Windows, поскольку в том же Linux, на котором MS SQL с недавних пор тоже поддерживается, есть возможность использования мультипоточного планировщика ввода-вывода.


    1. akivan
      31.12.2017 16:30

      Добрый день! Дело не в том, сколько потоков может обслужить ядро, а сколько процессорных ресурсов заберет себе сам планировщик для обработки очередей ввода-вывода. Чем больше ресурсов у планировщика, тем быстрее будет обработка очередей, и как следствие быстрее ввод-вывод.


  1. AlanDenton
    30.12.2017 09:05

    Сам по себе продукт, конечно, интересный. Но технических подробностей не хватает. Вы приводили пример с множественными INSERT...UPDATE...DELETE. Это можно решить на уровне настроек базы за счёт Delayed durability начиная с 2014 версии. Либо использования ин-мемори. Начиная с 2016 SP1 этот функционал и в экспресс редакции есть, поэтому с ускорением OLTP проблем быть не должно. По правде так и не понял как Ваш продукт использовать и что он с трансляцией IO запросов сиквела делает.


    1. akivan
      31.12.2017 16:32

      Добрый день! Согласен, технических подробностей действительно не хватает. Инженеры компании держат все в секрете (know-how и все такое). Все правильно, MaxParallel действительно проявляет себя в меньшей степени на базах где используется in-memory. Продукт не занимается ускорением конкретно запросов SQL, он ускоряет работу с диском всей ОС на которой он установлен. В целом, нас применять можно там, где база интенсивно работает с диском, и где есть свободные процессорные ресурсы. Даже в базах где используется in-memory может быть толк во время создания отчетов, если база лезет за данными на диск. Но, надо пробовать. И если я правильно понимаю, то побочным эффектом delayed durability является возможность потери данных при отказе сервера. Чтобы этого избежать можно попробовать использовать MaxParallel, т.к. повысится скорость записи на диск.


      1. AlanDenton
        31.12.2017 19:00

        В случае работы с логом отсутствие понимания что делает MaxParallel ничем не лучше Delayed durability. И там и там меняется поведение при работе с лог буфером. Возможно что-то другое, поэтому вслепую я бы не рискнул такое на продакшен ставить. При DW нагрузке если данные уже в памяти как Ваш продукт может ускорить запросы? А если они на диске, то опять же скорее всего используется некий аналог упреждающего чтения.

        В общем, по моему мнению, чуточку мутно. Тем более, что начиная с 2016-го сиквела добавили аппаратные приблуды, которые дешевле под OLTP нагрузку и менять в коде ничего не нужно. А для DW иногда достаточно сделать кластерный ColumnStore секционированный. Хотя буду объективным истины в чем-то одном нет. Ваш продукт возможно хорош, но нет хорошего прува с технической составляющей. Я бы ее с радостью почитал.

        С наступающими праздниками :)


        1. akivan
          01.01.2018 19:33

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

          С наступившим!


  1. osipov_dv
    30.12.2017 11:56
    +2

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


    1. akivan
      31.12.2017 16:33

      Добрый день! Технических деталей увы не много даже внутри компании (см. предыдущий коммент), и так как продукт новый, порадовать ссылками на успешные проекты тоже не можем. Все правильно, MaxParallel не меняет движок SQL, но также не оптимизирует его настройки. MaxParallel работает на уровне ядра ОС, ускоряя ввод-вывод всего сервера. Т.е. в теории, из академического интереса, можно на этом же сервере создать файловую шару, тогда MaxParallel будет ускорять обращения к файлам.