2013-06-17 3 views
4

Я столкнулся с проблемой с LINQ To Entities.linq и параллелизм - SQL Server

Если я запустил свой запрос LINQ, то он использует Параллелизм (собирать потоки и репарационный поток) в плане выполнения, который вызывает много ожиданий CXPACKET.

Но если я запускаю LINQ переведенный запрос (который я получил через функцию ToTraceString) непосредственно на мой SQL-сервер, тогда план выполнения не содержит параллелизма.

Почему существует разница в отношении параллелизма SQL при его запуске через LINQ или сам SQL-запрос?

Как я могу преодолеть эту проблему? Я хочу, чтобы мой запрос LINQ выполнялся так же, как при непосредственном запуске SQL.

Пример планов выполнения:

с помощью LINQ: using linq

SQL непосредственно:

without linq - sql directly

Я могу опубликовать мой SQL запрос, но я не думаю, что это может help here ...

+0

У меня была такая же проблема - запуск хранимой процедуры из веб-приложения вызвал таймауты, а запуск ее непосредственно из студии управления SQL был достаточно быстрым; в этом случае рекомпиляция хранимых процедур решила его. Если бы я был вами, я бы попытался просмотреть компилированные запросы - http://msdn.microsoft.com/en-us/library/bb896297.aspx (dunno, если это поможет) –

+0

Попробуйте запустить следующую команду 'DBCC FREEPROCCACHE' а затем 'sp_updatestats' и посмотреть, существует ли проблема. – Magnus

+0

Вы запустили SQL Profiler в отношении БД, чтобы увидеть, что SQL фактически выполняется Linq? Кроме того, есть ли что-нибудь смешное в строке соединения, которую использует клиент? – Robin

ответ

0

Являются ли CXPACKET на самом деле проблемой?

Когда SQL Server получает запрос, он оптимизирует его. Если расчетная стоимость запроса больше, чем порог затрат для параллелизма, он будет рассматривать параллельный запрос. Всегда можно повысить этот порог, если распараллеливается слишком много запросов.

Я хотел бы знать, существует ли какая-либо разница между запросом фреймворка сущности и вашим запросом, который может поднять сметную стоимость.

В любом случае, ожидания CXPATCKET НЕ являются проблемой. Они являются естественной частью любого параллельного запроса, и мы не платим дополнительных денег за четырехъядерные серверы с несколькими потоками, чтобы мы могли запускать все в серии. Еще одна вещь, которую нужно проверить - это сеть.

При потоковой передаче IO по сети это может занять больше времени, если вы возвращаете кучу результатов. Вот почему запуск запроса в студиях SQL Server Management может быстро вернуться, но ваш запрос с другого сервера может занять некоторое время.

Смежные вопросы