May 5, 2004 at 1:31 pm
I have a question about "sleeping" processes.
We have an application that access our SQL Server. I just took a look at the Current Activity and I saw 18 processes from the same person that all had a login time of a few seconds.
I have seen this before where I have had a large number of sleeping processes that had login times and last batch times that were long ago.
Is this caused by opening connections and not closing them, or is it something else? Also, should I be concerned about having a lot of sleeping connections? Is it going to cause a big drain on my system? If so, should I do something about killing sleeping processes after a certain time or will this cause bigger problems?
Thanks.
----------------------------------------------------------
01010011010100010100110000100000010100110110010101110010011101100110010101110010
001000000101001001101111011000110110101101110011
May 6, 2004 at 8:33 am
This can be somewhat confusing when looking at sp_who in Query Analyzer. I believe this is somewhat of an energy saver feature. When a spid is sleeping it is simply holding a place holder representing a login against the database. It is very common to see many processes with a status of sleeping even from Production application processes. I do not believe these processes are holding locks nor do they affect performance.
Oh, btw, GO HOGS!
Cortec
May 7, 2004 at 7:03 am
Normally a sleeping process may be waiting ether for a lock or user input. Cortec is correct the process is not holding locks.
Regards
December 8, 2009 at 7:26 am
Sorry, my last post was not complete. I also have Sleeping processes that are holding locks. The processes have no CPU, No I/O, using some memory. It is Awaiting Commands and has Last Batch time varying from 8 hrs to 5 days. These guys have prevented me from shrinking the Tlog until I killed them. We are running SQL Server 2000 Enterprise with latest SP. These TXNS have just started to appear in the last 2 weeks. Any ideas why or what could be causing these ? Thanks.
January 28, 2013 at 2:03 am
I too observed similar behavior in our production servers, in SQL 2005&2008 environments.
Here 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 on SQL 2005 X64 machines
January 28, 2013 at 2:09 am
Please note: 3 year old thread.
Also, ad-hoc queries and plan cache has nothing to do with sleeping connections.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply