Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 MAX DOP  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4379
Господа,
есть сервер на который перенесли отдельную БД -- хранилище. SQL 2014 Ent, база 3 TB. SIMPLE RECOVERY

Характер запросов от 5 до 15 крупных запросов параллельно. (редко 25)

Время жизни сессий от 2 мин до 5-10 часов. В среднем 20-30 минут.

Всего 40 ядер.

Вопрос, какой дефолтовый Max DOP кто порекомендует для данного сервера?

cpu_ticks ms_ticks cpu_count hyperthread_ratio physical_memory_kb virtual_memory_kb committed_kb committed_target_kb visible_target_kb stack_size_in_bytes os_quantum os_error_mode os_priority_class max_workers_count scheduler_count scheduler_total_count deadlock_monitor_serial_number sqlserver_start_time_ms_ticks sqlserver_start_time affinity_type affinity_type_desc process_kernel_time_ms process_user_time_ms time_source time_source_desc virtual_machine_type virtual_machine_type_desc
646366488683473 182096874 40 20 536771720 137438953344 515292464 515292464 515292464 2093056 4 5 32 1088 40 48 3384929 890623 2017-08-02 13:58:27.610 2 AUTO 17138359 286459359 0 QUERY_PERFORMANCE_COUNTER 0 NONE
4 авг 17, 16:21    [20701472]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
o-o
Guest
оставьте по умолчанию и решайте проблемы по мере их поступления
4 авг 17, 16:40    [20701547]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
человек_ниоткуда
Guest
a_voronin,
дефолтный... хм... ну ИЛИ(1/8; 1/4; 1/2; 1) от количества процессоров в одной NUMA ноде.

cost_threshold_parallelism можно ещё подтёнить чтоб процессинг случайно не тормознул с CX_PACKET из-за кривого параллельного запроса.
4 авг 17, 16:42    [20701553]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
Dmitry V. Liseev
Member [заблокирован]

Откуда: Санкт-Петербург
Сообщений: 5490
o-o
оставьте по умолчанию и решайте проблемы по мере их поступления
+1
4 авг 17, 18:14    [20701822]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Dmitry V. Liseev
o-o
оставьте по умолчанию и решайте проблемы по мере их поступления
+1
-1
8 авг 17, 22:12    [20709555]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
o-o
Guest
Тогда вместо опроса населения идем в BOL и читаем там Guidelines
9 авг 17, 06:46    [20709751]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30792
o-o
оставьте по умолчанию и решайте проблемы по мере их поступления

o-o
Тогда вместо опроса населения идем в BOL и читаем там Guidelines
Так и в BOL советуют 8. Почему оставить по умолчанию?
ИМХО надо сделать 8, и потом уже смотреть.
9 авг 17, 08:00    [20709792]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
o-o
Guest
Я поэтому и привожу ссылку.
Я совсем не против, наоборот.
Мой ответ "оставить по умолчанию" это для случая, когда вопрошающий сам не знает, и документация его не устраивает.
Ибо зачем опрашивать народ, если и так все написано?
Тот, кто читал/знает, уже ответил на это, -1
9 авг 17, 08:08    [20709803]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
iii2
Member

Откуда:
Сообщений: 202
o-o
Я поэтому и привожу ссылку.
Я совсем не против, наоборот.
Мой ответ "оставить по умолчанию" это для случая, когда вопрошающий сам не знает, и документация его не устраивает.
Ибо зачем опрашивать народ, если и так все написано?
Тот, кто читал/знает, уже ответил на это, -1

Так по умолчанию ж там 0 стоит! Если он говорит, что у него есть параллельновыполняющиеся запросы - логично, вроде, как то ограничить?
Я бы, для начала, выставил = количеству "железных" ядер в нума-ноде, и прислушался бы к крикам пользователей.
Если бы крики участились - стал бы возиться со счетчиками и вообще как то мерять производительность.

... хотя, для начала выяснил бы, чё, собственно, хотят то от сервера. Может это какие-то оффлайновые отчеты считаются, и им скорость +- час - не критична.
9 авг 17, 08:48    [20709838]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30792
iii2
Я бы, для начала, выставил = количеству "железных" ядер в нума-ноде, и прислушался бы к крикам пользователей.
По рекомендациям - 8, но не больше количества логических ядер. У него похоже 2 10-ти ядерных проца.
Я на автомате ставлю 8 много много лет...
9 авг 17, 08:58    [20709863]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
iii2
Member

