Azure应用服务中的磁盘队列长度为30，这是不对的

我们正在与微软Azure支持团队进行一场战斗。 我希望Serverfault社区能够支持，因为以前的支持团队已经搞砸了我们。

这是发生了什么事。

作为我们在Azure上托pipe的一个更大的SaaS服务的一部分，我们有一个接受基本HTTP请求的前端应用程序服务，执行一些小的validation，然后将繁重的工作传递给后端服务器。 这个过程不是CPU，内存或networking密集型的，我们根本不接触磁盘子系统。

定价层级是“基本：2中等”，这对我们所承受的负担来说已经足够了。 CPU和内存图表显示系统在很大程度上处于内存使用率的36％左右。

• 一个VPN背后的基于云的域控制器是否可行？
• 将Azure VMjoinAzure AD
• 将用户帐户从Azure AD迁移到本地AD？
• AD副本DC促销档
• Azure虚拟机上的磁盘性能变慢

由于我们在服务器学校备受关注，我们使用Azure的标准监控设施主动监控整个解决scheme的各个层面。 我们跟踪的其中一个计数器是“磁盘队列长度”，它是Azure应用服务中可用的极less数计数器之一，因此它必须非常重要。

回到服务器学校，我们被告知，磁盘队列长度理想情况下应该为零，如果它持续超过1，你需要一起行动（某些RAIDconfiguration有一些例外）。 过去几年一切顺利，磁盘队列长度为99％，而当微软维修系统时，磁盘队列长度偶尔会升至5。

几个月前，情况开始发生变化（所以不是在我们推出改变之后）。 磁盘队列警报开始涌入，平均队列长度在30秒。

我们让它运行几天，看看问题是否会消失（性能没有明显的影响，至less在目前的负载下）。 由于问题没有消失，我们认为可能是底层系统有问题，所以我们实例化了一个全新的Azure应用服务并迁移到那个。 同样的问题。

所以我们联系了Azure支持。 当然，他们要求我们运行一些无意义的testing，希望我们能够走开（他们要求networking追踪…对于磁盘队列问题！）。 我们不会轻易放弃，所以我们进行了无意义的testing，最终被告知只要将队列长度设置为50（超过10分钟）即可。

尽pipe我们无法控制底层硬件，基础架构和系统configuration，但这听起来不对。

他们的全部答复如下

我通过收集的信息与我们的产品团队联系。

他们调查了您为磁盘队列长度指定的警报发射频率超出预期的问题。

如果在5分钟内磁盘队列长度平均值超过10，则会将此警报设置为通知您。 此度量标准是采样间隔期间所选磁盘排队的读取和写入请求的平均数量。 对于Azure应用程序服务基础结构，以下文档链接讨论了此指标： https ： //docs.microsoft.com/en-us/azure/app-service-web/web-sites-monitor

对于部署的任何types的应用程序，值10非常低，因此您可能会看到误报。 这意味着警报可能比确切的连接数更频繁地触发。

例如，在每个虚拟机上，我们运行防恶意软件服务来保护Azure应用服务基础设施。 在这段时间内，您会看到已build立的连接，如果警报设置为较低的数字，则可以触发。

我们没有发现任何影响您网站可用性的反恶意软件扫描实例。 Microsoftbuild议您考虑在10分钟内将“磁盘队列长度”度量设置为至less50的平均值。

我们相信这个价值应该让你继续监视你的应用程序的性能目的。 它也应该受到我们为维护目的而运行的防恶意软件扫描或其他连接的影响。

任何人想要join？