Max degree of parallelism что такое. Max degree of parallelism – выбор оптимального значения. Настройка параметра максимальной степени параллелизма

В данном посте речь пойдет только о MS SQL Server. Если вы собрались "попытать счастья" в использовании 1С с Oracle, DB2, Postrgre вам данная информация будет бесполезна. Но нужно понимать, что в 1С есть прежде всего специалисты по MS SQL серверу. Усилиями со стороны компании IBM появляются ещё и специалисты по DB2. Можно долго рассуждать хорошие или плохие это СУБД, важно одно, наиболее "гладко" 1С работает с MS SQL сервером. Судя по последним сообщениям с "фронта" более-менее приличной стала работа с DB2. Хотя я лично имел опыт настройки 1С для работы с DB2 ещё в версии 8.1 - там всё было как-то не очень. В любом случае выбор другой СУБД должен быть четко аргументирован - либо возможностоями, которых нет в MS SQL (кластер с балансировкой нагрузки, Grid, и т.п.), либо финансами (Oracle уже куплен), либо платформой (всё на linux).

Итак по порядку, что нужно сделать с MS SQL Server:

1) Настроить минимальный и максимальный объем памяти. Минимальный - половина памяти системы. Максимальный - память системы без 2ГБ. Делается это через Management Studio - в свойствах сервера:

2) Если приоритет не установлен на закладке "Процессоры" - нужно установить

3) Максимальную степень параллелизма ставим в 1.

4) Включаем SQL Server Agent, настраиваем Database Mail - ничего там трудного нет, подробно описывать не буду.

5) Настраиваем планы обслуживания:
Общие:
а) Обновление статистики - каждые 2 часа
б) DBCC FREEPROCCACHE - каждые 2 часа
Для каждой базы:
а) Полное резервное копирование
б) Разностное резервное копирование
в) Дефрагментация индексов - каждый день
г) Перестройка индексов - ночью в выходные
д) Проверка целостности базы - раз в месяц ночью в выходные

6) Рекомендую для каждой базы (в свойствах) модель восстановления установить как Simple. В случае если у вас не 24/7 система и менее 1000 пользователей на базу, нет отказоустойчивого кластера и вы не подписывали SLA в котором обязуетесь в случае выхода любого оборудования из строя восстановить данные с точностью до секунды (а не со времени последней резервной копии) эта рекомендация будет разумной. Иначе вы очень скоро будете долго и судорожно размышлять куда же деть разросшийся Tranzaction Log

7) Уберите базу tempdb от обычных баз на другой диск - даже если при этом придётся переконфигурировать RAID массив и снизить его производительность. Иначе 1 пользователь сможет парализовать работу всех остальных. Если у вас есть Hardware Accelereator вместо жесткого диска то конечно можно не отделять и положить tempdb на него, но это только в случае если таковой имеется

8) установите какое-нибудь средство мониторинга - мне, к примеру, нравится spotlight http://www.quest.com/spotlight-on-sql-server-enterprise/

9) Проверьте себя с best practice analizer от Microsoft - http://www.microsoft.com/download/en/details.aspx?id=15289 - замечательный инструмент, который помогает не только с настройками, но и с решением многих проблем.

Теперь вкратце для чего мы всё это делали:

1) Память. Минимальное значение просто убережет вас от "глюков", когда SQL сервер по каким-то только ему известным причинам не использует всю доступную ему память. Должен съесть всю! Максимальное значение убережет вас от свопа в случае если тот же самый оптимизатор использования памяти SQL сервер-а решит что ему ещё на помешало бы....

3) Очень важный пункт - ИХМО его нужно ставить в 1 во всех транзакционных системах. Во-первых - это предотвращает часть блокировок между разными процессами, пытающимися выполнить 1 запрос, соответственно уберегает нас от некоторых "странных" ошибок. Во-вторых... 1 "убийственный" запрос сможет вытянуть на себя все ресурсы сервера, что несколько не справедливо по отношению к остальным пользователям системы.Собственно параметр определяет - сколькими ядрами процессоров может обрабатываться 1 запрос.

5) Про статистику и очистку процедурного кэша - это "на слуху " а вот про реиндексацию часто забываем. А между тем это процедура достаточно важная, особенно с ростом объёма базы важность её увеличивается. Иногда на фрагментации индексов теряется до60 % производительности.

