FILESTREAM_WORKITEM_QUEUE高等待

Question

在过去的5天里，我一直在使用sp_BlitzFirst并每15分钟记录一次结果。使用来自FirstResponderKit.org的新Power报告，我看到了非常广泛的FILESTREAM_WORKITEM_QUEUE等待。此等待的范围从0到2942分钟不等。过去5天的总数为16 406分钟。这包括周末，服务器只有轻微的使用。

是什么原因造成了这种等待，我是否应该担心，有时在15分钟内会超过2000分钟？

这是带有10核处理器的Server 2012标准.

Answer 1

好吧，几乎所有的等待都是队列或定时等待(特别是名字中有QUEUE的等待)，基本上都可以忽略。虽然在Paul的要忽略的等待列表中没有明确列出这一项，但这种等待可能更少，而不是因为它不应该被忽略。在将Sentry等待数据上传到云中的所有实例中，这个等待类型是还没有遇到 (比较一下，比方说，LCK_M_SCH_M，一种更常见的观察到的等待类型--在近1%的实例中可以看到)。

结合：

• 没有关于这种等待类型的博客文章(我可以找到)；
• 这是第一次在这个站点上或在堆栈溢出上提到；并且，
• 微软甚至连“TBD”之外的任何事情都没说过..。

...leads我相信这是一个无害的等待，你不应该担心。

这是我在使用等待方法寻找“问题”时遇到的问题之一--这些等待是否涉及到任何与性能相关的实际症状？你总是要等待，这是最高的；这并不意味着这是一个问题。现在，如果您可以将此等待类型与相关内容(例如读取filestream容器或写入filestream容器)中可观察到的性能症状关联起来，那么可能会有更多的内容需要研究。

另外，您确定您正在准确地翻译到minutes__吗？在过去的5天里只有7200分钟，所以我不知道这个等待类型怎么会注册超过两倍。我已经觉得这个等待类型只能是一个定时器，这意味着它只是在积累良性的等待时间，我无法想象这也是并行发生的。所以，也许你引用的分钟实际上是秒或其他单位。