Откуда:
Сообщений: 202
alexeyvg
iii2
Я бы, для начала, выставил = количеству "железных" ядер в нума-ноде, и прислушался бы к крикам пользователей.
По рекомендациям - 8, но не больше количества логических ядер. У него похоже 2 10-ти ядерных проца.
Я на автомате ставлю 8 много много лет...

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

Ага, скорее всего так и есть, 2 проца, у каждого 10 ядер железных, десять - фейковых.
А вот под ввод-вывод не нужно ядра выделять?
Или это только в случае, если в системе специфическое оборудование стоит нужно делать?
Всегда этот вопрос интересовал, но т.к. всегда имел дело с лёгкими, слабонагруженными системами - так и не удосужился выяснить.
9 авг 17, 09:26    [20709908]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
o-o
Guest
iii2
Так по умолчанию ж там 0 стоит!
...
Ну, с другой стороны, и рекомендациям тоже много лет.
8, видимо, это магическое число, и связанное с программными ограничениями.

у нас что на старом сервере, что на новом(мигрировали), 8 ядер.
это DWH-сервер.
maxdop стоял 0 по умолчанию и жили мы с 8
(не потому что 8 магическое, а по числу ядер)
в один прекрасный день у немцев что-то случилось и они выставили ограничение 4.
после чего запросы к компресснутым таблицам превратились в главное тормозилово.
читаем мы много и целиком, и вот это 8 нам никогда не мешало.
а 4 отразилось.

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

К сообщению приложен файл. Размер - 27Kb
9 авг 17, 09:53    [20709992]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30792
o-o
оставили 0 (что по сути есть 8)
Так это у вас 8, а у ТС 20. Ведь сервер у него будет использовать все 20 ядер в запросе?
Тогда при параллельных запросах накладные расходы на параллелизм будут слишком велики.
10 авг 17, 01:27    [20712320]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
iii2
Member

Откуда:
Сообщений: 202
alexeyvg
o-o
оставили 0 (что по сути есть 8)
Так это у вас 8, а у ТС 20. Ведь сервер у него будет использовать все 20 ядер в запросе?
Тогда при параллельных запросах накладные расходы на параллелизм будут слишком велики.

Опять же вот много раз это слышал, но никогда не видел объяснений этому.
Почему велики то?
Engine промажет с оценкой кардинальности, нарежет выборки на неоптимальные куски (ну, например, порежет на 8, а все данные всё равно в одном - двух кусках останутся), и в результате всё будет на одном ядре считаться, а остальные потоки будут курить? Так при этом процессорные мощности, вроде, другим, ждущим запросам отойдут.
Т.е. этот запрос будет тормозить, может даже чуть больше, чем выполняемый на 1 ядре, за счет того что сервер создаст кучу потоков, выполнит всё на одном, а потом сольёт всё в один, хотя они пустые, и это делать было не нужно. И как велики эти расходы в сравнении с выполнением, скажем, в 1 поток?
И стоит ли заморачиваться такими пустяками на реальной системе, вот что интересно.
Т.е. бывают ли проигрыши в разы/десятки раз, на ощутимое время, чтобы ловить такие запросы и разбираться с ними с помощью управления ресурсами?
Было у кого нибудь в практике?
10 авг 17, 09:33    [20712608]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
iii2,

проблема не в том что выполнит за один поток, а в том что разбив на 10 потоков миллион записей промахнувшись в оценке в 1000, то 9 потоков отработают по 100 а 10й 999000 и все будут ждать его
10 авг 17, 09:45    [20712647]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
AnyKey45
Member

Откуда: Ekaterinburg-Moscow-EU
Сообщений: 219
TaPaK
iii2,

проблема не в том что выполнит за один поток, а в том что разбив на 10 потоков миллион записей промахнувшись в оценке в 1000, то 9 потоков отработают по 100 а 10й 999000 и все будут ждать его

и мы увидим тип ожидания Latch, который обычно возникает
10 авг 17, 13:39    [20713437]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
o-o
Guest
AnyKey45
TaPaK
iii2,

проблема не в том что выполнит за один поток, а в том что разбив на 10 потоков миллион записей промахнувшись в оценке в 1000, то 9 потоков отработают по 100 а 10й 999000 и все будут ждать его

и мы увидим тип ожидания Latch, который обычно возникает

