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

Откуда: Харків
Сообщений: 1233
Подскажите плиз. Можно ли R2 Dataceneter заставить распараллелить запрос вида:
WITH CTE1 AS (),
CTE2 AS (),
CTE3 AS () 

SELECT *
FROM table1 
LEFT JOIN CTE1 ON (три параметра)
LEFT JOIN CTE2 ON (три параметра)
LEFT JOIN CTE3 ON (три параметра)

работать в 4 потока?
Сервер вначале определяет 3 цте-шки, генерит 3 потока, но через секунду сворачивает и начинает выполнять по-очереди. Каждая ЦТЕ-шка кушает минут по 15 времени, и в итоговом запросе они между собой независимы- все джоинятся с table1.
21 июл 11, 13:27    [11006403]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
igor2222
Сервер вначале определяет 3 цте-шки, генерит 3 потока, но через секунду сворачивает и начинает выполнять по-очереди.
Это вы все в плане выполнения увидели?
21 июл 11, 13:30    [11006423]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Гавриленко Сергей Алексеевич,
План как раз показывает HASH MATCH от каждой CTE-шки в основную таблицу. И понятное дело у каждой CTE-шки он свой.
А смотрю в master.dbo.sysprocesses with(readuncommitted)
21 июл 11, 13:33    [11006448]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Уточню. Пареллелизма в плане нет. ХЕШ МАТЧ происходит последовательно. Почему- мне пока не понятно.
Можно заставить сервер смотреть на ЦТЕ-шки параллельно?
21 июл 11, 13:45    [11006543]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Хинта "параллель давай" нету. И потом, с чего вы взяли, что параллельное выполнение будет быстрее?
21 июл 11, 13:50    [11006589]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Ну вообще то я хотел бы попробовать для начала.
А решил потому, что у меня процессор не нагружен и идут постоянные качели I/O - CPU.
Т.е. получается MSSQL сам решает, задействовать ли ему все 8 процессоров или использовать исключительно один потому что так должно быть быстрее?
21 июл 11, 15:20    [11007409]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
igor2222
Ну вообще то я хотел бы попробовать для начала.
А решил потому, что у меня процессор не нагружен и идут постоянные качели I/O - CPU.
Т.е. получается MSSQL сам решает, задействовать ли ему все 8 процессоров или использовать исключительно один потому что так должно быть быстрее?
В общем и целом - да. Параллелизм можно явно уменьшать, а вот увеличивать явно его нечем.
21 июл 11, 15:28    [11007473]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Глобально, через sp_configure тоже никак не решается?
(Это уже так сказать контрольный выстрел в воздух)
21 июл 11, 16:06    [11007806]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
igor2222
Глобально, через sp_configure тоже никак не решается?
(Это уже так сказать контрольный выстрел в воздух)
Только в сторону уменьшения. Есть, правда, еще cost threshold for parallelism.
21 июл 11, 16:25    [11007963]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Там стандартная пятерочка. А у меня каждая ЦТЕ-шка минут по 10 выполняется...
21 июл 11, 16:35    [11008043]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
Glory
Member

Откуда:
Сообщений: 104751
igor2222
Там стандартная пятерочка. А у меня каждая ЦТЕ-шка минут по 10 выполняется...

А "пятерочка" - это не время выполнения, а стоимость
21 июл 11, 16:38    [11008072]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Ну так кост в секундах, а не в процентах.
А у меня явно он зашкаливает за 5 сек. по любой ЦТЕхе
21 июл 11, 16:54    [11008206]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
Glory
Member

Откуда:
Сообщений: 104751
igor2222
Ну так кост в секундах, а не в процентах.
А у меня явно он зашкаливает за 5 сек. по любой ЦТЕхе

Я любой запрос блокировкой могу заставить выполняться более 5 секунд
Поэтому все запросы сервер должен параллелить что ли ?
21 июл 11, 16:57    [11008236]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Вопрос не в том, должен ли все.
Вопрос в том, должен ли параллелить если явно кост каждого из подзапроса соизмерим с костом запроса, который их объединяет.
Разве это не логично, что имея большой запрос, который выполняется 20 минут и состоит из 4-х подзапросов, которые могут выполняться не блокируя друг друга и каждый из которых выполняется например в % соотношении 10-25-30-35, относительно друг-друга, быть тут же распараллеленными?
Получается что либо логика параллельного выполнения совсем не направлена на ускорение выполнения запросов, либо оптимизатор, имея такой процентный план, решает, что параллелизм не нужен.
Кстати.
Я взял свои ЦТЕ, которые из таблиц по 10 млн. записей возвращали по 1 тысяче группированных, засунул их в глобальные темповые таблицы - и процесс пошел. 4 потока, и как результат вместо 20 минут - 3 минуты на создание и индексацию глобальных темпов и 10 минут на параллельное выполнение....
Таки 13 минут вместо 20. Спрашивается, это нормально?
21 июл 11, 18:20    [11008864]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Кстати в БОЛе написано:
The following example sets the cost threshold for parallelism to 10 seconds.
sp_configure 'show advanced options', 1; 
GO 
reconfigure; 
GO 
sp_configure 'cost threshold for parallelism', 10; 
GO 
reconfigure; 
GO 
Что есть эти самые 10 seconds- остается загадкой...
21 июл 11, 18:22    [11008872]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
igor2222, из какой резины диски, IO шина, память и процессор? С хорошей эластичностью?
21 июл 11, 18:41    [11008981]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Диски в рейде. Загрузка - полный ноль.
Остальное уже писал ранее, что у меня качели: процессор - I/O. Грубо говоря 2 секунды процессор грузится до 30% при этом I/O на нуле, потом две секунды проходит с сотню I/O операций, при этом процессор падает в ноль. Не знаю из какой они резины, но если бы они работали одновременно и с нагрузкой раз в 5 больше- то машина справлялась бы. Ну про память писать не буду. Стоит 16 гиг - пока хватает.
21 июл 11, 19:52    [11009199]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
igor2222
ХЕШ МАТЧ происходит последовательно.
А как вы представляете подругому. Если в конце loop был это ещё не шло, а так физика не позволяет.

