奇怪的Azure VM性能问题

Question

我们在Azure上为一位客户提供了5台VMs。所有的越野车运行都很顺利。

现在，从星期一开始，其中一个用户的VM每天下午4点UTC+1 (+-1h)就会失去性能。当我们有这些性能问题时，CPU随机运行在100%左右。

所有其他VM运行平稳，而软件栈在所有VM上都是完全相同的。

我们已经与微软的支持部门联系了超过24小时。同时，我们已经重新部署了VM 2次，一次从快照中重新部署，一次完全从零开始重新部署。这一问题再没有减少过。

所有其他VM运行在相同的情况下，大约在5-30%的CPU.

这个问题根本不能重复。一次只来来去去几个小时。

我们现在有四个经验丰富的工程师在这方面，我们无法解决这个问题。

你们知道这可能是什么吗？我很高兴有任何意见。我们很快就要疯了..。

我们在机器上运行的是：

• O365办公室
• Adobe阅读器
• Avast杀毒
• Firefox / Chrome
• 2个专门的力学软件工具
• OneDrive
• ScreenConnect

我们已经做了些什么来找出/解决这个问题：

• 性能诊断(没有特定的进程导致它)
• 比较Windows版本
• 比较所有安装的软件
• 比较所有Azure设置
• 从零开始重新创建VM
• 检查磁盘吞吐量
• 检查内存使用情况
• 全AV检查
• 根据Microsoft支持部门的建议(SQL express通过Veeam安装)，从所有VM中删除Veeam
• 检查所有事件日志->无特殊情况

当我想起更多我们试过的东西时，我会在这里编辑

Answer 1

感谢我们在Reddit的可爱朋友们，我已经找到了解决这个问题的办法。因此，我们正在运行Burstable VMs (B系列)，有人向我指出，这些VMs具有“随时间增长的突发配额”。

在深入研究这个问题之后，我发现这个暗示在钱上是完美的。我知道这些VM是可燃烧的，但我不知道这是如何测量或限制的。

经过大量的挖掘和验证假设，使用天蓝色监视器同时使用CPU百分比以及所有VM上的“CPU学分剩余”指标，结果显示CPU学分正在耗尽，因此CPU被限制在40%以内，直到负载减少或积分累积为止。

当停止和释放VM时，信用将被重置为一个基线，并且在客户完成工作之前，信用从未用完过。

非常感谢你把我带到正确的方向，这给我们带来了更多的麻烦。

我们现在已经把规模提高了一倍，而且一直运行得很好，而且积分也不会降到零。

这个星期才刚刚开始，因为我们星期一和星期二都在运行备份作业，所以当备份开始的时候，CPU的使用率在中午左右就更高了，并且在下午4点左右就降低了学分。

这周剩下的时间里，监控的增加和试图通过增加使用量来引发问题，确实导致了问题再次发生，但延迟了。

在分析的过程中，我们意识到这个特定的用户只是一次做得更多，所以CPU比CPU基线更频繁，从而降低了CPU的信用。

大约两个小时后，我们发现这一点，微软得出了同样的结论。

谢谢大家的投入，尤其是Reddit用户/u/VTi-R，我真的很感激！

您可以在这里找到关于B系列VM的更多信息，https://azure.microsoft.com/de-de/blog/introducing-b-series-our-new-burstable-vm-size/。