7) При наличии Hardware Accelerator или просто 2 дисков с разными скоростями доступа я бы рекоммендовал ещё задуматься о выделении в базах файловых групп и разделении отдельных таблиц на разные дисковые массивы, с разным временем доступа. Ведь согласитесь, РН "товары на складах" и справочник "Хранилище дополнительной информации" 2 объекта требования к хранению которых в корне рознятся. Не обязательно на быстром массиве хранить все файлы и картинки в базе - можно выделить его на отдельный, не такой быстрый, но где места много (и не бояться потом в базу кучу файлов загружать, кстати).

Tutorial

Данная инструкция предназначена для новичков, ищущих простое руководство на русском языке для установки английской версии SQL Server 2012, который будет далее использоваться для SharePoint 2013.
Эта статья не для профессионалов.

Вся работа разделена на 3 этапа:

Установка SQL Server 2012
Настройка параметра конфигурации сервера max degree of parallelism
Настройка прав учетной записи, предназначенной для установки SharePoint 2013

Также в статье описывается процесс установки Microsoft .NET Framework 3.5 в среде MS Windows Server 2012 R2 Standart.

Внимание: под катом много картинок!

Установка SQL Server 2012

1. Перед установкой следует убедиться, что на жестком диске достаточно свободного места (в моем случае потребовалось 2.7 ГБ).
После запуска дистрибутива выбираем пункт "Installation " в левом меню, затем «кликаем» пункт "New SQL Server stand-alone or add features to an existing installation ":

2. Запустится мастер установки. Он выполнит проверку. Можно кликнуть по кнопке «Show details» и посмотреть детальный отчет:

3. Детальный отчет. Нажимаем кнопку «ОК»:

4. Вводим ключ продукта и нажимаем кнопку «Next»:

5. Соглашаемся c условиями лицензионного соглашения.
Для этого ставим галочку "I accept the license terms

6. На шаге «Setup Role» выбираем первый пункт "SQL Server Feature Installation ". Нажимаем кнопку «Next»:

7. На шаге «Feature Selection» отмечаем "Database Engine Services ", "Management Tools – Basic " и "Management Tools – Complete ". Затем нажимаем кнопку «Next»:

8. Затем установщик выполнит еще одну проверку. Можно кликнуть по кнопке «Show details» и посмотреть детальный отчет:

9. Детальный отчет. (На данном этапе у меня возникла ошибка в правиле «Microsoft .NET Framework 3.5 is installed ...». Об этом ниже). Нажимаем кнопку «Next»:

10. На шаге «Instance Configuration» необходимо сконфигурировать экземпляр службы SQL-сервера.
Повторюсь, что данная статья предназначена для новичков. Поэтому сделаем предположение, что на вашем сервере до этого не устанавливался SQL Server, а значит оставим все настройки по умолчанию. Нажимаем кнопку «Next»:

11. На данном шаге мастер установки отобразит требования к дисковому пространству. Нажимаем кнопку «Next»:

12. На шаге «Server Configuration» необходимо указать доменную учетную запись для службы "SQL Server Database Engine ". После заполнения полей «Account Name» и «Password» нажимаем кнопку «Next»:

13. На шаге «Database Engine Configuration» достаточно добавить текущего пользователя в администраторы SQL-сервера. Для этого нажмите кнопку «Add Current User», затем нажмите кнопку «Next»:

14. На следующем шаге нажимаем кнопку «Next»:

15. Далее мастер установки опять выполнит проверку и отобразит её результаты. Нажимаем кнопку «Next»:

16. На шаге «Ready to Install» мастер отобразит сводную информацию. Здесь необходимо нажать кнопку «Install»:

17. После завершения установки отобразится информация о произведенных операциях:

18. Крайне рекомендую на данном этапе перезагрузить компьютер. В некоторых случаях (например, при инсталляции Microsoft .NET Framework 3.5) мастер установки сам отобразит окно с предложением перезагрузить компьютер. Не отказывайтесь.

Настройка параметра конфигурации сервера max degree of parallelism

По умолчанию значение параметра «Max Degree of Parallelism» равно 0.
SharePoint 2013 требует, чтобы этот параметр был равен 1.
Это легко исправить!

1. Запустите Microsoft SQL Server Management Studio (Пуск - Все программы - Microsoft SQL Server 2012 - SQL Server Management Studio).

2. На экране подключения к серверу нажмите кнопку «Connect».

3. Щелкните правой клавишей мыши по вашему серверу в окне "Object Explorer " и выберите пункт "Properties ":

4. В открывшемся окне свойств сервера в левом меню выберите страницу "Advanced " и промотайте список свойств в самый низ экрана. Установите значение параметра "Max Degree of Parallelism " в 1 и нажмите кнопку «ОК»:

5. Не закрывайте SQL Server Management Studio, она нам еще пригодится.

Настройка прав учетной записи, предназначенной для установки SharePoint 2013

Учетная запись, от имени которой будет производиться установка SharePoint 2013, должна обладать повышенными правами в SQL-сервере.
Этой учетной записи рекомендуется дать следующие роли:

dbcreator
securityadmin
public

1. В SQL Server Management Studio в окне "Object Explorer " разверните пункт "Security ". Затем щелкните правой клавишей мышки на пункте "Logins " и выберите пункт "New Login ":

2. В поле «Login name» введите доменное имя учетной записи, из под которой вы планируете установить и настроить SharePoint 2013.

3. В левом меню выберите страницу "Server Roles " и отметьте роли «dbcreator» и «securityadmin», а также убедитесь, что роль «public» уже отмечена. Затем нажмите кнопку «ОК»:

Теперь SQL-сервер готов к установке SharePoint 2013.

Установка Microsoft .NET Framework 3.5 в среде MS Windows Server 2012 R2 Standart

В шаге №9 пункта "Установка SQL Server 2012 " у меня возникла ошибка: не был установлен.NET Framework 3.5.
Для решения этой проблемы необходимо выполнить следующие шаги:

1. Необходимо открыть консоль "Server Manager ".

2. В левом меню выбираем пункт «Dashboard».

3. В центре окна щелкаем по пункту «Add roles and features».

4. В открывшемся мастере пропускаем шаг «Before You Begin».

5. На шаге «Installation Type» выбираем пункт "Role-based or feature-based installation ". Нажимаем кнопку «Next».

6. На следующем шаге оставляем все по умолчанию и нажимаем кнопку «Next».

7. Пропускаем шаг «Server Roles», нажав кнопку «Next».

8. На шаге «Features» отмечаем галочку ".NET Framework 3.5 Features". Нажимаем кнопку «Next».

9. После завершения процесса установки можно закрыть мастер «Add Roles and Features Wizard».

10. Готово!

Всем добра и мирного неба над головой!

P.S. С наступающим Днем космонавтики!

Max degree of parallelism (DOP) - дополнительна опция конфигурации SQL Server, с которой связано много вопросов и которой посвящено множество публикаций. В этой статье своего блога, автор надеется внести немного ясности в то, что эта опция делает и как её нужно использовать.
Во-первых, автор хотел бы рассеять любые сомнения по поводу того, что указанная опция устанавливает, сколько процессоров может использовать SQL Server при обслуживании нескольких подключений (или пользователей) - это не так! Если SQL Server имеет доступ к четырем неактивным процессорам, и он настроен на использование всех четырёх процессоров, он будет использовать все четыре процессора, независимо от максимальной степени параллелизма.
Так, что же эта опция даёт? Эта опция устанавливает максимальное число процессоров, которые SQL Server может использовать для одного запроса. Если запрос к SQL Server должен вернуть большой объём данных (много записей), его иногда имеет смысл распараллелить, разбив на несколько маленьких запросов, каждый из которых будет возвращать своё подмножество строк. Таким образом, SQL Server может использовать несколько процессоров, и, следовательно, на многопроцессорных системах большое количество записей всего запроса потенциально может быть возвращено быстрее, чем на однопроцессорной системе.
Есть множество критериев, которые должны быть учтены до того, как SQL Server вызовет "Intra Query Parallelism" (разбивку запроса на несколько потоков), и нет смысла их здесь детализировать. Вы можете найти их в BOL, поискав фразу "Degree of parallelism". Там написано, что решение о распараллеливании основано на доступности памяти процессору и, особенно, на доступности самих процессоров.
Итак, почему мы должны продумать использование этой опции - потому что, оставляя её в значении по умолчанию (SQL Server сам принимает решение о распараллеливании), иногда можно получить нежелательные эффекты. Эти эффекты выглядят примерно так:

Распараллеленные запросы выполняются медленнее.

Время исполнения запросов может стать недетерминированным, и это может раздражить пользователей. Время исполнения может измениться потому что:

Запрос может иногда распараллеливаться, а иногда нет.

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

Прежде, чем мы продолжим, автор хотел бы заметить, что нет особой необходимости погружаться во внутреннюю организацию параллелизма. Если же Вы этим интересуетесь, Вы можете почитать статью "Parallel Query Processing" в Books on Line, в которой эта информация изложена более детально. Автор считает, что есть только две важные вещи, которые стоит знать о внутренней организации параллелизма:

Параллельные запросы могут породить больше потоков, чем указано в опции "Max degree of parallelism". DOP 4 может породить более двенадцати потоков, четыре для запроса и дополнительные потоки, используемые для сортировок, потоков, агрегатов и сборок и т.д.

Распараллеливание запросов может провоцировать разные SPID ожидать с типом ожидания CXPACKET или 0X0200. Этим можно воспользоваться для того, что бы найти те SPID, которые находятся в состоянии ожидания при параллельных операциях, и имеют в sysprocesses waittype: CXPACKET. Для облегчения этой задачи, автор предлагает воспользоваться имеющейся в его блоге хранимой процедурой: track_waitstats.

И так "Запрос может выполняться медленнее при распараллеливании" почему?

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

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

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

Из всего этого следует рекомендация проверять исполнение запроса без параллелизма (DOP=1), это поможет идентифицировать возможные проблемы.
Упомянутые выше эффекты параллелизма, сами собой должны навести Вас на мысль о том, что внутренняя механика распараллеливания запросов не подходит для применения в OLTP - приложениях. Это такие приложения, для которых изменение времени исполнения запроса может раздражать пользователей и для которых сервер, одновременно обслуживающий множество пользователей, вряд ли выберет параллельный план исполнения из-за присущих этим приложениям особенностей профиля рабочей нагрузки процессора.
Поэтому, если Вы собираетесь использовать параллелизм, то, скорее всего это понадобится, для задач извлечения данных (data warehouse), поддержки принятия решений или отчётных систем, где не много запросов, но они являются достаточно тяжёлыми и исполняются на мощном сервере с большим объёмом оперативной памяти.
Если Вы решили использовать параллелизм, какое же значение нужно установить для DOP?. Хорошей практикой для этого механизма является то, что если Вы имеете 8 процессоров, тогда устанавливайте DOP = 4, и это с большой степенью вероятности будет оптимальной установкой. Однако, нет никаких гарантий, что так оно и будет работать. Единственный способ убедиться в этом - протестировать разные значения для DOP. В дополнение к этому, автор хотел предложить свой, основанный на эмпирических наблюдениях совет, никогда не устанавливать это число больше, чем половине от числа процессоров, которые есть в наличии. Если бы автор имел процессоров меньше шести, он установил бы DOP в 1, что просто запрещает распараллеливание. Он мог бы сделать исключение, если бы имел базу данных, которая поддерживает процесс только одного пользователя (некоторые технологии извлечения данных или задачи отчётности), в этом случае, в порядке исключения, можно будет установить DOP в 0 (значение по умолчанию), которое позволяет SQL Server самому принимать решение о необходимости распараллеливания запроса.
Прежде, чем закончить статью, автор хотел предостеречь Вас по поводу того, что параллельное создание индексов зависит от числа, которое Вы устанавливаете для DOP. Это означает, что Вы можете захотеть изменять его на время создания или пересоздания индексов, чтобы повысить производительность этой операции, и, конечно же, Вы можете использовать в запросе хинт MAXDOP, который позволяет игнорировать установленное в конфигурации значение и может быть использован в часы минимальной нагрузки.
Наконец, ваш запрос может замедляться при распараллеливании из-за ошибок, поэтому убедитесь, что на вашем сервере установлен последний сервисный пакет (service pack).

CREATE proc track_waitstats (@num_samples int =10 ,@delaynum int =1 ,@delaytype nvarchar (10 )="minutes" ) AS -- T. Davidson -- This stored procedure is provided =AS IS= with no warranties, -- and confers no rights. -- Use of included script samples are subject to the terms -- specified at http://www.microsoft.com/info/cpyright.htm -- @num_samples is the number of times to capture waitstats, -- default is 10 times. default delay interval is 1 minute -- delaynum is the delay interval. delaytype specifies whether -- the delay interval is minutes or seconds -- create waitstats table if it does not exist, otherwise truncate set nocount on if not exists (select 1 from sysobjects where name = "waitstats" ) create table waitstats ( varchar (80 ), requests numeric (20 ,1 ), numeric (20 ,1 ), numeric (20 ,1 ), now datetime default getdate ()) else truncate table waitstats dbcc sqlperf (waitstats,clear) -- clear out waitstats declare @i int ,@delay varchar (8 ) ,@dt varchar (3 ) ,@now datetime ,@totalwait numeric (20 ,1 ) ,@endtime datetime ,@begintime datetime ,@hr int ,@min int ,@sec int select @i = 1 select @dt = case lower (@delaytype) when "minutes" then "m" when "minute" then "m" when "min" then "m" when "mm" then "m" when "mi" then "m" when "m" then "m" when "seconds" then "s" when "second" then "s" when "sec" then "s" when "ss" then "s" when "s" then "s" else @delaytype end if @dt not in ("s" ,"m" ) begin print "please supply delay type e.g. seconds or minutes" return end if @dt = "s" begin select @sec = @delaynum % 60 select @min = cast ((@delaynum / 60 ) as int ) select @hr = cast ((@min / 60 ) as int ) select @min = @min % 60 end if @dt = "m" begin select @sec = 0 select @min = @delaynum % 60 select @hr = cast ((@delaynum / 60 ) as int ) end select @delay = right ("0" + convert (varchar (2 ),@hr),2 2 ),@min),2 ) + ":" + + right ("0" +convert (varchar (2 ),@sec),2 ) if @hr > 23 or @min > 59 or @sec > 59 begin select "hh:mm:ss delay time cannot > 23:59:59" select "delay interval and type: " + convert (varchar (10 ) ,@delaynum) + "," + @delaytype + " converts to " + @delay return end while (@i <= @num_samples) begin insert into waitstats (, requests, ,) exec ("dbcc sqlperf(waitstats)" ) select @i = @i + 1 waitfor delay @delay End --- create waitstats report execute get_waitstats --//--//--//--//--//--//--//--//--//-//--//--//--//--//--//--//--//--/ CREATE proc get_waitstats AS -- This stored procedure is provided =AS IS= with no warranties, and -- confers no rights. -- Use of included script samples are subject to the terms specified -- at http://www.microsoft.com/info/cpyright.htm -- -- this proc will create waitstats report listing wait types by -- percentage -- can be run when track_waitstats is executing set nocount on declare @now datetime ,@totalwait numeric (20 ,1 ) ,@endtime datetime ,@begintime datetime ,@hr int ,@min int ,@sec int select @now=max (now),@begintime=min (now),@endtime=max (now) from waitstats where = "Total" --- subtract waitfor, sleep, and resource_queue from Total select @totalwait = sum () + 1 from waitstats where not in ("WAITFOR" ,"SLEEP" ,"RESOURCE_QUEUE" , "Total" , "***total***" ) and now = @now -- insert adjusted totals, rank by percentage descending delete waitstats where = "***total***" and now = @now insert into waitstats select "***total***" ,0 ,@totalwait ,@totalwait ,@now select , ,percentage = cast (100 */@totalwait as numeric (20 ,1 )) from waitstats where not in ("WAITFOR" ,"SLEEP" ,"RESOURCE_QUEUE" ,"Total" ) and now = @now order by percentage desc

ОБЛАСТЬ ПРИМЕНЕНИЯ ЭТОЙ СТАТЬИ: SQL Server (начиная с 2008)База данных SQL AzureХранилище данных SQL AzureParallel Data Warehouse

В этом разделе описываются способы настройки параметра конфигурации сервера max degree of parallelism (MAXDOP) в SQL Server 2016 с помощью среды SQL Server Management Studio или Transact-SQL. Если экземпляр SQL Server работает на многопроцессорном компьютере, он определяет оптимальную степень параллелизма, то есть количество процессоров, задействованных для выполнения одной инструкции, для каждого из планов параллельного выполнения. Для ограничения количества процессоров в плане параллельного выполнения может быть использован параметр max degree of parallelism . SQL Server учитывает планы параллельного выполнения для запросов, операций DDL с индексами, параллельной вставки, изменения столбца в режиме "в сети", параллельного сбора статистики и заполнения статических курсоров и курсоров, управляемых набором ключей.

