Constant WAITFOR(RECEIVE) in Profile Trace?

After seeing abnormally high load on the sql server this morning, i've
been investigating. After ruling out the usual sources, i ran a trace
on the DB, limited to showing only queries taking longer than 2000
miliseconds, only to find a constant stream of:
WAITFOR (RECEIVE message_body FROM WMIEventProviderNotificationQueue),
TIMEOUT 5000
it stops ~5000ms, then another one occurs!
Is this causing my load? I've had no luck googling for that message,
so not sure how common it seems to be .. Only thing I can think of is
last week we set up database mail, is this related? The field
"message_body" seems to indicate perhaps it is related to this?
Is it normal? or is this my CPU load problem?
How do I fix it? Thanks in advance!<vidguide@.gmail.com> wrote in message
news:1170282805.989902.152780@.j27g2000cwj.googlegroups.com...
> After seeing abnormally high load on the sql server this morning, i've
> been investigating. After ruling out the usual sources, i ran a trace
> on the DB, limited to showing only queries taking longer than 2000
> miliseconds, only to find a constant stream of:
> WAITFOR (RECEIVE message_body FROM WMIEventProviderNotificationQueue),
> TIMEOUT 5000
> it stops ~5000ms, then another one occurs!
> Is this causing my load? I've had no luck googling for that message,
> so not sure how common it seems to be .. Only thing I can think of is
> last week we set up database mail, is this related? The field
> "message_body" seems to indicate perhaps it is related to this?
> Is it normal? or is this my CPU load problem?
> How do I fix it? Thanks in advance!
>
I am not sure exactly what process is causing this, but shouldn't be a
performance problem. This is a normal usage pattern for a service broker
application reading a queue.
The WAITFOR RECEIVE is the command to perform a blocking read on a queue.
It consumes no resources while waiting, times out after 5000ms and
immediately starts another blocking read.
David|||It is set up by the SQL Server 2005 WMI Provider for Server Events. You can
find more information here:
http://msdn2.microsoft.com/en-us/library/ms181893.aspx
As David noted in his reply, this should not be a performance hit. RECIEVE
just waits until it either gets a message in it's queue or it times out. The
WMI provider is just launching another RECIEVE when one times out.
--
Alan Brewer [MSFT]
SQL Server Documentation Team
Download the latest Books Online update:
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
This posting is provided "AS IS" with no warranties, and confers no rights.|||On Feb 1, 12:53 pm, "Alan Brewer [MSFT]" <ala...@.microsoft.com> wrote:
> It is set up by the SQL Server 2005 WMI Provider for Server Events. You can
> find more information here:
> http://msdn2.microsoft.com/en-us/library/ms181893.aspx
> As David noted in his reply, this should not be a performance hit. RECIEVE
> just waits until it either gets a message in it's queue or it times out. The
> WMI provider is just launching another RECIEVE when one times out.
> --
> Alan Brewer [MSFT]
> SQL Server Documentation Team
> Download the latest Books Online update:http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
> This posting is provided "AS IS" with no warranties, and confers no rights.
Thanks very much for your information. Turns out it was one of the
clients causing the load, i'd just missed it on the first sweep, these
messages were just new/repeating, so looked suspicious :)
Thanks heaps!