Comments 12
А у вас случаем скриншоты Работы HammerDB до и после не перепутаны, как-то судя по тому, что есть, всё стало гораздо хуже.
Мысль была в том что вход/выход данных идет через «одно ядро», и иногда это узкое место, потоки данных стоят в очереди, поэтому и получается нагрузка на диск максимальная, а процессоры простаивают, работы мало. Во втором случае данные входят/выходят параллельно, тем самым больше загружается процессоры…
Добрый день! Нет, все правильно. MaxParallel подключает к обработке ввода-вывода неиспользуемые ресурсы ядер. Как следствие возрастает нагрузка на CPU (с ~10% до ~45%) и как результат увеличивается число TPM и NOPM.
сама ОС использует для обработки ввода вывода только одно процессорное ядро
Замените «ОС» на Windows, поскольку в том же Linux, на котором MS SQL с недавних пор тоже поддерживается, есть возможность использования мультипоточного планировщика ввода-вывода.
Сам по себе продукт, конечно, интересный. Но технических подробностей не хватает. Вы приводили пример с множественными INSERT...UPDATE...DELETE. Это можно решить на уровне настроек базы за счёт Delayed durability начиная с 2014 версии. Либо использования ин-мемори. Начиная с 2016 SP1 этот функционал и в экспресс редакции есть, поэтому с ускорением OLTP проблем быть не должно. По правде так и не понял как Ваш продукт использовать и что он с трансляцией IO запросов сиквела делает.
Добрый день! Согласен, технических подробностей действительно не хватает. Инженеры компании держат все в секрете (know-how и все такое). Все правильно, MaxParallel действительно проявляет себя в меньшей степени на базах где используется in-memory. Продукт не занимается ускорением конкретно запросов SQL, он ускоряет работу с диском всей ОС на которой он установлен. В целом, нас применять можно там, где база интенсивно работает с диском, и где есть свободные процессорные ресурсы. Даже в базах где используется in-memory может быть толк во время создания отчетов, если база лезет за данными на диск. Но, надо пробовать. И если я правильно понимаю, то побочным эффектом delayed durability является возможность потери данных при отказе сервера. Чтобы этого избежать можно попробовать использовать MaxParallel, т.к. повысится скорость записи на диск.
В случае работы с логом отсутствие понимания что делает MaxParallel ничем не лучше Delayed durability. И там и там меняется поведение при работе с лог буфером. Возможно что-то другое, поэтому вслепую я бы не рискнул такое на продакшен ставить. При DW нагрузке если данные уже в памяти как Ваш продукт может ускорить запросы? А если они на диске, то опять же скорее всего используется некий аналог упреждающего чтения.
В общем, по моему мнению, чуточку мутно. Тем более, что начиная с 2016-го сиквела добавили аппаратные приблуды, которые дешевле под OLTP нагрузку и менять в коде ничего не нужно. А для DW иногда достаточно сделать кластерный ColumnStore секционированный. Хотя буду объективным истины в чем-то одном нет. Ваш продукт возможно хорош, но нет хорошего прува с технической составляющей. Я бы ее с радостью почитал.
С наступающими праздниками :)
В общем, по моему мнению, чуточку мутно. Тем более, что начиная с 2016-го сиквела добавили аппаратные приблуды, которые дешевле под OLTP нагрузку и менять в коде ничего не нужно. А для DW иногда достаточно сделать кластерный ColumnStore секционированный. Хотя буду объективным истины в чем-то одном нет. Ваш продукт возможно хорош, но нет хорошего прува с технической составляющей. Я бы ее с радостью почитал.
С наступающими праздниками :)
>> По правде так и не понял как Ваш продукт использовать и что он с трансляцией IO запросов сиквела делает.
Как использовать вроде бы ясно, есть trial. А вот как он работает действительно интересно. И ещё больше интересно почему до этого до сих пор MS не додумалась.
Как использовать вроде бы ясно, есть trial. А вот как он работает действительно интересно. И ещё больше интересно почему до этого до сих пор MS не додумалась.
на хабр без технических деталей лучше не отправлять такие статьи, сейчас это выглядит как реклама без подтверждения эффективности. Движок SQL ваша вундервафля не меняет, следовательно просто оптимизирует настройки в лучшем случае…
Добрый день! Технических деталей увы не много даже внутри компании (см. предыдущий коммент), и так как продукт новый, порадовать ссылками на успешные проекты тоже не можем. Все правильно, MaxParallel не меняет движок SQL, но также не оптимизирует его настройки. MaxParallel работает на уровне ядра ОС, ускоряя ввод-вывод всего сервера. Т.е. в теории, из академического интереса, можно на этом же сервере создать файловую шару, тогда MaxParallel будет ускорять обращения к файлам.
Sign up to leave a comment.
Третья космическая скорость для MS SQL Server