November 28, 2011 at 1:43 am
I folks,
One of my server is running slow. i ran profiler, with that i came to know DatabaseMail-DatabaseMail90-ID<2588>(Application name) and object name Sp_readrequest is taking more than 3 minutes of time.
can anyone suggest me how to fix this issue..
TIA...
November 28, 2011 at 9:22 pm
Please can anyone give some valuable inputs to sort out this issue...
December 1, 2011 at 5:53 am
Experts, please advise me on this issue...
December 1, 2011 at 6:02 am
MasterDB (11/28/2011)
I folks,One of my server is running slow. i ran profiler, with that i came to know DatabaseMail-DatabaseMail90-ID<2588>(Application name) and object name Sp_readrequest is taking more than 3 minutes of time.
can anyone suggest me how to fix this issue..
TIA...
Whenever you find this SP running, check what type of waits (i.e. wait_type & last_wait_type columns) it is facing in sys.dm_exec_requests. Post the same here also so that we can further investigate.
December 2, 2011 at 5:33 am
the wait_type and last_wait_type are BROKER_RECEIVE_WAITFOR
December 2, 2011 at 5:56 am
MasterDB (12/2/2011)
the wait_type and last_wait_type are BROKER_RECEIVE_WAITFOR
Then probably you need to adjust the DatabaseMail property 'Database Mail Executable Minimum Lifetime (seconds)" to some acceptable value as per your requirement.
Go through the below discussion on msdn & you will get the insight.
December 2, 2011 at 11:45 am
I don't know how much a waitfor command would really slow your system. Unless you see blocking with the waitfor SPID as the blocker, I would look somewhere else.
The database mail task you mention is really sitting there, doing not much anything other than waiting, for something. It's on the server here near all the time. It really is pointing out that you have database mail enabled.
Before you look to adjust anything for it, try looking in other areas.
The server running slow, check the server log for anything out of the blue (unless you don't recycle the logs normally and reading the log could hurt the system io). If nothing pointing to errors, check cpu, memory use, pagefile use, and other server level settings and disk io on all volumes if easily possible. A slow server can be MANY things. A waitfor type wait stat is really something that takes time but at that time, isn't really doing anything.
December 2, 2011 at 11:52 am
Also... might want to check select * from sys.objects where modify_date > '' << where you put in the time things started going slow. It could be someone put new code out there that does not have the correct index. You might see indication of this in memory and disk use. One bad query could be hogging other things. However, if in profiler you did not catch another long running query I went past it for now. Really, anything changes in the server I like grabbing a quick view of what changed since the slow down myself to log it for record. It might also include recompiles due to invalidation of statistics, but still gives some view of what has changed.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply