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:
...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.