FILESTREAM_WORKITEM_QUEUE high waits

Question

I've been using sp_BlitzFirst and logging the results every 15 minutes for the past 5 days. Using the new Power BI report from FirstResponderKit.org, I'm seeing a VERY large range of FILESTREAM_WORKITEM_QUEUE waits. The range for this wait is anywhere from near 0, to 2942 minutes. Total for the past 5 days is 16,406 minutes. This includes the weekend, which the server only has light usage.

What causes this wait and should I be concerned that it sometimes get above 2000 minutes for a 15 minute period?

This is SQL Server 2012 Standard with a 10-core processor.

Answer 1

Well, almost universally, any wait that is a queue or timing wait (especially one with QUEUE in the name), can largely be ignored. While this one is not explicitly listed in Paul Randal's list of waits to ignore, it may be more that this wait is rare than because it shouldn't be ignored. Across all of the instances uploading SQL Sentry wait data to the cloud, this wait type has yet to be encountered (compare that to, say, LCK_M_SCH_M, a much more frequently observed wait type - seen on close to 1% of instances).

With the combination of:

• there are no blog posts about this wait type (that I could find);
• this is the first time it has been mentioned on this site or on Stack Overflow; and,
• Microsoft hasn't even bothered to say anything about it beyond "TBD"...

...leads me to believe this is an innocuous wait that you shouldn't be concerned about.

And this is one of the problems I have with using a waits methodology for finding "problems" - is there any actual performance-related symptom involved with these waits? You're always going to have a wait that is the highest; that doesn't mean it's a problem. Now, if you can associate this wait type with observable performance symptoms in something related (such as reading from or writing to a filestream container), there might be more to investigate.

Also, are you sure you are accurately translating to minutes? There have only been 7,200 minutes in the past 5 days, so I'm not sure how this wait type could have registered more than double that. I already feel this wait type can't be anything more than a timer, which means it's simply accumulating benign wait time, and I can't imagine this also happens in parallel. So maybe the minutes you quote are actually seconds or some other unit.