Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Can lots of User Connections cause high CPU use Expand / Collapse
Author
Message
Posted Wednesday, July 8, 2009 8:07 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Wednesday, October 22, 2014 7:18 AM
Points: 531, Visits: 433
Are you sure it is the % Privileged Time >90%? That means CPU is busy in kennel mode, e.g. using operating system services, processing IOs, Paging Memories to disk, etc.

What is the % User time?



Post #749268
Posted Monday, January 28, 2013 2:15 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Sunday, September 14, 2014 2:09 AM
Points: 4, Visits: 49
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.
Post #1412262
Posted Monday, January 28, 2013 2:16 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 6:50 AM
Points: 40,425, Visits: 36,875
Please note: 4 year old thread.

Also, ad-hoc queries and plan cache has nothing to do with sleeping connections. Sleeping connections are ones waiting for input from the application, they are doing nothing.
Max degree of parallelism has nothing to do with sleeping connections, nor with plan memory



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1412263
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse