Can lots of User Connections cause high CPU use

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 2005 » SQL Server 2005 Performance Tuning » Can lots of User Connections cause high CPU...

13 posts, Page 2 of 2

««1 2

Can lots of User Connections cause high CPU use

Rate Topic

Display Mode

Topic Options

Author

Message

peterhe

Posted Wednesday, July 08, 2009 8:07 AM

Mr or Mrs. 500

Group: General Forum Members
Last Login: Wednesday, February 20, 2013 10:51 AM
Points: 531, Visits: 416

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

Rahim+971-501387269

Posted Monday, January 28, 2013 2:15 AM

Forum Newbie

Group: General Forum Members
Last Login: Sunday, March 03, 2013 5:31 AM
Points: 4, Visits: 48

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

GilaMonster

Posted Monday, January 28, 2013 2:16 AM

SSC-Dedicated

Group: General Forum Members
Last Login: Today @ 6:25 AM
Points: 37,678, Visits: 29,934

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 »

13 posts, Page 2 of 2

««1 2

Permissions