Назад | Перейти на главную страницу

В чем опасность использования параллелизма на сервере sql?

У нашего клиента сервер sql настроен на 1 для степени параллелизма. На сервере 8 ЦП, так что зачем ограничивать эту степень до 1?

SQL Server уже отправит несколько запросов на несколько процессоров (при наличии лицензии). В больших запросах он может разбить один запрос на несколько потоков (и, возможно, на ЦП), включив параллелизм.

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

Это очень общие рекомендации, дополнительная информация от MS на Параллельная обработка запросов, а Степень параллелизма настройка.

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

Вот как я отвечу, исходя исключительно из моего опыта и ограниченных знаний:

Кажется, что SQL Server принимает решение о том, следует ли использовать параллелизм в плане запроса, в основном на основании того, поможет ли это ускорить возврат однократного выполнения этого запроса. В большинстве случаев эта оценка довольно точна; иногда оптимизатор может сделать выбор, который оказывается не очень удачным. Но в любом случае он не принимает во внимание, что еще происходит с этим сервером. В частности, если вы используете сервер, который обрабатывает большое количество пакетных запросов в секунду, и некоторая значительная часть этих пакетов распараллеливается, вы можете столкнуться с нехваткой потоков. То есть все планировщики заняты обработкой распараллеленных запросов или их ожиданием, и ничто не может быть обработано. Это может проявляться в том, что SQL Server не отвечает. Обратите внимание, что вы не обязательно увидите 100% загрузку ЦП. У вас закончился не процессор, а доступные планировщики. Как правило, у вас будет много ожиданий CX_PACKET и, возможно, THREADPOOL, а среднее количество запускаемых задач по планировщикам больше 1.

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