Ограничения

Если параметр affinity mask имеет значение, отличное от значения по умолчанию, он может ограничивать число процессоров, доступных для SQL Server в симметричных многопроцессорных системах (SMP).

Этот параметр является дополнительным и его следует изменять только опытным администраторам баз данных или сертифицированным техническим специалистам SQL Server .

Чтобы разрешить серверу определять максимальную степень параллелизма, установите 0 в качестве значения данного параметра, то есть значение по умолчанию. Установка значения 0 в качестве максимальной степени параллелизма позволяет SQL Server использовать все доступные процессоры (до 64 процессоров). Чтобы отключить создание параллельных планов, присвойте параметру max degree of parallelism значение 1. Задайте значение для параметра в диапазоне от 1 до 32 767, чтобы указать максимальное количество процессорных ядер, которые могут быть использованы при выполнении одного запроса. Если указано значение, превышающее количество доступных процессоров, используется действительное количество доступных процессоров. Если у компьютера только один процессор, то значение параметра max degree of parallelism учитываться не будет.

Значение параметра max degree of parallelism можно переопределить, задав в инструкции указание запроса MAXDOP. Дополнительные сведения см. в разделе .

Операции по созданию и перестройке индексов, а также по удалению кластеризованного индекса могут оказаться достаточно ресурсоемкими. Значение параметра max degree of parallelism для операций с индексами можно переопределить, указав в инструкции параметр индекса MAXDOP. Значение MAXDOP применяется к инструкции во время выполнения и в метаданных индекса не хранится. Дополнительные сведения см. в статье .

Помимо запросов и операций с индексами, этот параметр также управляет степенью параллелизма при выполнении инструкций DBCC CHECKTABLE, DBCC CHECKDB и DBCC CHECKFILEGROUP. Планы параллельного выполнения для этих инструкций можно отключить с помощью флага трассировки 2528. Дополнительные сведения см. в разделе .

Безопасность

Разрешения

Разрешения на выполнение хранимой процедуры sp_configure без параметров или только с первым параметром по умолчанию предоставляются всем пользователям. Для выполнения процедуры sp_configure с обоими параметрами для изменения параметра конфигурации или запуска инструкции RECONFIGURE необходимо иметь разрешение ALTER SETTINGS на уровне сервера. Разрешение ALTER SETTINGS неявным образом предоставлено предопределенным ролям сервера sysadmin и serveradmin .

В обозревателе объектов щелкните правой кнопкой мыши сервер и выберите пункт Свойства .

Щелкните узел Дополнительно .

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

Настройка параметра максимальной степени параллелизма

Установите соединение с компонентом Компонент Database Engine.

На панели «Стандартная» нажмите Создать запрос .

Скопируйте следующий пример в окно запроса и нажмите кнопку Выполнить . В этом примере описывается использование процедуры для задания значения параметра max degree of parallelism равным 8 .

USE AdventureWorks2012 ; GO EXEC sp_configure "show advanced options" , 1 ; GO RECONFIGURE WITH OVERRIDE; GO EXEC sp_configure "max degree of parallelism" , 8 ; GO RECONFIGURE WITH OVERRIDE; GO

Дополнительные сведения см. в статье

Не секрет, что обдумывая проблемы конфигурирования SQL сервера, связанные с увеличением производительности, IT-специалисты в своем большинстве, делают выбор в пользу увеличения аппаратных средств. Но всегда ли это оправдано? Все ли методы настройки сервера при этом уже использованы? Известно, что работа с параметрами конфигурации и изменение их значений по умолчанию, способна улучшить производительность и другие характеристики данной системы. Среди этих опций конфигурации SQL есть одна опция, с которой связано много вопросов, это опция - Max degree of parallelism (DOP) - вот о ней и поговорим.

