好的，我们的新版本在随机间隔内每台服务器上的 CPU 峰值达到 100%。长时间内，它会导致网站完全无响应 - 这种情况发生在高峰时段，因为不同国家/地区的用户登录网站等。
我们研究了 perfmom、内存分析器、CLR 分析器、sql 分析器、Red gate ants 分析器，尝试了 UAT 中的负载测试 - 但甚至无法重现该问题。这可能意味着只有数千名用户访问实时网站才会导致这种情况发生。
我们确实注意到的一个模式是，新代码（损坏的构建）实际上使用的线程明显更少。
我们也在为 IOC 使用 spring - 它有 bed 声誉吗？
更糟糕的是，由于业务影响，我们无法进行实时部署 - 因此无法将问题缩小到我们添加的新功能的子集。
我们确实被摧毁了——有谁身上有战斗伤疤可以拯救我们的生命吗？
答案1
我建议进行内存转储，并使用 Sos 在 WinDdg 中对其进行分析。我修复了生产中的一些问题，如果没有 WinDbg，我可能无法诊断这些问题。
泰丝·费尔南德斯有一个很棒的博客，您可以在其中了解如何分析内存转储。
答案2
这通常是由于 GC 中清理大型长寿命对象造成的（stackoverflow 有这个问题，参见链接)。您是否在缓存或会话中存储了大量的对象集合？
我还建议您在生产环境中构建和配置一台新服务器进行测试。如果您遇到随机疯狂行为，不知道原因，也无法重现，我会将问题归咎于硬件或配置，而不是代码。
答案3
这是具有共享资源的虚拟服务器还是物理服务器？如果是前者，也许您可以考虑将资源专用于此服务器。祝您好运...
答案4
在没有数据的情况下尝试猜测错误是毫无意义的。是的，stackoverflow 或您的工程团队中的某个人可能会走运，但那只是糟糕的工程，您无法计划好尝试每个猜测需要多长时间，以及他们是否会找到问题。
- 你必须重现问题。Jmeter 因其广泛性而是一个很好的开始，但如果不了解我们的架构，我们就无法推荐正确的工具。
- 日志记录特别是在应用程序层，这是必须的。您可以启用 IIS 跟踪来降低性能，但微软的笨蛋让您无法在性能缓慢时捕获整个管道流。如果很难重现，您真的需要一些日志来帮助您缩小范围在哪里问题是。（就像哦，每当我们调用这个存储过程时）。
CPU 100% 有点可疑，因为它不太可能是 I/O（假设数据库是另一个框，缓慢的数据库不应该导致 Web 服务器上的 CPU 达到 100%）。您需要仔细观察。