ASP.NET性能计数器暂时降到零
对VM映像有一些性能问题（我无权访问VM主机，只访问客户机操作系统）。
试图确定为什么有一段时间的范围从10-60秒，其中服务器只是停止推出任何请求。
在这样做的时候，我有几个性能计数器，但是我注意到一些非常奇怪的东西，在这些“死亡”期间开始后，我的所有ASP.NET应用程序计数器（活动会话，pipe道实例计数，请求执行）一旦我们摆脱了“死亡”时期，就恢复到正常水平。 在这里查看图表：
- 当“请求排队”一直在数百个时，ASP.NET的“请求等待时间”如何为0？
- 显示每个连接IP的stream量的Windows Serverstream量监视器
- Perfmon的开销 – >直接到SQL数据库
- P2V – select正确的服务器，基线
- 最好的免费networking监控工具，用于几个运行（主要是）Java应用程序的服务器？
我完全知道这些会议虽然从柜台统计中删除，但在整个时间内仍然保持运转。
有没有人从柜台看过这种行为？ 是否有可能导致这些计数器不正常的虚拟机资源匮乏，甚至可能导致整个死亡期？
我们刚刚遇到了这个问题，这让我感到非常紧张，并导致很多其他问题。 在这个低点期间，请求会在BeginRequest或者MapRequestHandler停顿 – 然后在10多秒之后，他们都会突然开始进入状态。
最终的根本原因是IIS应用程序正在自己的/ bin目录中写入一个文件。 IIS检测到它并发出一个软回收，将监听器的数量暂时减less到0（由Pipeline Instance Count显示，我发现这个问题的原因）。 然而，这并没有在任何其他工具中显示为新的过程等。
我们通过使用MS中的DebugDiag2来获取所有IIS进程的小型转储，其中一个减速是通过用小提琴手ping一个小端点而发现的。 DebugDiag有一个CrashHangAnalysis报告。 该报告中有很多信息 – 需要一段时间才能find包含System.Web.DirectoryMonitor.FireNotifications和System.Web.Compilation.BuildManager.OnWebHashFileChange的堆栈跟踪的HttpRuntime Shutdown Report 。
这导致我在prod bin目录中查找并发现有错误的电子邮件日志正在写入，导致IIS回收应用程序。 这特别奇怪，因为New Relic中的应用程序的内存图表显示了内存泄漏的情况，但实际上整个应用程序正在重新启动（有点），只是增加了现有的内存。 这看起来不像一个正常的回收，PIDs保持不变。 不知道什么魔术IIS试图做。
此外，更改IIS AppPool高级设置Disable Recycling for Configuration Changes True并不能防止此问题中build议的其他问题 。 我们必须改变和重新部署二进制文件来修复它。