Опция Maximum Degree of Parallelism (DOP) определяет число потоков, на которые SQL Server может распараллелить запрос и означает число используемых процессоров сервера. Параметр этот умолчанию имеет значение 0 – максимальную степень параллелизма. Например, если вы имеете 24 ядра – тогда значение ‘max degree of parallelism’ будет равно 24 и оптимизатор, если он посчитает нужным, может задействовать все процессоры на выполнение одной инструкции, то есть запрос будет распараллелен на 24 потока. Для большинства случаев это хорошо, но не для всех. Также, далеко не всегда хорошо, использование значение этого параметра по умолчанию. Конфигурирование этого параметра может быть нужно, например, в следующей ситуации: допустим, у нас есть приложение, в которое все сотрудники вносят информацию о ежедневных операциях, и, в определенный промежуток времени каждый из пользователей выполняет запрос, который строит отчет обо всех операциях пользователя за некий промежуток времени. Естественно, что если промежуток времени большой, этот запрос будет выполняться долго и, при установке DOP по умолчанию, займет все доступные процессоры, что, естественно, скажется на работе остальных пользователей. Следовательно, изменяя значение DOP, мы можем без изменения самого запроса повысить время отклика SQL сервера у других пользователей.
MS рекомендует устанавливать значение следующим образом:

Установка параметра на TSQL целиком для сервера:

EXEC sp_configure "max degree of parallelism", 4; reconfigure

Так же вы можете установить это значение для конкретного TSQL запроса:

USE AdventureWorks2008R2 ; GO SELECT ProductID, OrderQty, SUM(LineTotal) AS TotalFROM Sales.SalesOrderDetail WHERE UnitPrice < $5.00 GROUP BY ProductID, OrderQty ORDER BY ProductID, OrderQty OPTION (MAXDOP 2); GO

В этом примере «хинт» maxdop меняет значение по умолчанию параметра max degree of parallelism на 2. Посмотреть текущую настройку можно так:

EXEC sp_configure "Show Advanced",1; RECONFIGURE; EXEC sp_configure "max degree of parallelism"

Теперь давай те посмотрим как влияет это значение на скорость выполнения запроса. Для того что бы тестовый запрос, написанный выше, выполнялся более продолжительное время, добавим в него ещё один select. Запрос приобретет следующий вид:

< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty

На моей тестовой машине значение ‘max degree of parallelism’ выставлено в 0. MSSQL запущен на машине с 4-х ядерным процессором. Я провел серию экспериментов с разными значениями MAXDOP: равным 1 – без распараллеливания запроса; равным 2 - с использованием только 2 ядер; равным 4 – с использованием всех и без хинта для определения варианта, который использует сиквел по умолчанию. Для того, чтобы получить статистику выполнения, в запрос нужно включить опцию SET STATISTICS TIME ON, а также включить кнопку отображения плана запроса в Management studio. Для усреднения полученных результатов я выполнял каждый запрос в цикле 3 раза. Результаты можно видеть ниже:

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice < $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 1); SQL Server Execution Times: CPU time = 45942 ms, elapsed time = 46118 ms. SQL Server Execution Times: CPU time = 45926 ms, elapsed time = 46006 ms. SQL Server Execution Times: CPU time = 45506 ms, elapsed time = 45653 ms.

На плане запроса видно что при установке хинта (MAXDOP 1) запрос выполнялся без распараллеливания. Среднее время выполнения запроса 45925.66 ms

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice < $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 2); SQL Server Execution Times: CPU time = 51684 ms, elapsed time = 28983 ms. SQL Server Execution Times: CPU time = 51060 ms, elapsed time = 26165 ms. SQL Server Execution Times: CPU time = 50903 ms, elapsed time = 26015 ms.

При установке хинта (MAXDOP 2) запрос выполнялся параллельно на 2 cpu, это можно увидеть на Number of Execution в плане выполнения запроса. Среднее время выполнения запроса 27054.33 ms

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice < $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 4); SQL Server Execution Times: CPU time = 82275 ms, elapsed time = 23133 ms. SQL Server Execution Times: CPU time = 83788 ms, elapsed time = 23846 ms. SQL Server Execution Times: CPU time = 53571 ms, elapsed time = 27227 ms.

При установке хинта (MAXDOP 4) запрос выполнялся параллельно на 4 cpu. Среднее время выполнения запроса 24735.33 ms

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice < $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty SQL Server Execution Times: CPU time = 85816 ms, elapsed time = 23190 ms. SQL Server Execution Times: CPU time = 85800 ms, elapsed time = 23307 ms. SQL Server Execution Times: CPU time = 58515 ms, elapsed time = 26575 ms.