о, спсб.
может быть это послужило причиной, по которой немцы нам выставляли 4?
там я не помню этого ожидания в топ 10,
а теперь оно у нас присутствует на 6-ом почетном месте.
как ни странно, без этого ожидания в топе и с выставленной 4-кой чтение компрессутого было медленнее.

кстати, попутно спрошу:
у нас оно не на чтении, у нас же LATCH_EX.
значит, это на записи при перезаливке базы.
и что с этим можно поделать?

К сообщению приложен файл. Размер - 17Kb
10 авг 17, 13:49    [20713472]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
sti
Member

Откуда:
Сообщений: 769
iii2
alexeyvg
пропущено...
Так это у вас 8, а у ТС 20. Ведь сервер у него будет использовать все 20 ядер в запросе?
Тогда при параллельных запросах накладные расходы на параллелизм будут слишком велики.

Опять же вот много раз это слышал, но никогда не видел объяснений этому.
Почему велики то?
Engine промажет с оценкой кардинальности, нарежет выборки на неоптимальные куски (ну, например, порежет на 8, а все данные всё равно в одном - двух кусках останутся), и в результате всё будет на одном ядре считаться, а остальные потоки будут курить? Так при этом процессорные мощности, вроде, другим, ждущим запросам отойдут.
Т.е. этот запрос будет тормозить, может даже чуть больше, чем выполняемый на 1 ядре, за счет того что сервер создаст кучу потоков, выполнит всё на одном, а потом сольёт всё в один, хотя они пустые, и это делать было не нужно. И как велики эти расходы в сравнении с выполнением, скажем, в 1 поток?
И стоит ли заморачиваться такими пустяками на реальной системе, вот что интересно.
Т.е. бывают ли проигрыши в разы/десятки раз, на ощутимое время, чтобы ловить такие запросы и разбираться с ними с помощью управления ресурсами?
Было у кого нибудь в практике?


Было и неоднократно, и в разных компаниях, вплоть до почти полного умирания всего и вся из-за блокировок. Ну и чем дерьмовее спроектирована структура, тем хуже, что и не удивительно.
10 авг 17, 14:13    [20713563]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30792
iii2
alexeyvg
пропущено...
Так это у вас 8, а у ТС 20. Ведь сервер у него будет использовать все 20 ядер в запросе?
Тогда при параллельных запросах накладные расходы на параллелизм будут слишком велики.

Опять же вот много раз это слышал, но никогда не видел объяснений этому.
Почему велики то?
Engine промажет с оценкой кардинальности, нарежет выборки на неоптимальные куски (ну, например, порежет на 8, а все данные всё равно в одном - двух кусках останутся), и в результате всё будет на одном ядре считаться, а остальные потоки будут курить? Так при этом процессорные мощности, вроде, другим, ждущим запросам отойдут.
Т.е. этот запрос будет тормозить, может даже чуть больше, чем выполняемый на 1 ядре, за счет того что сервер создаст кучу потоков, выполнит всё на одном, а потом сольёт всё в один, хотя они пустые, и это делать было не нужно. И как велики эти расходы в сравнении с выполнением, скажем, в 1 поток?
И стоит ли заморачиваться такими пустяками на реальной системе, вот что интересно.
Т.е. бывают ли проигрыши в разы/десятки раз, на ощутимое время, чтобы ловить такие запросы и разбираться с ними с помощью управления ресурсами?
Было у кого нибудь в практике?

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

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

Я на 4-х сокетном сервере немножко повысил производительность, сделав MAX_DOP = 8
Впрочем, может, влияние и несильное, а мне могло показаться.

С другой стороны, Guidelines из ссылки выше МС же не просто так написала?
10 авг 17, 15:26    [20713820]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
iii2
Member

Откуда:
Сообщений: 202
TaPaK
iii2,

проблема не в том что выполнит за один поток, а в том что разбив на 10 потоков миллион записей промахнувшись в оценке в 1000, то 9 потоков отработают по 100 а 10й 999000 и все будут ждать его

Так это понятно. Непонятно почему в этом случае возникнут дополнительные тормоза в сравнении с MAXDOP = 1.
Дополнительные значительные тормоза, я имею ввиду.
Что надо будет потратиться на создание нескольких ненужных потоков а потом на их слияние - это понятно.
Но это ж вроде не значительный довесок к самому выполнению?
10 авг 17, 15:32    [20713845]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
iii2
TaPaK
iii2,

проблема не в том что выполнит за один поток, а в том что разбив на 10 потоков миллион записей промахнувшись в оценке в 1000, то 9 потоков отработают по 100 а 10й 999000 и все будут ждать его

Так это понятно. Непонятно почему в этом случае возникнут дополнительные тормоза в сравнении с MAXDOP = 1.
Дополнительные значительные тормоза, я имею ввиду.
Что надо будет потратиться на создание нескольких ненужных потоков а потом на их слияние - это понятно.
Но это ж вроде не значительный довесок к самому выполнению?

не понятно почему вы всё сравниваете с 1. При правильной оценка 4 потока ~ 4 раза быстрее чем 1. О чём речь вообще?
10 авг 17, 15:34    [20713863]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30792
TaPaK
не понятно почему вы всё сравниваете с 1. При правильной оценка 4 потока ~ 4 раза быстрее чем 1. О чём речь вообще?
Понятно, что любое увеличение количества потоков вызывает ускорение.

Но в тебе другая проблема обсуждается, и ТС поднял другую проблему, и iii2 пишет о другой проблеме.

А именно, что при правильной оценка 4 потока < 4 раза быстрее чем 1

Т.е. при повышении MAX_DOP мы ускоряем отдельные запросы, но замедляем работу сервера в целом,

Для примера, мы на 16 ядерном сервере запускаем 4 запроса параллельно.
Что выгоднее, установить MAX_DOP = 4, и пусть каждый запрос выполняется на своих 4 ядрах, или установить MAX_DOP = 16 (0), и пусть каждый из 4 запросов выполняется на всех 16 ядрах одновременно?
10 авг 17, 15:44    [20713914]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
iii2
Member

Откуда:
Сообщений: 202
alexeyvg
TaPaK
не понятно почему вы всё сравниваете с 1. При правильной оценка 4 потока ~ 4 раза быстрее чем 1. О чём речь вообще?
Понятно, что любое увеличение количества потоков вызывает ускорение.

Но в тебе другая проблема обсуждается, и ТС поднял другую проблему, и iii2 пишет о другой проблеме.

А именно, что при правильной оценка 4 потока < 4 раза быстрее чем 1

Т.е. при повышении MAX_DOP мы ускоряем отдельные запросы, но замедляем работу сервера в целом,

Для примера, мы на 16 ядерном сервере запускаем 4 запроса параллельно.
Что выгоднее, установить MAX_DOP = 4, и пусть каждый запрос выполняется на своих 4 ядрах, или установить MAX_DOP = 16 (0), и пусть каждый из 4 запросов выполняется на всех 16 ядрах одновременно?

Если имеется много конкурентных запросов, то 0 выставлять нельзя, потому что если запросы спроектированы хорошо, и если база спроектировано хорошо, то каждый запрос будет монополизировать процессорные мощности и другие запросы будут курить, особенно если процессор заткнет какой-нибудь хороший, весь из себя параллельный, но долгоиграющий запрос.
Если же база спроектирована так себе, то MAXDOP=0, не окажет существенного влияния, потому что сервер будет промахиваться при распараллеливании, и потоки будут простаивать, соответственно - ресурсы уйдут к другим запросам.
Как то так? :-))))
10 авг 17, 15:56    [20713976]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
вы как-то считаете что сервер просто спит и видит как бы занять свободные ядра. MAXDOP = 8 это потолок. и потоков никак всегда не будет 8, при построении плана количество потоков будет расссчитано от "текущих"(ну почти на недавно) свободных ресурсов. Рекомендация на 8 при ядрах больше = 8, вполне логична для разноплановых запросов. Понятно что если у вас все запросы одинаковы по нагрузку то можно подбирать и более точное число
10 авг 17, 16:01    [20714002]     Ответить | Цитировать Сообщить модератору
 Re: MAX DOP  [new]
o-o
Guest
iii2
Если имеется много конкурентных запросов, то 0 выставлять нельзя, потому что если запросы спроектированы хорошо, и если база спроектировано хорошо, то каждый запрос будет монополизировать процессорные мощности и другие запросы будут курить, особенно если процессор заткнет какой-нибудь хороший, весь из себя параллельный, но долгоиграющий запрос.

у нас же 0, и никто ничего не монополизирует,
нормально конкурентно все выполняется.
и нет такого, чтобы только один кто-то выполнялся, а остальные сидели ждали.
а читают все будь здоров.
не зря же у нас на втором месте PAGEIOLATCH_SH
10 авг 17, 16:02    [20714004]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить