因此我们使用由5台服务器组成的VMWare创建VM环境。 数据库服务器，
其他说明：
每个网络服务器上大约有30个网站，这些网站由物理负载均衡器通过循环进行定向。
每个单独的网站都有一个名为SharedContent的虚拟目录，位于主网站文件夹之外 - 位于单独的内容服务器上。
该文件夹被共享并映射为所有网站的虚拟文件夹
所以所有网站都从同一个文件夹中提取图像和预告片。 目前，根文件夹中有大约1400000个文件，共享内容文件夹中有7个子文件夹中有几千个文件。
问题在于，有几次所有网络服务器都会转向100％CPU并导致所有网站都没有响应，因为有更多请求通过。该应用程序基于ASP.NET 3.5，服务器开始返回503
网站配置为使用基于ASP.NET文件的缓存
我们怀疑它与SharedContent文件夹及其中的所有文件有关。我们做了一个测试，将30个文件移动到共享文件夹（在所有站点中映射为虚拟目录）手动 - 首先文件服务器达到峰值100％CPU（可能重新索引文件）然后这个效果级联到所有3个Web服务器，所有的网络服务器都达到了100％的CPU并且留在那里
使Web服务器恢复正常运行的唯一方法是从资源管理器中查找具有高CPU使用率的进程。
我们不知道为什么会这样 - 我们正在制作一个补丁来分发该文件夹中的文件，最终会创建子文件夹并在那里移动文件
我们不知道的是它背后的原因是什么？ - 如果我们快速将几个文件（复制20-30个文件）添加到该文件夹，CPU首先会在文件内容服务器上启动，然后一个接一个地所有Web服务器也会高达100％的CPU使用率
在这些停电期间：
如果有人知道为什么会这样？或背后的理由？
以前有没有人经历过这样的事情？
更新：20/1/17
所有网站在每个网络服务器上都有自己的应用程序池。
当时事件查看器中添加的唯一错误是请求超时。
去年8月，基础设施从物理环境迁移到虚拟机，从未出现问题。
2016年11月底，3个网站升级到.net 4.5，其余网站仍在.net 3.5。 这个问题的第一个例子发生在12月底。
我们尝试在SharedContent文件夹中添加另一个权限角色，该文件夹在高峰期将其高达100％的CPU。我们不得不取消这项行动。
交通正常。
SharedContent配置为映射驱动器。
答案 0 :(得分：0)
以下是我要检查的内容;
让所有网站都拥有自己的应用程序池，或者在每台服务器上的所有30个站点之间共享。
您是否已经隔离了使用100％的确切流程？
是否有任何错误被添加到事件查看器中？
您是否收到外部流量/内部流量的任何高峰。
是否在vm主机上生成了错误？
物理cpu是否过度分配给vms？
域控制器中的计算机是什么？这会在盒子上触发任何类型的更新活动吗？
共享内容如何完成，映射驱动器或MS分布式文件系统？如果使用DFS是什么拓扑结构？