http://social.msdn.microsoft.com/Forums/en-US/sqlnetfx/thread/942fe3d4-141a-486a-afdf-53f079d3a4d3

This is an issue that is new in SQL Server 2005, and is only exposed under specific conditions – namely,

the use of the x64 version of SQL Server 2005 and the execution of large ad hoc query batches. Unfortunately, the memory that is used to store the execution plans for those ad hoc queries is not trimmed aggressively enough in the x64 version, and as a result we see more and more connections having to wait for memory allocations before they can continue. If any connection is suspended for more than 30 seconds, the application terminates the connection by reporting that the command currently executing has timed out.

This issue has been previously identified and is fixed in the upcoming service pack release (SP2) for SQL Server 2005, the Community Technology Preview (CTP) release of which is available today, and is confirmed to fix the issue in your environment.

Possible Solutions:

1. Sp2

2. create a job that manually frees the memory that is being consumed by query plans through the use of the

DBCC FREEPROCCACHE command. The documentation for this command states that “freeing the procedure cache causes,

for example, an ad hoc SQL statement to be recompiled instead of reused from the cache.”

(http://msdn2.microsoft.com/en-us/library/ms174283.aspx)

We have not tried out the second solution so far.

3.Change the Max Degree of Parallelism argument at the server/instance level, to something less than # or processors.