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/pr...oads/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:[vbcol=seagreen]
> It is set up by the SQL Server 2005 WMI Provider for Server Events. You ca
n
> 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. T
he
> 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/pr...nloads/books...
> This posting is provided "AS IS" with no warranties, and confers no rights.[/vbcol
]
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!