igor2222
Можно заставить сервер смотреть на ЦТЕ-шки параллельно?
Сервер CTE не видит, у него уже готовый развёрнутый запрос (всегда).

igor2222
Я взял свои ЦТЕ, которые из таблиц по 10 млн. записей возвращали по 1 тысяче группированных
А вы посмотрите в план, сервер видит, что группировка мало-строчная?

hash говорит что скорее нет. И почему hash а не mege. Скорее вот:
igor2222
3 минуты на создание и индексацию глобальных темпов
Статистику проанализировать. Индексы.

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

Кароче план надо анализить.
21 июл 11, 22:33    [11009648]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
igor2222
Member

Откуда: Харків
Сообщений: 1233
Mnior
Сервер CTE не видит, у него уже готовый развёрнутый запрос (всегда).

Разве это принципиально - каждая ЦТЕ-шка или каждый вложенный независимый подзапрос?
А вы посмотрите в план, сервер видит, что группировка мало-строчная?

Наоборот! Если бы группировка была малострочная по каждому подзапросу- то сервер можно было бы понять. Зачем грузить все 8 процессоров, если малострочный запрос займет доли секунды на одном. А так в плане 4 полноценных многострочных подзапроса. Почему их нельзя распараллеливать?
Статистику проанализировать. Индексы.

Я говорил об индексах, которые я создаю для глобальных темповых таблиц. К чему мне анализировать индексы, если я вижу и так достаточно оптимальный план по КАЖДОМУ из подзапросов. Т.е. реально получить результат по нескольким миллионам строк с просчетами сумм и каунтов по условиям не получится. Но опять таки по каждому из подзапросов, а не запросу в целом.
И помните, время на создание плана ограниченно, до хорошего ему тяжелей добраться чем сложнее запрос.

Если следовать этой логике, то MSSQL сначала пытается построить "быстрый" план, а потом думает, оптимизировать его или нет. Где можно почитать о время на создание плана ограничено? Ограничено в чём? В %, в секундах, в количестве строк запроса? Можно поподробнее?
22 июл 11, 11:51    [11011509]     Ответить | Цитировать Сообщить модератору
 Re: Распараллеливание  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
igor2222
Разве это принципиально - каждая ЦТЕ-шка или каждый вложенный независимый подзапрос?
Конечно, он и подзапросы не "видит". Для него это цельнометаличесикийый единый запрос - нет там "кусков". Он видит только индексы, кучи, статистику и ограничения.

igor2222
Если бы группировка была малострочная по каждому подзапросу- то сервер можно было бы понять. Зачем грузить все 8 процессоров, если малострочный запрос займет доли секунды на одном.
Неправильно, для малострочного - hash очень жирно, значит что-то не так. Проц практически не показатель.

igor2222
А так в плане 4 полноценных многострочных подзапроса.
А в оперативу вмещается все строки? Нет. Тогда параллельность только всё усугубит. Если у вас был правильный индекс, то вместо hash был бы merge который может сильно грузануть потоковое чтение дисков и практически не юзать оперативу.

igor2222
если я вижу и так достаточно оптимальный план по КАЖДОМУ из подзапросов.
"Понимание частей системы не даёт понимание всей системы".
Во вторых как это план оптимален если там hash? Время выполнения ничего не говорит. А вот потраченные при этом ресурсы - многое.
Вы должны понимать что можно получить результат за минуту с оперативой в 104 суслика, и за час имея только 96 (всего на 8 меньше), при том же подходе.

igor2222
Если следовать этой логике, то MSSQL сначала пытается построить "быстрый" план, а потом думает, оптимизировать его или нет.
Как много абстактных понятий, с ними можно к чему угодно прийти.

igor2222
Где можно почитать о время на создание плана ограничено? Ограничено в чём?
Во времени. Срабатывает timeout и песец ;).
Архитектура обработчика запросов (поверхностно)
How SQL Server Determines an Execution Plan Using Available Indexes and Statistics
The Phases of Query Optimization
Microsoft SQL Server Query Processor Internals and Architecture
22 июл 11, 22:34    [11015394]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить